<br><br><div class="gmail_quote">2011/4/8 Andrew Bradford <span dir="ltr"><<a href="mailto:bradfa@gmail.com">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 class="im"><<a href="mailto:al004140@gmail.com">al004140@gmail.com</a>> wrote:<br>
> 2011/4/8 Andrew Bradford <<a href="mailto:bradfa@gmail.com">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">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><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><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> 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><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><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><br>If that doesn't work, I'll take a look at that   URL. <br>Your advices are always very valuable to me.  <br>Thank you very much for your help, Mr. Andrew!<br>
<br>Best regards,<br>  -- Ivan<br><br>
</div></div>