From mboxrd@z Thu Jan 1 00:00:00 1970 From: bifferos Date: Sun, 18 Mar 2012 16:12:39 +0000 Subject: [Buildroot] [PATCH] bifferboard: new board In-Reply-To: <201203181450.44385.arnout@mind.be> References: <201203031529.36487.arnout@mind.be> <1330788921-27127-1-git-send-email-arnout@mind.be> <4F5D5017.2080908@yahoo.co.uk> <201203181450.44385.arnout@mind.be> Message-ID: <4F660977.4040806@yahoo.co.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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