BeagleBone Black MMC ordering clashes

Fri Jan 6 18:40:29 UTC 2017

> Am 06.01.2017 um 15:09 schrieb Ian Lepore <ian at freebsd.org>:
> 
> On Fri, 2017-01-06 at 14:33 -0200, Dr. Rolf Jansen wrote:
>>> 
>>> Am 06.01.2017 um 13:54 schrieb Ian Lepore <ian at freebsd.org>:
>>> 
>>> On Fri, 2017-01-06 at 12:37 -0200, Dr. Rolf Jansen wrote:
>>>> 
>>>> The BeagleBone Black comes with 2 MMC facilities, one built-in
>>>> (internal 4 GB) and one provided by a removable SD card. For
>>>> unknown
>>>> reasons the BBB defined on the removable SD card to be MMC0 and
>>>> the
>>>> internal flash memory is MMC0.
>>>> 
>>>>   1) In the first go, I dd'd the FreeBSD-12 BBB snapshot
>>>> (20161221)
>>>> onto a SD card and I was able to start the device from that card.
>>>> gpart showed me that the device identifier of the SD card is
>>>> mmcsd0
>>>> and that of the internal flash memory is mmcsd1. OK, that matches
>>>> the
>>>> already mentioned definitions.
>>>> 
>>>>   2) Now, I destroyed the partition of the internal mmcsd1 and
>>>> created a new one:
>>>> 
>>>> =>     63  7552961  mmcsd1  MBR  (3.6G)
>>>>        63     8129          - free -  (4.0M)
>>>>      8192     8192       1  fat32  [active]  (4.0M)
>>>>     16384  7536640       2  freebsd  (3.6G)
>>>> 
>>>> =>      0  7536640  mmcsd1s2  BSD  (3.6G)
>>>>         0  7536640         1  freebsd-ufs  (3.6G)
>>>> 
>>>>   3) I copied over the contents of /boot/msdos from the external
>>>> SD
>>>> card to the msdosfs on mmcsd1s1 and I installed the FreeBSD 12
>>>> snapshot on mmcsd1s1a. Restarting the device from the internal
>>>> flash
>>>> and no external SD inserted with FreeBSD 12-CURRENT works well at
>>>> the
>>>> first glance.
>>>> 
>>>>   4) However, the internal flash got now the device identifier
>>>> mmcsd0:
>>>> 
>>>>    ...
>>>>    mmc0: No compatible cards found on bus
>>>>    ...
>>>>    mmcsd0: 4GB <MMCHC MMC04G 5.8 SN 82390DEC MFG 11/1998 by 112
>>>> 0x0000> at mmc1 48.0MHz/8bit/65535-block
>>>>    ...
>>>> 
>>>> I know, this is how FreeBSD deals with the device numbering, i.e.
>>>> serial numbers starting at zero without particular meaning, and I
>>>> know that we should not rely on the number ordering.
>>>> 
>>>> But it seems that the MMC device driver does cont on the external
>>>> SD
>>>> card is at MMC0 when I insert it into the BBB once it has been
>>>> started from the internal flash. It seems to insist to assign the
>>>> device ID mmcsd0, which results in the device ordering clash
>>>> because
>>>> mmcsd0 has been assigned to the internal flash at MMC1 (s.
>>>> above).
>>>> 
>>>> In the moment, I can have both flash device active at the same
>>>> time
>>>> only when I start the BBB from the external SD.
>>>> 
>>>> I would be glad to hear suggestions on how to deal with the
>>>> issue. At
>>>> the end of the day, I want to start the device from the mostly
>>>> static
>>>> OS file system on the internal flash and keep the volatile data
>>>> on
>>>> the external SD.
>>>> 
>>>> Best regards
>>>> 
>>>> Rolf
>>> The mmcsd0 identifier will be assigned to the first mmc device
>>> found
>>> that has a valid mmc or sd card.  If  the external slot has a card
>>> in
>>> it, it will become mmcsd0 because it gets probed first.  If it has
>>> no
>>> card in it, the onboard eMMC becomes mmcsd0 because the sd slot
>>> didn't
>>> claim that device id.  There is no way to change the order of
>>> probing;
>>> probing happens in order of the devices in the chip.  The BBB
>>> makers
>>> decided to connect the external sd to the first device and the
>>> onboard
>>> eMMC to the second one.
>> Thank you for rephrasing of what I wanted to say in my initial post:
>> 
>>> 
>>>> 
>>>> I know, this is how FreeBSD deals with the device numbering, i.e.
>>>> serial numbers starting at zero without particular meaning, and I
>>>> know that we should not rely on the number ordering.
>> So, yes, this part is absolutely clear and understood.
>> 
>>> 
>>> If you want the eMMC to be the root filesystem whether there is an
>>> external sd card installed or not, the only solution is to use UFS
>>> or
>>> GPT labels instead of device names to refer to partitions in fstab.
>> I do not rely on device identifiers in fstab on non of my numerous
>> FreeBSD boxes, instead, I use the various sorts of labels ever since,
>> and I continue to do it also with the BBB installation(s).
>> 
>> # df -h
>> Filesystem         Size    Used   Avail Capacity  Mounted on
>> /dev/ufs/SYSTEM     13G    875M     11G     7%    /
>> devfs              1.0K    1.0K      0B   100%    /dev
>> /dev/label/BOOT    4.0M    924K    3.1M    23%    /boot/msdos
>> tmpfs               50M    4.0K     50M     0%    /tmp
>> 
>> However, this does not help in the given case, because the MMC device
>> driver refuses to enumerate the SD card when inserted into a BBB that
>> has been already started-up from the internal flash. So the question
>> is, how can I get the SD card activated once inserted into a running
>> system, and I would happily live with any device identifier for it,
>> even let it mmcsd77 if only the device would be accessible by this.
>> 
>> Best regards
>> 
>> Rolf
> 
> Oh, you mean you boot from eMMC without an sd card, then later when you
> insert an sd card it's not detected?  I've never tried that (I've never
> used the onboard eMMC at all), but it wouldn't surprise me that it's
> broken.

Yes, that is the problem.

> It would imply we're not handling the card-detect properly,
> probably because it's a gpio pin, and we didn't have good gpio support
> back when I was working on the TI sdcard driver.

Well, this might be related to an issues with the U-Boot/MLO facility. Remember that I replaced the factory one on the eMMC by the one from the FreeBSD 12.0-CURRENT(Beaglebone) image. Actually this allows me to boot FreeBSD from the internal eMMC without an SD card, however with a remarkable notice at the very beginning of the boot sequence:

   U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07)
   Trying to boot from MMC2
   Card did not respond to voltage select!
   *** Warning - MMC init failed, using default environment

The "Card did not respond" notice and the consecutive warning does not appear when I boot from the SD card, instead I see another one about a not supported property by the SD card: 

   U-Boot SPL 2016.05 (Dec 21 2016 - 18:05:07)
   Trying to boot from MMC1
   Card doesn't support part_switch
   MMC partition switch failed
   *** Warning - MMC partition switch failed, using default environment

Perhaps U-Boot disables/deactivates/turns-off something on the board already in the very early stage. Perhaps I need to adapt the U-Boot image for internal eMMC booting.

> Yep, I just looked at the source, and there's no handling for gpio-
> based sd card detect in the TI driver.  Maybe I can find some time this
> weekend to add it, now that we have a better gpio infrastructure for
> drivers to use.

Many thanks in advance for spending your time.

Best regards

Rolf