[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Working with Freescale 8323

From: Charles Krinke
Subject: Re: [Ltib] Working with Freescale 8323
Date: Fri, 4 Feb 2011 10:25:46 -0800

Thanks, Peter, what you say makes quite a lot of sense. I had forgotten about HOSTCC and I should have remembered it. I will digest what you have written and see if I can get back into the ltib groove. I also have this distraction called "Open Embedded" that the other engineer I am working with and its fragilities and nested bitbake menus give me a different sort of headache. Basically, I am trying to get the customer back to being used to ltib and weaned a bit from Open Embedded. Unfortunately, it is not smooth sailing yet for either for me.


On Fri, Feb 4, 2011 at 9:11 AM, Peter Barada <address@hidden> wrote:
On 02/04/2011 11:24 AM, Charles Krinke wrote:
Thank you Peter for your help.

I thought I was out of the woods last night, but this morning, I ended up with a very similar issue I started with. Yesterday, I was able to do "./ltib -f -p kernel -m scbuild" with no problem.

Then I edited a c source file and a found that ./ltib -f -p kernel -m scbuild did not rebuild the edited source file. Looked like ltib could not tell the time stamp changed.

So, .... in my zeal, I went "./ltib -m shell" and cd/rpm.BUILD/linux-2.6.20 and executed a make.

At this point, make fails (and subsequent invocations of ./ltib -f -p kernel -m scbuild also fail) with a error on scripts/basic/fixdep.

Using "file", I can see that scripts/basic/fixdep is a PPC executable and not a host executable, so I end up very confused.

I *thought* that the cross compiler setup was already handled in the ltib shell so this must be some environment issue.
Yes, but the spoofing replaces the system tools with the cross tools (since some packages aren't bright enough to figure out that they are cross compiling.  This means that you need the host compiler which the kernel looks for via HOSTCC.  Blindly executing "make" in the kernel directory (even if inside an LTIB shell) will cause even more problems.

What you should do is to move your kernel directory out of the way, then *outside* of LTIB's shell (one you get from "./ltib -m shell") in the top-level LTIB directory execute "./ltib -p kernel -m prep && ./ltib -p kernel -f -m scbuild 2>&1 | tee /tmp/build.log"  This will prep the kernel source, then build the kernel and capture a logfile in /tmp/build.log.  Look in /tmp/build.log for the make step that builds the kernel image.  For my OMAP3 arm project (yours will be different but somewhat similar) I see:

+ make ARCH=arm 'HOSTCC=ccache /usr/bin/gcc -B/usr/bin//' uImage

The "ARCH=arm" should be obvious for my ARM world
The "'HOSTCC=ccache /usr/bin/gcc -B/usr/bin//'" is the host compiler command (used to build scripts/basic/fixdep and other host utilities needed by the kernel build process).
The "uImage" is the kernel image I want ot build that is loadable by u-boot.

If you try to build the kernel w/o HOSTCC, then it assumes that you are building the kernel natively (as in build it on your PPC board!) and will use the same compiler ("gcc" which is now spoofed by LTIB to be the PPC cross-compiler in your world) for both the kernel utilities and the kernel code.  This as you can understand is quite bad when you really wanted to cross-compile the kernel.

If you want to build your kernel directly you can create an LTIB shell, cd into the kernel source and then execute that same command (that you pulled out of your /tmp/build.log).  And yes, it is a bit tricky to get everything right the first time you do this in LTIB.

What I am trying to use is the ltib from Freescale to get back to a baseline. This particular ltib is dated 20081112 so is older then current state-of-the-ltib. But the issue is that it should be possible to go back to an ltib iso image from 1, 2 or 4 years ago and be able to work with it to compile u-boot, kernel and a root filesystem. At least that is what I have told my customer. So, until I gain a bit more understanding, I am a bit behind the eight-ball, so to speak.
If you've used a newer LTIB and want to go back, I'd suggest moving /opt/freescale and /opt/ltib out of the way since some of the "newer" bits in there may confuse an older LTIB and cause all kinds of grief...


On Thu, Feb 3, 2011 at 5:20 PM, Peter Barada <address@hidden> wrote:
On 02/03/2011 07:52 PM, Charles Krinke wrote:
I got the ltib running for the 8323 on two different computers, but had to go through the ltib configure step several times and eventually found the right combination of settings that lets me be able to build u-boot, uImage and rootfs.jffs2.

This leads to another question. "What is the location of the configure file and its name that ./ltib --configure creates?".

I think I need to study this file a bit *and* another engineer that I am supporting wants to get the same ltib running and already requested the configuration file at which point I had to shrug, look foolish and say "dunno where it is yet".
You'll find it in config/platform/<platform>/.config, created from config/platform/ (and if that doesn't exist then config/platform/  the and .config in the config/platform/<platform>/ directory are created from the config/platform/<platform>/defconfig which is the default configuration you use when you use "./ltib" unless you change the configuration with "./tlib -c" or "./ltib --configure"....

Peter Barada

reply via email to

[Prev in Thread] Current Thread [Next in Thread]