BeagleBox: small steps – better xcc, u-boot/kernel boot but rootfs still hangs 1


I couldn't figure out why my initrd or rootfs wouldn't work and had exhausted all obvious solutions.  Jumping to Occam's Razor, I decided the problem may be with the cross compiler toolchain.  So I grabbed Free Electron's (FE) embedded Linux training lab (which focuses on the BeagleBoard) and decided to start over with the cross compiler.  I made a minor change to the FE steps in that I'm using Crosstools-NG 1.8.2 which is the latest bug fix release for the 1.8.x series.

The xcc target, which builds the cross compiler toolchain for beaglebox, now builds completely.  It builds a uclibc based toolchain, however.  I've heard there may be problems with using this with X.org, but I'll have to deal with that – if necessary – when I get to it. My old build used Crosstools-NG 1.7.1 and built for glibc.  This makes the toolchain a much different beast this time around.

Using the new cross compiler toolchain, I rebuilt u-boot based on FE's instructions.  The only difference between those and my original was that my original was pulling from a different git repository.  I don't think that matters as much as having a working toolchain, however.  At least not to simply get the bootloader running.

So the updated u-boot built with the new cross compiler toolchain builds fine and boots correctly now so I know I've got a working combination of cross compiler toolchain and bootloader. I haven't tried to rebuild x-loader yet because I see no reason to since it loads my u-boot from the sd card just fine.  The BeagleBox kernel, also built with the updated compiler toolchain, boots to the point of trying to mount the rootfs. If I try the initrd it fails but I don't know why yet. If the kernel boots directly to the 2nd partition on the SD card (an ext2 rootfs created with Buildroot) I get this:

Waiting for root device /dev/mmcblk0p2…
mmc0: new SD card at address 88f7
mmcblk0: mmc0:88f7 SU01G 942 MiB
mmcblk0: p1 p2
VFS: Mounted root (ext2 filesystem) on device 179:2.
Freeing init memory: 132K

Then nothing. Looks like it's booting but there is no console output. At least not to the serial console. The bootargs look like this:

kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 rw rootfstype=ext2 rootwait

I think that's correct, but more research into the FE labs is probably needed. And I really want to know why the initrd doesn't boot. This is what I get with the initrd:

Power Management for TI OMAP3.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
regulator_init_complete: incomplete constraints, leaving VDVI on
regulator_init_complete: incomplete constraints, leaving VDAC on
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
List of all partitions:
No filesystem could mount root, tried: ext3 ext2 vfat msdos
Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

The bootargs for this one are:

Kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/ram0 rw initrd=0x81600000

The initrd is a gzipped compressed ext2 filesystem that is loaded into that memory location by u-boot. So I don't know what the problem is. At one point I did get a message that a gzipped file system was found but then I got nothing. And I can't seem to get back to that. Ugh.

This problem is detailed, for anyone that wants to follow it, on the BeagleBox issue tracker.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

One thought on “BeagleBox: small steps – better xcc, u-boot/kernel boot but rootfs still hangs