Date: Tue, 21 Feb 2017 20:57:58 -0700 From: Ian Lepore <ian@freebsd.org> To: "Dr. Rolf Jansen" <rj@obsigna.com>, freebsd-arm@freebsd.org Subject: Re: BeagleBone Black MMC ordering clashes Message-ID: <1487735878.73144.140.camel@freebsd.org> In-Reply-To: <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.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> <1483928120.96230.61.camel@freebsd.org> <A0506EF1-F01A-426E-AC46-D58C2155D887@obsigna.com> <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2017-02-16 at 07:48 -0200, Dr. Rolf Jansen wrote: > Am 09.01.2017 um 00:32 schrieb Dr. Rolf Jansen <rj@obsigna.com>: > > > > > > > > Am 09.01.2017 um 00:15 schrieb Ian Lepore <ian@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@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.or > > > > > > > g>: > > > > > > > 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/msd > > > > > > os > > > > > > 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. > I tried the FreeBSD 12 snapshot for the BeagleBone from 2017-02-10, > and it does not work at all. > > The new u-boot is complaining that it cannot find a configured device > and drops into the console, and I needed to revert to the previous u- > boot, i.e. the one that was on the snapshot from 2017-01-05. > > With that the new kernel loaded, however, when trying to mount root, > kernel's vfs complained that the indicated device /dev/mmcsd0s2a is > read-only, and booting was not finished. > > I gave up with FreeBSD-12.0-CURRENT-arm-armv6-BEAGLEBONE-20170210- > r313561, and I will try again with the next snapshot. > > Best regards > > Rolf Sorry for the long delay on this. I had flagged this mail for followup but somehow forgot to ever do so. It turns out that read-only problem is a bug I introduced along with the card-detect changes. I've just committed a fix in r314071, which should hopefully show up in the next shapshot build. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1487735878.73144.140.camel>