Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2017 07:48:11 -0200
From:      "Dr. Rolf Jansen" <rj@obsigna.com>
To:        freebsd-arm@freebsd.org
Subject:   Re: BeagleBone Black MMC ordering clashes
Message-ID:  <6A97EEB3-6B24-48E7-959F-67F4275AFEC8@obsigna.com>
In-Reply-To: <A0506EF1-F01A-426E-AC46-D58C2155D887@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.org>:
>>>>>> On Fri, 2017-01-06 at 12:37 -0200, Dr. Rolf Jansen wrote:
>>>>>>>=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
>>>>>>> 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
>>>>>> 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).
>=20
> Ian,
>=20
> thank you very much for all you efforts.
>=20
> 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.
>=20
> 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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6A97EEB3-6B24-48E7-959F-67F4275AFEC8>