BeagleBone Black MMC ordering clashes
Dr. Rolf Jansen
rj at obsigna.com
Mon Jan 9 02:32:55 UTC 2017
> Am 09.01.2017 um 00:15 schrieb Ian Lepore <ian at freebsd.org>:
>
> On Fri, 2017-01-06 at 16:40 -0200, Dr. Rolf Jansen wrote:
>>>
>>> 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
>
> Okay, I got this all done and tested this weekend, and just committed
> all the changes for am335x (beaglebone) and imx6 (wandboard, cubox,
> etc). It's pretty easy to convert an existing driver, so I expect
> other boards with sdhci-compatible hardware to get updated soon too.
>
> If you are set up to build custom kernels, you just need to update your
> sources to r311736 or later and rebuild. Otherwise you can wait until
> the next 12-current snapshot is available (I think those still come out
> weekly).
Ian,
thank you very much for all you efforts.
My x86-machines are running custom kernels and personally I am set building it, however, I am in the course of porting my own software to the BeagleBone, and I learned already that compiling huge code bases on it is not fun at all.
At some point in time in the near future, I need to setup ARM cross building on one of my faster x86 machines. For the time being, I will wait for the next snapshot, and of course I will report my findings.
Best regards
Rolf
More information about the freebsd-arm
mailing list