BBB: schizophrenic MMC names

[Gary Thomas]

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?

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

[Robert Nelson]

On Thu, Nov 3, 2016 at 7:26 AM, Gary Thomas <ga...@mlbassoc.com> wrote:
> 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,

--
Robert Nelson
https://rcn-ee.com/

[Gary Thomas]

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

[Robert Nelson]

On Thu, Nov 3, 2016 at 8:55 AM, Gary Thomas <ga...@mlbassoc.com> wrote:
> On 2016-11-03 14:38, Robert Nelson wrote:
>>
>> On Thu, Nov 3, 2016 at 7:26 AM, Gary Thomas <ga...@mlbassoc.com> wrote:
>>>
>>> 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.
>
>
> 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

[Gary Thomas]

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

[Robert Nelson]

> 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

[Gary Thomas]

On 2016-11-03 15:11, Robert Nelson wrote:
>> 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

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.

[Robert Nelson]

On Thu, Nov 3, 2016 at 9:18 AM, Gary Thomas <ga...@mlbassoc.com> wrote:
> On 2016-11-03 15:11, Robert Nelson wrote:
>>>
>>> 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
>
>
> 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

[Gary Thomas]

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.

[William Hermans]

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 ;)

[Robert Nelson]

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. ;)

[William Hermans]

On Thu, Nov 3, 2016 at 2:19 PM, Robert Nelson <robert...@gmail.com> wrote:

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. ;)

heheh, excellent. That worked out good then ;)