[Buildroot] [PATCH] bifferboard: new board

[bifferos <bifferos@yahoo.co.uk>]

On 03/18/2012 01:50 PM, Arnout Vandecappelle wrote:
> On Monday 12 March 2012 02:23:35 bifferos wrote:
>> Write protecting the kernel text: 1048k
>> Write protecting the kernel read-only data: 164k
>> init[1]: segfault at 0 ip   (null) sp bf95bf40 error 4 in
>> busybox[8048000+7c000]
>   Since this segmentation fault is in init, it will be tough to debug.
> Judging from the address, it in fact happens even before init is
> started.  Is it possible that there isn't enough RAM to run busybox?
>

I have a hard time believing there is not enough RAM  I have copied the 
generated busybox onto the working system and run it there, and it 
executes OK, so the same system can execute two instances of the busybox 
binary (from two different places on rootfs), and they both run OK.

I learnt something new the other day - an initramfs compiled into the 
kernel can be compressed, however the kernel compression works ontop of 
that.  So if you specify CONFIG_INITRAMFS_SOURCE it is pointless to 
specify initramfs compression other than 'None', and in fact this is 
probably why lzma compression for initramfs in conjunction with lzma 
compression for kernel gives Ooops on kernel boot for most recent 
kernels (2.6.37 -> 3.3), perhaps because the compressed is larger than 
the uncompressed initramfs.. or something.  When I used bz2 initramfs 
compression (or any other compression) instead of lzma, it worked.  Now 
I switched initramfs compression to 'none' and removed the support for 
bz2 compressed initramfs and saved myself another 20k of space - handy 
to know if your storage is constrained, but not immediately obvious 
unless you've done the experiment.

So, why was I messing about with this?  To make it easier to pull out 
the cpio after the fact.  I switched kernel compression to bz2, 
initramfs to 'none', searched for BZh header in kernel, pulled out the 
binary from there, uncompressed with bz2 (it ignores junk at the end of 
the file, fortunately), and looked at the resulting binary.  Yes, 
there's definitely a cpio there, it's got the header '070701', and it 
matches the cpio generated by buildroot.  It also seems to indicate cpio 
generated with the right options (not that I believed buildroot would 
have screwed that up or everyone would have noticed).  CPIO starts at 
about the right place, and it's the right length.  I can see busybox and 
its strings inside it, it's really beginning to look doubtful it's 
corrupted, the only thing I haven't done is pull it out of the cpio 
again and try to run it.

Now I'm wondering if there is something that has been activated in 
busybox, some feature, which requires kernel support, and (since my 
kernel is minimal) perhaps it doesn't have it, and perhaps init doesn't 
handle the lack of that support gracefully and crashes.  Nothing comes 
to mind though.

regards,
Biff