Date: Fri, 10 Aug 2018 08:59:32 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Mark Millard <marklmi@yahoo.com> Cc: Marius Strobl <marius@freebsd.org>, 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: <20180810085932.248050e3383151efb41c967c@bidouilliste.com> In-Reply-To: <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> 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> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Aug 2018 23:39:35 -0700
Mark Millard <marklmi@yahoo.com> wrote:
> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>=20
> > On 2018-Aug-9, at 3:00 PM, Marius Strobl <marius at freebsd.org> wrote:
> >=20
> >> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote:
> >>> . . .
> >>=20
> >> 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 (apparentl=
y,
> >> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO).
Yes, the first controller is usually used for SD, second for SDIO and
the third for eMMC. I don't know if any of them can be used for any of
the function or if they are intended to be used for a specific mode.
> >> 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.=20
That seems the easiest fix.
> >> 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.
> >=20
> > Thanks for the notes.
> >=20
> > Clearly there is something that I'm missing because:
> >=20
> > *) 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.
We always used official DTS for aarch64.
What changed recently is that I added DDR52 support to the controller.
> > It had been my standard configuration for some time before
> > I made the jump to a more modern environment.
> >=20
> > As for now:
> >=20
> > A) u-boot successfully gets the loader from the e.MCC over the sdcard
> > adapter plugged into the Pine64+ 2GB's sdracard slot.
> >=20
> > B) The loader successfully loads the kernel from the e.MCC over the
> > sdcard adapter plugged into the Pine64+ 2GB's sdracard slot.
Loaded use u-boot driver and it only work with HS mode iirc.
> > C) The first failure is from the kernel attempting to deal with
> > the e.MCC (via the adapter).
> >=20
> > 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.
> >=20
> > 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).
>=20
> As for the Pine A64+ 2GB specifics . . .
>=20
> Quoting pine6.org about the microsd support for Pine A64:
>=20
> QUOTE
> The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this=
means the largest capacity is 256GB. Please note that if a microSD card is=
formatted as an FAT32 file format, the maximum capacity is 32GB.
> END QUOTE
>=20
> I would expect supporting SDHC and SDXC to mean support for
> various 1.8V modes of use: Such required if UHS-I is
> supported (UHS50 or UHS104). Also DDR50 is required for
> microSD (but not Standard SD). This would seem to match what
> the schematics suggest to me (see below).
>=20
> I looked and the Power Tree page of the schematics for
> the Pine A64+ 2GB at:
>=20
> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%2=
0Rev%20C-20160113_Release.pdf
>=20
> and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to
> "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page
> shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows
> VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to
> VDD. T-CARD looks to me like the sdcard slot connections.
> (Yes: the mix of T-CADD and T-CARD naming is as in the
> document.) (I'm not listing the capacitor and such.)
VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO,
VCC3V3-USB etc .... so it needs to stay at 3.3V
>=20
>=20
> For reference, for the e.MCC adaptor for anyone that cares:
> (things like "3.3V" are as labeled in those schematics,
> whatever the actual voltage of use for some mode of use)
>=20
> https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview
>=20
> shows a 49.9K resister in line between 3.3V and RSTN at the
> e.MMC end of things. It also shows a 10uF capacitor between
> 3.3V and ground on VDD from the micrSD end of things.
>=20
> The rest is direct connections.
>=20
> But the connections are for using a Hardkernel eMMC module,
> in my case V0.3.
>=20
> http://forum.odroid.com/download/file.php?id=3D433
>=20
> is for that module. Other than some parallel capacitors to
> ground off of VDD and VDDF, and one off of VDDI, it looks
> like direct connections there to the e.MMC device as well.
>=20
> End "for reference".
>=20
>=20
>=20
> The above does not say the the loader and u-boot are using
> a 1.8 V mode instead of a 3.3V mode of operation for the
> sdcard interface, even if 1.8V is possible.
It doesn't, see
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner=
/sun50i-a64-pine64.dts#L151
Again, 1.8V is in theory possible, but I wouldn't try that on my
boards.
> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
> any of (for 3V):
>=20
> Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V
> Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltag=
e(s)"
> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltag=
e(s)"
>=20
> that match up with one of the sdcard 3.3V modes:
>=20
> UHS-I modes:
> DS: Default Speed up to 25 MHz 3.3V signaling
> HS: High Speed up to 50 MHz 3.3V signaling
> (Looks like the signal timings are distinct from 1.8 V modes.)
>=20
> So not bit 2 if 3V, unsure about the other two bits for 3V.
>=20
> In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1
> UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does
> boot from) the kernel seems to pick the UHS-I HS mode,
> instead of SDR50 or DDR50 or higher:
Because SDR50 or DDR50 needs 1.8V signaling.
So the maximum mode that we can select is HS at 50Mhz which is
using 3.3V signaling.
> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff=
irq 4 on simplebus0
> aw_mmc0: vmmc-supply regulator found
> mmc0: <MMC/SD bus> on aw_mmc0
> random: harvesting attach, 8 bytes (4 bits) from mmc0
> random: harvesting attach, 8 bytes (4 bits) from aw_mmc0
> simplebus0: <mmc@1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat a=
llwinner,sun50i-a64-mmc (no driver attached)
> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled compat a=
llwinner,sun50i-a64-emmc (no driver attached)
> . . .
> aw_mmc0: Powering up sd/mmc
> mmc0: Probing bus
> . . .
> mmc0: SD 2.0 interface conditions: OK
> mmc0: SD probe: OK (OCR: 0x40ff8000)
> mmc0: Current OCR: 0x00ff8000
> mmc0: Probing cards
> mmc0: New card detected (CID 0353445345333247800978130301171d)
> mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3)
> mmc0: Card at relative address 0xaaaa added:
> mmc0: card: SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD
> mmc0: quirks: 0
> mmc0: bus: 4bit, 50MHz (high speed timing)
> mmc0: memory: 62333952 blocks, erase sector 8192 blocks
> mmc0: setting transfer rate to 50.000MHz (high speed timing)
> mmcsd0: 32GB <SDHC SE32G 8.0 SN <REPLACED> MFG 07/2017 by 3 SD> at mmc0 5=
0.0MHz/4bit/32768-block
> random: harvesting attach, 8 bytes (4 bits) from mmcsd0
> GEOM: new disk mmcsd0
> mmc0: setting bus width to 4 bits high speed timing
> mmc0: ACMD42 failed, RESULT: 4
> mmc0: Card at relative address 43690 failed to set bus width
>=20
>=20
>=20
>=20
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
--=20
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180810085932.248050e3383151efb41c967c>