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>