[Clfs-support] Oops booting a working kernel cross-compiled with CLFS cross-toolchain [SOLVED]

[Andrew Bradford]

On Fri, Apr 8, 2011 at 11:38 AM, Angel Ivan Castell Rovira
<al004140 at gmail.com> wrote:
> 2011/4/8 Andrew Bradford <bradfa at gmail.com>
>> On Fri, Apr 8, 2011 at 5:34 AM, Angel Ivan Castell Rovira
>> <al004140 at gmail.com> wrote:
>> >
>> > I have built a buildroot-based toolchain with the same package versions
>> > used
>> > in CLFS book, to compile my custom kernel (2.6.30.4)
>> >
>> > binutils-2.21
>> > gcc-4.5.2
>> > uClibc-0.9.31
>> >
>> > The kernel image generated with that toolchain also generated the Oops
>> > message reported yesterday building with CLFS toolchain. So, it was
>> > obviously not related with any missing CLFS patch...

OK, that's good to know.
Buildroot seems like a good benchmark for CLFS right now, if both are
performing the same, that's good.

>> > I tryied again a buildroot-based toolchain, but setting up with older
>> > version of gcc/binutils/uClibc packages. Just to test, I selected:
>> >
>> > binutils-2.20
>> > gcc-4.2.4
>> > uClibc-0.9.30
>> >
>> > And surprisingly (at least for me), the image of that kernel works fine,
>> > it
>> > does not generate any Oops message. It seems that not every version of
>> > gcc
>> > can build a working linux kernel. I'm curious to know why both
>> > cross-compilers generate a kernel image fine, but only one of the
>> > generated
>> > images runs fine on my platform. Does that have some sense to you?

If something changed in GCC between 4.2.4 and 4.5.2, yes, it would
make sense that one tool chain will cause kernel oops and another
won't.

> CLFS_HOST=i486-cross-linux-gnu
> CLFS_TARGET=armv4-linux-uclibceabi
> CLFS_FPU=
> CLFS_ARM_ARCH=armv4t
> CLFS_ARM_MODE=arm
> CLFS=/home/clfs
> CLFS_ARCH=arm
> CLFS_ABI=aapcs-linux
> CLFS_ENDIAN=little
> CLFS_FLOAT=soft
>
> You should be able to reproduce the same behabiour following the same steps
> described on the book.

I can build it, but I don't have an ARM920T board, so booting may be
difficult...

> The small changes I made are theses:
> I have installed this patches:
>
> static gcc:
> patch -Np1 -i ../810-arm-softfloat-libgcc.patch
>
> uClibc:
> patch -Np1 -i ../uClibc-0.9.31-configs-2.patch
>
> busybox:
> patch -Np1 -i ../busybox-1.17.3-fixes-1.patch
> patch -Np1 -i ../busybox-1.17.3-config-1.patch
>
> I installed sanitized headers of my 2.6.30.4 kernel instead of the 2.6.36
> refered on the book

OK, that looks reasonable.

> This is my /etc/inittab on my rootfs

Inittab and /dev nodes shouldn't matter here.  You should at least get
a message saying that init started (an no oops).  If init can't find
what it wants, it'll get pissed off and tell you, or just die
silently, but there'll be no oops.

> I will continue checking diffs between setup of patches between buildroot
> and CLFS to see if that helps...

If Buildroot's GCC 4.5.2 tool chain is giving you the same issue as
the CLFS tool chain, that probably points to a GCC issue.  Comparing
patches for GCC 4.5.2 and 4.2.4 may not be easy, I'm sure there's a
_LOT_ of different code between those two GCC versions, especially for
ARM targets.

> Hope somebody can help with that. Thanks a lot in advance!! Does your kernel
> cross-compiled with CLFS work?

I have a working 2.6.38 kernel cross compiled with a CLFS tool chain.
But it's for an ARM cortex-A8 TI OMAP3 processor (armv7-a).

You could try a newer version of the kernel, maybe there's a problem
with the combo of your kernel version and GCC version?
Your kernel .config file from 2.6.30 may not work without a lot of
effort on a newer (like 2.6.38) kernel source, but if you can cobble
together a good enough config to get to init, that's worth trying.

> The complete messages when boots my kernel cross-compiled with CLFS:

That's helpful, thanks.  I don't see anything that stands out, but
then again, I'm not a kernel hacker so I'm not really sure what to
look for.

Regardless, you're not the only one having issues with armv4t, see:
https://lists.yoctoproject.org/pipermail/yocto/2011-January/000889.html
Yocto may have fixed this issue (they just released their 1.0).  Their
toolchain may be a good one to take a look at and compare to CLFS.

-Andrew