BBB: schizophrenic MMC names

On my BeagleBoneBlack with a system installed in eMMC, I get
different device names for the MMC devices, depending on whether
or not there is a SD card installed at boot time.

With SD card installed:
   MMC/SD slot = mmcblk0
   eMMC = mmcblk1

Without SD card installed (at boot):
   MMC/SD slot = mmcblk1 if inserted after boot
   eMMC = mmcblk0

Is there some way to configure this to be consistent? i.e.
   MMC/SD slot = mmcblk0 (regardless of the presence of an SD card)
   eMMC = mmcblk1
which matches the device enumeration in U-Boot?

If not, what's the rationale behind the madness?

First valid device probed is mmc0...

This changed in v4.5.x/v4.6.x timeframe and we backported it to v4.4.x.

Regards,

Do you recall the changeset, in case I'd like to undo it? I'm trying
to make the BBB behave like all the other platforms I support.

Thanks for any pointers

For our "v4.4.x-ti" just revert:

https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.4.y/patches/x15/fixes/0004-mmc-block-Use-the-mmc-host-device-index-as-the-mmcbl.patch

On mainline (v4.5.x+): either get use to it, or revert:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc/core?id=520bd7a8b4152aacfbd34eb7f7a447354b631039
&
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/mmc?id=9aaf3437aa72ed5370bf32c99580a3fa2c330e3d

Regards,

Thanks, I'll investigate these changes.

Based on the comment "first valid device probed", is there any way to
force the eMMC to be the first valid device (I might be able to live with
the fact that U-Boot sees the eMMC as dev 1 but Linux as dev 0 if it was
always consistent).

Again, thanks for any ideas/pointers

Thanks, I'll investigate these changes.

Based on the comment "first valid device probed", is there any way to
force the eMMC to be the first valid device (I might be able to live with
the fact that U-Boot sees the eMMC as dev 1 but Linux as dev 0 if it was
always consistent).

Again, thanks for any ideas/pointers

Going forward, it will be consistent..

microSD = ti mmc1 port -> mmc0 kernel
eMMC = ti mmc2 port -> mmc1 kernel

Regards,

What does "going forward" mean? I'm not seeing this, using
the latest Debian+U-Boot

What you've outlined above would be ideal, I'm just curious
how to get it.

Well let's see:

I merged it into our tree on Jul 19, 2016, at tag: 4.4.15-ti-r37

If your running something older then just:

cd /opt/scripts/tools/ ; git pull ; sudo ./update_kernel.sh

Regards,

That's fine and good, but I can't test it running eMMC only (no SD)
as the image can't be flashed to my (revA) board that only
has 2GB eMMC, so I can't really test anything using these
tools :frowning:

Reverting the previously mentioned change does make things
work for me though.

Unless I'm mistaken. That script only pulls in the latest kernel + initrd +
modules, etc. Needed to boot the new kernel. Typically we're talking . . .

william@beaglebone:~$ *du -h /boot/*`uname -r`*
3.2M /boot/System.map-4.4.14-ti-r34
144K /boot/config-4.4.14-ti-r34
4.5M /boot/initrd.img-4.4.14-ti-r34
7.5M /boot/vmlinuz-4.4.14-ti-r34

william@beaglebone:~$ *du -h /boot/dtbs/*`uname -r`*
13M /boot/dtbs/4.4.14-ti-r34

william@beaglebone:~$ *du -h /lib/modules/`uname -r`*
. . .
66M /lib/modules/4.4.14-ti-r34

Roughly 100M, plus you'll need around another 60-70M for the package as it
downloads / installs. After which it could be purged. Plus maybe a little
extra I'm forgetting.

Anyway, if that script wont work you can always run

$ apt-cache search linux-image |grep <whatever version you want>

Another thing to keep in mind. Is that lately ( as in the last several
months atleast ) the kernel modules have been built with debugging symbols
built in . . . which increases their size drastically. Or so I've been
told. Personally, I think this is something that needs being done outside
of released images . . . but I'm not the one who has the honor of building
the kernel images weekly . . . thank god :wink:

CONFIG_DEBUG_INFO is now disabled... The dbg symbols, while smaller
then they use to be, still just ended up taking up too much server
space. :wink:

Regards,