Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Jan 2017 19:42:01 +0100
From:      Emmanuel Vadot <manu@bidouilliste.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "Dr. Rolf Jansen" <rj@obsigna.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: BeagleBone Black MMC ordering clashes
Message-ID:  <20170107194201.5a5c5a28e58b7c58e6efd91c@bidouilliste.com>
In-Reply-To: <CANCZdfquae7ENruM3jbmfN_6Hjio0TWnFRodmGBJOJ536DtsGA@mail.gmail.com>
References:  <7D750433-59FC-4999-AC24-041683E17310@obsigna.com> <1483718084.96230.5.camel@freebsd.org> <0D800E14-799A-4926-AEF8-CD698D647E40@obsigna.com> <1483722560.96230.10.camel@freebsd.org> <F0D101AF-181B-4630-B539-C354C21538EC@obsigna.com> <CANCZdfquae7ENruM3jbmfN_6Hjio0TWnFRodmGBJOJ536DtsGA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Jan 2017 11:51:34 -0700
Warner Losh <imp@bsdimp.com> wrote:

> On Fri, Jan 6, 2017 at 11:40 AM, Dr. Rolf Jansen <rj@obsigna.com> wrote:
> >
> >> Am 06.01.2017 um 15:09 schrieb Ian Lepore <ian@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@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:
> 
> Yes. When the card isn't there, it won't respond :)
> 
> >    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.
> 
> I don't believe that it is. The u-boot image that we have currently
> supports booting off both the internal and external cards. I have two
> different BBBs that differ only in this detail. Newer versions of
> u-boot have broken this (they did a revamp of the block layer in
> 2016.07 which broke this). It's one of the reasons I've not rolled
> forward those ports yet, but I think that there's a fix coming soon so
> I'll be able to roll it all forward to 2017.01 when it's released or
> soon after. Once I've done that, we can roll all the allwinner and
> other ports forward as well..

 I've fixed the issue (which was in the API) see
https://people.freebsd.org/~manu/uboot/2017.01/0001-api-storage-Test-all-block-device-in-dev_stor_get.patch

 I've submitted the patch upstream but since 2017.01 is near I don't
think it will made it for this release.
 In u-boot >= 2016.07 on BBB, SD slot is always MMC0 and eMMC is always
MMC1.

> >> 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.
> 
> I'm happy to test as well...
> 
> Warner
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"


-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170107194201.5a5c5a28e58b7c58e6efd91c>