Hi Robert, Am 26.06.2015 um 21:15 schrieb Robert Nelson <[email protected]>:
> On Fri, Jun 26, 2015 at 1:32 PM, Dr. H. Nikolaus Schaller > <[email protected]> wrote: >> 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 > > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
