Date: Mon, 9 Jan 2017 00:32:46 -0200 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: freebsd-arm@freebsd.org Subject: Re: BeagleBone Black MMC ordering clashes Message-ID: <A0506EF1-F01A-426E-AC46-D58C2155D887@obsigna.com> In-Reply-To: <1483928120.96230.61.camel@freebsd.org> 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> <1483928120.96230.61.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 09.01.2017 um 00:15 schrieb Ian Lepore <ian@freebsd.org>: >=20 > On Fri, 2017-01-06 at 16:40 -0200, Dr. Rolf Jansen wrote: >>>=20 >>> Am 06.01.2017 um 15:09 schrieb Ian Lepore <ian@freebsd.org>: >>>=20 >>> On Fri, 2017-01-06 at 14:33 -0200, Dr. Rolf Jansen wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> Am 06.01.2017 um 13:54 schrieb Ian Lepore <ian@freebsd.org>: >>>>>=20 >>>>> On Fri, 2017-01-06 at 12:37 -0200, Dr. Rolf Jansen wrote: >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 2) Now, I destroyed the partition of the internal mmcsd1 >>>>>> and >>>>>> created a new one: >>>>>>=20 >>>>>> =3D> 63 7552961 mmcsd1 MBR (3.6G) >>>>>> 63 8129 - free - (4.0M) >>>>>> 8192 8192 1 fat32 [active] (4.0M) >>>>>> 16384 7536640 2 freebsd (3.6G) >>>>>>=20 >>>>>> =3D> 0 7536640 mmcsd1s2 BSD (3.6G) >>>>>> 0 7536640 1 freebsd-ufs (3.6G) >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 4) However, the internal flash got now the device >>>>>> identifier >>>>>> mmcsd0: >>>>>>=20 >>>>>> ... >>>>>> 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 >>>>>> ... >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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). >>>>>>=20 >>>>>> In the moment, I can have both flash device active at the >>>>>> same >>>>>> time >>>>>> only when I start the BBB from the external SD. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Best regards >>>>>>=20 >>>>>> 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: >>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>=20 >>>>>=20 >>>>>=20 >>>>> 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). >>>>=20 >>>> # 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 >>>>=20 >>>> 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. >>>>=20 >>>> Best regards >>>>=20 >>>> 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. >>=20 >>>=20 >>> 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: >>=20 >> 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 >>=20 >> 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:=20 >>=20 >> 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 >>=20 >> 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. >>=20 >>>=20 >>> 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. >>=20 >> Best regards >>=20 >> Rolf >=20 > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A0506EF1-F01A-426E-AC46-D58C2155D887>