3

I am trying to build a basic root filesystem using Buildroot, for an embedded system (the Banana PI D1).

I am using a kernel from an SDK supplied by the SoC vendor. From this repo I am using only the kernel, found in src/kernel.

There's nothing remarkable about the Buildroot configuration. It builds with no errors and the resulting root filesystem looks like it contains everything I would expect.

I have configured it to build the filesystem as an initramfs embedded within the zImage.

The kernel appears to start up correctly, but cannot load init and then panics:

Booting Linux on physical CPU 0
Linux version 3.4.35 (harmic@penski.harmic.moo.org) (gcc version 4.8.4 (Buildroot 2015.02) ) #7 Sat Mar 21 22:59:18 AEDT 2015
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
...
Kernel command line: root=/dev/mtdblock1 ro init=/sbin/init mem=64M console=ttySAK0,115200
...
Freeing init memory: 4632K
Failed to execute /init
Failed to execute /sbin/init.  Attempting defaults...
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SDHC card at address 0007
mmcblk0: mmc0:0007 SD08G 7.42 GiB 
 mmcblk0: p1
Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.

I have tried a number of troubleshooting steps:

  1. I've built a root filesystem using this miniroot project (took some doing, as it is quite out of date). It booted OK, using the same kernel as I am trying to use with the buildroot root fs.

  2. I've tried using both uClibc and eglibc

  3. I've tried using Buildroot's own cross-tools as well as the cross tools supplied by the SoC vendor

  4. I've confirmed that the built rootfs does include an /init (it does!)

There is a gist here containing the buildroot configuration, a copy of the kernel boot log, and a listing of the contents of the generated filesystem.

What steps can I take to troubleshoot this further?

Update:

  1. The generated rootfs.cpio.gz weighs in at 2139200 bytes. I have read that there is a maximum size of initramfs you can use, but I have not been able to find where the hard limit is documented.

  2. I have attached a listing of the generated root filesystem to the gist linked above.

  3. I have unpacked the rootfs on the host and inspected it. /init contains this:

    #!/bin/sh
# devtmpfs does not get automounted for initramfs
/bin/mount -t devtmpfs devtmpfs /dev
exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console
exec /sbin/init $*

    /sbin/init is a symlink to /bin/busybox.

    /bin/busybox is dynamically linked:

    $ file busybox
busybox: setuid ELF 32-bit MSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
$ ../../../host/usr/bin/armeb-buildroot-linux-gnueabi-readelf -a busybox | grep "Shared library:"
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

    libc.so.6 is present in /lib. /lib32 is a symlink to /lib for good measure.

  4. The device has 64M RAM.

  5. Both the vendor's cross tools and the buildroot cross tools are set up for eabi

harmic
  • 28,606
  • 5
  • 67
  • 91
  • Your question is not clear. Do you want buildroot to create a init file or Do you want to have a running system? – Prajosh Premdas Mar 24 '15 at 12:48
  • supply `ignore_loglevel` to your kernel command line and boot. It might tell a little bit more. – 0andriy Mar 24 '15 at 17:33
  • If you have a working qemu for your target architecture (or some other remote debugging mechanism -- JTAG?), you can use that to attach a debugger to the kernel and see what's happening up close. Overkill sometimes, to be sure, but overkill isn't always a bad thing. – Charles Duffy Mar 24 '15 at 21:08
  • 1
    *"I've tried using both uClibc and eglibc"* -- I've had issues with booting with a large initramfs (but I don't recall the exact symptoms). eglibc is a poor choice for an initramfs; use the smaller uClibc. How much memory do you have? What are the sizes of these images? Are you positive the ARM926 processor should be running in big-endian mode? BTW ramdisk != ramfs. – sawdust Mar 24 '15 at 21:31
  • @PrajoshPremdas I want to create a root filesystem which boots successfully. To do that it would have to have an init program which the kernel could start. – harmic Mar 24 '15 at 22:46
  • @CharlesDuffy No JTAG I'm afraid. I tried QEMU - the CPU Core is supported but the SoC is not, so the UART is not emulated - so I can't interact with it. Maybe I can get around that by rebuilding the kernel with a different UART driver – harmic Mar 24 '15 at 22:49
  • Unpack that initramfs (as root) and have a look at it. Is it init or sbin/init? Is it executable? What are its dynamic library dependencies, if any? Is it compatible with the abi of the kernel? How does it compare against the one from the miniroot project that you said worked? – Chris Stratton Mar 24 '15 at 23:40
  • @sawdust I think you may be onto something with the endianness. I followed Chris Stratton's advice and compared the busybox between the buildroot and working minitroot images, and the working one is LSB. I have kicked off a fresh build using little endian. Let's see .... – harmic Mar 25 '15 at 10:16

1 Answers1

3

As suggested by @sawdust, the problem was that the CPU was not supposed to be run in big endian mode.

After changing the target to 'ARM (Little Endian)', cleaning and re-building, it now boots correctly.

In retrospect this should have been obvious - inspecting the vendor's kernel image:

$ file zImage
zImage: Linux kernel ARM boot executable zImage (little-endian)
harmic
  • 28,606
  • 5
  • 67
  • 91