Hello forum!<br><br><div class="gmail_quote">2011/4/8 Angel Ivan Castell Rovira <span dir="ltr"><<a href="mailto:al004140@gmail.com">al004140@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">2011/4/8 Andrew Bradford <span dir="ltr"><<a href="mailto:bradfa@gmail.com" target="_blank">bradfa@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Fri, Apr 8, 2011 at 11:38 AM, Angel Ivan Castell Rovira<br>
<div><<a href="mailto:al004140@gmail.com" target="_blank">al004140@gmail.com</a>> wrote:<br>
> 2011/4/8 Andrew Bradford <<a href="mailto:bradfa@gmail.com" target="_blank">bradfa@gmail.com</a>><br>
>> On Fri, Apr 8, 2011 at 5:34 AM, Angel Ivan Castell Rovira<br>
>> <<a href="mailto:al004140@gmail.com" target="_blank">al004140@gmail.com</a>> wrote:<br>
>> ><br>
>> > I have built a buildroot-based toolchain with the same package versions<br>
>> > used<br>
>> > in CLFS book, to compile my custom kernel (2.6.30.4)<br>
>> ><br>
>> > binutils-2.21<br>
>> > gcc-4.5.2<br>
>> > uClibc-0.9.31<br>
>> ><br>
>> > The kernel image generated with that toolchain also generated the Oops<br>
>> > message reported yesterday building with CLFS toolchain. So, it was<br>
>> > obviously not related with any missing CLFS patch...<br></div></blockquote></div><div><br>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:<br>
<br>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.<br>
<br>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.<br>
<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>
> CLFS_HOST=i486-cross-linux-gnu<br>
> CLFS_TARGET=armv4-linux-uclibceabi<br>
> CLFS_FPU=<br>
> CLFS_ARM_ARCH=armv4t<br>
> CLFS_ARM_MODE=arm<br>
> CLFS=/home/clfs<br>
> CLFS_ARCH=arm<br>
> CLFS_ABI=aapcs-linux<br>
> CLFS_ENDIAN=little<br>
> CLFS_FLOAT=soft<br>
><br>
> You should be able to reproduce the same behabiour following the same steps<br>
> described on the book.<br>
<br>
</div><br>I can build it, but I don't have an ARM920T board, so booting may be<br>
difficult...<br></blockquote></div><div><br>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...<br>
<br></div><div>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).<br>
<br>
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. <br><br>
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...<br><br>I will report here the obtained result.<br></div></div></blockquote><div><br><br>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:<br>
<br>MPFR:<br> $ patch -Np1 -i ../mpfr-3.0.0-p8.patch<br><br>BINUTILS:<br> $ patch -Np1 -i ../110-arm-eabi-conf.patch<br> $ patch -Np1 -i ../120-sh-conf.patch<br> $ patch -Np1 -i ../300-001_ld_makefile_patch.patch<br>
$ patch -Np1 -i ../300-012_check_ldrunpath_length.patch<br><br>GCC-STATIC:<br> $ patch -Np1 -i ../100-uclibc-conf.patch<br> $ patch -Np1 -i ../301-missing-execinfo_h.patch<br> $ patch -Np1 -i ../302-c99-snprintf.patch<br>
$ patch -Np1 -i ../305-libmudflap-susv3-legacy.patch<br> $ patch -Np1 -i ../810-arm-softfloat-libgcc.patch<br> $ patch -Np1 -i ../820-arm-unbreak-armv4t.patch<br> $ patch -Np1 -i ../830-arm-pr43440.patch<br> $ patch -Np1 -i ../850-arm-pr44392.patch<br>
<br>UCLIBC:<br> $ patch -Np1 -i ../uClibc-0.9.31-configs-2.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-add-bsd-endian-conversions.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-dnslookup-use-after-free.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-fix-error-locale-utf-8.patch<br>
$ patch -Np1 -i ../uClibc-0.9.31-fix-fcntl64-for-64-bit-targets.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-more-workarounds-GCC-PR32219.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-powerpc-ptrace-fix.patch<br> $ patch -Np1 -i ../uClibc-0.9.31-quad-routines.patch<br>
$ patch -Np1 -i ../uClibc-0.9.31-workaround-GCC-PR32219.patch<br><br>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.<br>
<br>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. <br>
<br>Do you think some missing configuration parameter (./configure) when configuring some of the packages compilation could be the problem?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div> </div><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regardless, you're not the only one having issues with armv4t, see:<br>
<a href="https://lists.yoctoproject.org/pipermail/yocto/2011-January/000889.html" target="_blank">https://lists.yoctoproject.org/pipermail/yocto/2011-January/000889.html</a><br>
Yocto may have fixed this issue (they just released their 1.0). Their<br>
toolchain may be a good one to take a look at and compare to CLFS.<br></blockquote></div></div></blockquote><div><br>
</div></div>The kernel panic reported on this post seems to be the same as I have. I have cloned the git repos <a href="http://git.pokylinux.org/cgit/cgit.cgi/poky-extras">http://git.pokylinux.org/cgit/cgit.cgi/poky-extras</a>, 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? <br>
<br>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...<br><br>
Regards,<br>
-- Ivan<br>
<br>