BeagleBone Black MMC ordering clashes
Ian Lepore
ian at freebsd.org
Wed Feb 22 03:58:01 UTC 2017
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 at obsigna.com>:
> >
> > >
> > > Am 09.01.2017 um 00:15 schrieb Ian Lepore <ian at 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 at 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 at 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
More information about the freebsd-arm
mailing list