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
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
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
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.
Regards,