Date: Thu, 9 Aug 2018 20:02:38 -0700 From: Mark Millard <marklmi@yahoo.com> To: Marius Strobl <marius@freebsd.org> Cc: Emmanuel Vadot <manu@bidouilliste.com>, Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted Message-ID: <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> In-Reply-To: <20180809220012.GU21523@alchemy.franken.de> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <D83A4360-AF95-4299-95C0-BBC677EF7633@yahoo.com> <20180809220012.GU21523@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22CDDB1E-48D5-4F60-9345-78992867299F>