Finally got a vanilla kernel to build and boot on my BBB:
Linux version 3.13.0-rc2 (root@bbb20131022)(gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1 Sat Nov 30 18:33:29 UTC 2013
It’s not hugely practical, there is no capemgr support and MMC enumeration is a bit weird (it currently won’t boot with an SD card in the slot [edit: it will if you use root=UUID= in uEnv.txt]). But still, I like the idea of being able to natively compile a stock kernel and have it run.
If I boot, from eMMC, with an SD card in the slot, this is what happens - kernel somehow expects rootfs at /dev/mmcbl10p2:
==
Mounting root file system …
Gave up waiting for root device. Common problems:
Boot args (cat /proc/cmdline)
Check rootdelay= (did the system wait long enough?)
Check root= (did the system wait for the right device?)
Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mmcbl10p2 does not exist. Dropping to a shell!
Bu-in shell (ash)
Enter ‘help’ for a list of built-in commands.
(initramfs) cat /proc/cmdline
console=ttyO0,115200n8 root=/dev/mmcbl10p2 ro rootfstype=ext4 rootwait fixrtc
==
Without an SD it boots normally and cmdline looks such (as expected):
console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc
I’m sorry guys, at least part of this is a red herring, because the SD card was also bootable (even though that should have booted fine using the root partition on there). The kernel that could n’t find ‘mmcbl10p2’ was an older one. I had been convinced the SD was not bootable (use yet another card to occasionally boot off of).
With an empty non bootable SD card in there (just a single vfat partition), it still doesn’t find a rootfs but it is now looking for mmcblk0p2. (ALERT! /dev/mmcblk0p2 does not exist. Dropping to a shell!)
This goes for both vanilla 3.13.0-rc2 and @Robert_Nelson s 3.12.2-bone9. Both do boot fine without SD card present.
@Bert_Lindner sigh, it’s got nothing to do with DT per se. It’s about how devices are getting their indices during boot. I will try to dig out a old patch that can fix it, but to fix it right will take another round of bike shedding on LKML.
http://pastebin.mozilla.org/3701140 is the output with the above patch -> Obviously to ensure that block device numbering is consistent no matter the probe priority, drivers/mmc/card/block.c should be able to consider numbering base. However, I do recollect @Tom_Rini telling me a few months(?) back that folks hate renumbering block devices…
@Pantelis_Antoniou if you have that patch around, I’d be happy to try it out… i am a bit antsy touching block.c with the comments indicating some magic stuff there… wondering if SDIO will be alive at that point.
@Nishanth_Menon yes, sigh. Embedded hasn’t been high on UUID/LABEL mounting for a long time so, yes, lots of rootfs’ default to block mounting in /etc/fstab and most bootloaders default to passing some variant on root=/dev/mmcblk0p2 along.
@Nishanth_Menon The patch’s got nothing to do with block or any specific driver subsystem. What the patch does is to use an index property on each device node that defines it in order to set the platform device index of the instantiated device. That way all the devices get the fixed index that the TRM defines.
On my wishlist for Newtonmas: root=OF_ALIAS=emmc
You probably need a bit more to actually specify the partition, but basically I’d just walk kobejcts from block devices upwards.