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

Mon Apr 11 07:02:32 PDT 2011

Hello forum!

2011/4/8 Angel Ivan Castell Rovira <al004140 at gmail.com>

>
>
> 2011/4/8 Andrew Bradford <bradfa at gmail.com>
>
>> 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...
>>
>
> My previous ssertion was false. I apologize for the confusion. Let me
> explain a little bit better to try to avoid confusion for future readers:
>
> The kernel image generated *with buildroot* works and boots the rootfs,
> fine, without generating any Oops message. When I tested it, I configured
> buildroot wrongly, and it was not decompressing my kernel 2.6.30.4 headers.
> It was decompressing default kernel headers. (I found this error this
> afternoon). That's because buildroot was not working fine. This was fixed,
> and now it is working fine.
>
> However, the reported problem is still happening *when building the kernel
> with the CLFS toolchain*. Here I can strongly confirm that I have properly
> installed sanitized kernel 2.6.30.4 headers to build my CLFS (as I have
> previously explained, I repeated the whole process again from scratch to be
> completely sure). And this is the kernel that it ls generating the Oops
> message reported in the post.
>
>
> > 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...
>>
>
> I understand, don't worry. I'm very interested in learning about that
> topic, I will try to fix this issue by myself, but it's always very useful
> to receive some advices, specially when you are lost in the huge ocean of
> cross-compilers...
>
> Just to clarify things a little bit more: the "rootfs" build with CLFS is
> OK, because the kernel build with buildroot is booting, mounting and
> prompting the shell (init/sh applets) on that rootfs properly. So, the CLFS
> cross-compiler is generating good userspace libs/bins (but not a working
> kernel).
>
> So, same kernel sources, same kernel headers, same compiler version, same
> uClibc... I suppose it has to be related with some gcc patch that buildroot
> applies, but CLFS don't.
>
> That's what I want to check. I will try to apply all the patches provided
> by buildroot and then I will build the CLFS again from scratch. Hope that
> will fix the issue...
>
> I will report here the obtained result.
>

I was trying to test if I just applying all the buildroot patches to the
corresponding CLFS packages, that could help. The patches applied have been
found using the hidden file .applied_patches_list for each package built by
buildroot:

MPFR:
    $ patch -Np1 -i ../mpfr-3.0.0-p8.patch

BINUTILS:
    $ patch -Np1 -i ../110-arm-eabi-conf.patch
    $ patch -Np1 -i ../120-sh-conf.patch
    $ patch -Np1 -i ../300-001_ld_makefile_patch.patch
    $ patch -Np1 -i ../300-012_check_ldrunpath_length.patch

GCC-STATIC:
    $ patch -Np1 -i ../100-uclibc-conf.patch
    $ patch -Np1 -i ../301-missing-execinfo_h.patch
    $ patch -Np1 -i ../302-c99-snprintf.patch
    $ patch -Np1 -i ../305-libmudflap-susv3-legacy.patch
    $ patch -Np1 -i ../810-arm-softfloat-libgcc.patch
    $ patch -Np1 -i ../820-arm-unbreak-armv4t.patch
    $ patch -Np1 -i ../830-arm-pr43440.patch
    $ patch -Np1 -i ../850-arm-pr44392.patch

UCLIBC:
    $ patch -Np1 -i ../uClibc-0.9.31-configs-2.patch
    $ patch -Np1 -i ../uClibc-0.9.31-add-bsd-endian-conversions.patch
    $ patch -Np1 -i ../uClibc-0.9.31-dnslookup-use-after-free.patch
    $ patch -Np1 -i ../uClibc-0.9.31-fix-error-locale-utf-8.patch
    $ patch -Np1 -i ../uClibc-0.9.31-fix-fcntl64-for-64-bit-targets.patch
    $ patch -Np1 -i ../uClibc-0.9.31-more-workarounds-GCC-PR32219.patch
    $ patch -Np1 -i ../uClibc-0.9.31-powerpc-ptrace-fix.patch
    $ patch -Np1 -i ../uClibc-0.9.31-quad-routines.patch
    $ patch -Np1 -i ../uClibc-0.9.31-workaround-GCC-PR32219.patch

Then, I regenerated again the CLFS-based toolchain.  After that, I
cross-compiled my custom 2.6.30.4 kernel with that CLFS-based toolchain.
After booting my ARM 920T platform with that kernel, I got the same Oops
error detailed on a previous post.

Makefiles differ after comparing diff's between buildroot and CLFS package
sources (after applying patches). The file path'es are different, of course.
But also there are more differences: for example "CC = gcc" vs "CC = gcc
-std=gnu99". The md5sum's of source tarballs are all exactly the same. I
also used the uClibc .config to configure my own uClibc.

Do you think some missing configuration parameter (./configure) when
configuring some of the packages compilation could be the problem?

>
>
>> 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.
>>
>
The kernel panic reported on this post seems to be the same as I have. I
have cloned the git repos http://git.pokylinux.org/cgit/cgit.cgi/poky-extras,
and there are a lot of patches, but all of them are related to gcc 4.5.1.
Does some of you know if some of these patches could fix that issue?

Keep in mind buildroot is building a valid kernel image, so the answer
should also be on the buildroot sources. I don't understand why should I use
a patch that buildroot is not using at all...

Regards,
  -- Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-support-clfs.org/attachments/20110411/d620c202/attachment-0001.htm>