BBB vs. OMAP5432EVM Kernel 4.1: how does mapping of eMMC and SD card to /dev/mmcblk0 resp. /dev/mmcblk1 work? Why does it differ between BBB and OMAP5?

I have found in this article that the mapping is well defined:

http://thethingsystem.com/dev/Bootstrapping-the-BeagleBone-Black-with-Debian.html

"NOTE: The booted device is always device 0, i.e. mmcblk0. The internal eMMC always has the mmcblkXboot0 and mmcblkXboot1 entries. If the device is booted from eMMC the entries will be mmcblk0boot0 and mmcblk0boot1. If the device is NOT booted from eMMC the entries will be mmcblk1boot0 and mmcblk1boot1.”

On the OMAP5 EVM it appears that eMMC is always /dev/mmcblk0 and SD card is /dev/mmcblk1 independently from where I boot. So the “boot device” appears not to be stable. This makes it a little difficult to write scripts that are generic for both.

I use a 4.1 kernel with just different DT files. Otherwise the same binaries. Well, MLO and u-boot also differ, but my issue is how the kernel does the mapping.

Any hints how this is achieved on the BBB? Or is it just good luck (different boot activity sequence between AM335x and OMAP5)?

Thanks,
— hns

Using: /sys/devices/platform/

it maps them by address omap5-uevm:

480b4000.mmc = mmc0 = eMMC
480ad000.mmc = mmc1 = un-used
4809c000.mmc = mmc2 = microSD

bbb:

48060000.mmc = mmc0 = microSD
481d8000.mmc = mmc1 = eMMC

aka...

Always use an initrd with multiple platforms and use uuid's. :wink:

Regards,

Hi Robert,

I have found in this article that the mapping is well defined:

http://thethingsystem.com/dev/Bootstrapping-the-BeagleBone-Black-with-Debian.html

"NOTE: The booted device is always device 0, i.e. mmcblk0. The internal eMMC always has the mmcblkXboot0 and mmcblkXboot1 entries. If the device is booted from eMMC the entries will be mmcblk0boot0 and mmcblk0boot1. If the device is NOT booted from eMMC the entries will be mmcblk1boot0 and mmcblk1boot1.”

On the OMAP5 EVM it appears that eMMC is always /dev/mmcblk0 and SD card is /dev/mmcblk1 independently from where I boot. So the “boot device” appears not to be stable. This makes it a little difficult to write scripts that are generic for both.

I use a 4.1 kernel with just different DT files. Otherwise the same binaries. Well, MLO and u-boot also differ, but my issue is how the kernel does the mapping.

Any hints how this is achieved on the BBB? Or is it just good luck (different boot activity sequence between AM335x and OMAP5)?

Using: /sys/devices/platform/

it maps them by address omap5-uevm:

Ah, I see.

480b4000.mmc = mmc0 = eMMC
480ad000.mmc = mmc1 = un-used
4809c000.mmc = mmc2 = microSD

Here results of my latest experiments:

OMAP5432EVM (boot from µSD - can’t boot from eMMC yet with my setup):

root@gta04:~# find /sys/devices/platform/*ocp/*.mmc -print -prune -exec ls {}/mmc_host \;
/sys/devices/platform/44000000.ocp/4809c000.mmc
mmc2
/sys/devices/platform/44000000.ocp/480ad000.mmc
mmc1
/sys/devices/platform/44000000.ocp/480b4000.mmc
mmc0
root@gta04:~# fgrep mmcblk /proc/partitions
179 0 3866624 mmcblk0
179 1 193328 mmcblk0p1
179 2 3673232 mmcblk0p2
179 16 2048 mmcblk0boot1
179 8 2048 mmcblk0boot0
179 24 31166976 mmcblk1
179 25 1558345 mmcblk1p1
179 26 29608566 mmcblk1p2
root@gta04:~#

bbb:

48060000.mmc = mmc0 = microSD
481d8000.mmc = mmc1 = eMMC

aka...

BBB booted from eMMC (and a non-bootable µSD inserted):

root@gta04:~# find /sys/devices/platform/*ocp/*.mmc -print -prune -exec ls {}/mmc_host \;
/sys/devices/platform/ocp/48060000.mmc
mmc0
/sys/devices/platform/ocp/481d8000.mmc
mmc1
root@gta04:~# fgrep mmcblk /proc/partitions
179 0 3833856 mmcblk0
179 1 191689 mmcblk0p1
179 2 3642102 mmcblk0p2
179 16 1024 mmcblk0boot1
179 8 1024 mmcblk0boot0
179 24 498176 mmcblk1
179 25 7836 mmcblk1p1
179 26 490336 mmcblk1p2
root@gta04:~#

BBB booted from a µSD:

root@gta04:~# find /sys/devices/platform/*ocp/*.mmc -print -prune -exec ls {}/mmc_host \;
/sys/devices/platform/ocp/48060000.mmc
mmc0
/sys/devices/platform/ocp/481d8000.mmc
mmc1
root@gta04:~# root@gta04:~# fgrep mmcblk /proc/partitions
179 0 7822336 mmcblk0
179 1 391113 mmcblk0p1
179 2 7431158 mmcblk0p2
179 8 3833856 mmcblk1
179 9 191689 mmcblk1p1
179 10 3642102 mmcblk1p2
179 24 1024 mmcblk1boot1
179 16 1024 mmcblk1boot0
root@gta04:~#

So the mapping to mmc0, mmc1, mmc2… is defined by the hardware addresses of the MMC controllers on the SoC (and the DT nodes).
And the sequence is reversed between AM335x and OMAP5.

The other observation is that the mapping of the mmcblk device numbers is as described by the article: boot device becomes mmcblkp0 and the other becomes mmcblkp1.

But only on the BBB.

Hm. I still wonder about the magic behind this…

BR and thanks,
Nikolaus