From owner-freebsd-arm@freebsd.org Fri Jan 6 19:55:19 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28BF0CA2FE8 for ; Fri, 6 Jan 2017 19:55:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFAD1D88 for ; Fri, 6 Jan 2017 19:55:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 14191c92-d44a-11e6-8c89-112185c90658 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 14191c92-d44a-11e6-8c89-112185c90658; Fri, 06 Jan 2017 19:55:31 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v06JtAd0007055; Fri, 6 Jan 2017 12:55:10 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1483732510.96230.26.camel@freebsd.org> Subject: Re: BeagleBone Black MMC ordering clashes From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Fri, 06 Jan 2017 12:55:10 -0700 In-Reply-To: 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> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:55:19 -0000 On Fri, 2017-01-06 at 16:40 -0200, Dr. Rolf Jansen wrote: > > > > Am 06.01.2017 um 15:09 schrieb Ian Lepore : > > > > On Fri, 2017-01-06 at 14:33 -0200, Dr. Rolf Jansen wrote: > > > > > > > > > > > > > > > Am 06.01.2017 um 13:54 schrieb Ian Lepore : > > > > > > > > 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 > > > > 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. > Nope, this is all normal.  MMC cards/devices are a bit different than SD, and one of the differences is that mmc supports a special "boot partition" that's separate from the main data in the device.  So uboot tries to use the mmc boot feature, but the eMMC on the BBB isn't set up that way, so it just reports the error and moves on to booting the normal way. -- Ian > > > > 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 > > _______________________________________________ > 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 > "