Finally got a vanilla kernel to build and boot on my BBB:

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.

And, ethernet works.

@Felipe_Balbi guess it is mmcblk num ?

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 believe it is probably due to probe defferal of mmc instance.

@Nishanth_Menon it’s a Side effect of DT, sane numbering goes out the window

@Koen_Kooi it is possible to solve it - I had fixed i2c bus numbering earlier. mmc, I had noticed, but not fixed…

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.

@Koen_Kooi @Felipe_Balbi http://pastebin.mozilla.org/3701134 -> I got mmc host renumbered, but the block devices seem to follow a completely different numbering scheme in drivers/mmc/card/block.c! Grrrrr… (&^(%^%&&^% mmc!

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.

Again fwiw, /etc/fstab on this system contains UUIDs not device names (to avoid this type of thing). Obviously this a step earlier (cmdline parsing).

@Bert_Lindner then you should have uEnv.txt override mmcroot (or so…) with root=UUID=… or root=LABEL=…

oh of course… thanks, will do.

@Koen_Kooi @David_Anders perhaps moving forward beagle images can augment uEnv.txt with UUID=… passing for rootfs?

That fixes it for me. Silly, totally overlooked the kernel cmdline option. Especially since I’d been posting https://plus.google.com/112271108970013300166/posts/7KUQRj2P4iD earlier. Duh. Getting rusty.

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.