Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted

Mark Millard marklmi at yahoo.com
Fri Aug 10 03:02:51 UTC 2018


On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:

> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
>> . . .
> 
> It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However,
> with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD
> DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for
> example figure 3-14 in the SD physical layer specification version
> 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with
> SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was
> written, Linux didn't support the former either so I saw no point in
> adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR
> a bit later in January 2017, though).
> While I have no problem with support for DDR52 at 3.0 V VCCQ being
> added to mmc(4), I doubt that will solve your problem given that Linux
> doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+
> or any other Allwinner gear. Based on what I could figure out about
> Allwinner MMC controllers, their capabilities actually differ depending
> on the particular instance of MMC controller of a given SoC (apparently,
> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
> So I guess what needs to be done is to let aw_mmc(4) announce and
> support different sets of capabilities depending on which instance of
> the controller it is driving. For your adapter this likely means that
> high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD
> slot complies with the SD physical layer specification if 1.8 V VCCQ
> isn't supported by the particular board.

Thanks for the notes.

Clearly there is something that I'm missing because:

*) Historically (before the switch to official dts's and such)
   I was able to boot, buildworld, buildkernel, poudreire-devel
   and the like booting from the e.MCC over the sdcard
   adapter plugged into the Pine64+ 2GB's sdcard slot.

   It had been my standard configuration for some time before
   I made the jump to a more modern environment.

As for now:

A) u-boot successfully gets the loader from the e.MCC over the sdcard
   adapter plugged into the Pine64+ 2GB's sdracard slot.

B) The loader successfully loads the kernel from the e.MCC over the
   sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.

C) The first failure is from the kernel attempting to deal with
   the e.MCC (via the adapter).

I may have read into this (and the messages from boot -v and what
was said about them) the wrong assumptions about what is wrong.

What I can say is that the issue looks to be specific to the
FreeBSD kernel but not to the prior loader (nor to u-boot).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list