Date: Fri, 10 Aug 2018 04:45:36 -0700 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com>, Marius Strobl <marius@freebsd.org> Cc: 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: <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> In-Reply-To: <DA7A2889-CD88-425C-A65D-9D6C6B5A8C92@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> <20180810085932.248050e3383151efb41c967c@bidouilliste.com> <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> <DA7A2889-CD88-425C-A65D-9D6C6B5A8C92@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[A note about CARD_TYPE/DEVICE_TYPE is added.]
On 2018-Aug-10, at 3:53 AM, Mark Millard <marklmi at yahoo.com> wrote:
> [A note about linux booting is added.]
>=20
> On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> wrote:
>=20
>> On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot <manu at bidouilliste.com> =
wrote:
>>=20
>>> On Thu, 9 Aug 2018 23:39:35 -0700
>>> Mark Millard <marklmi at yahoo.com> wrote:
>>>=20
>>>> 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 =
(apparently,
>>>>>> they are intended for different purposes, i. e. eMMC, eSD, SD, =
SDIO).
>>>=20
>>> 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.
>>>=20
>>>>>> 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
>>>=20
>>> That seems the easiest fix.
>>>=20
>>>>>> 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.
>>>=20
>>> We always used official DTS for aarch64.
>>> What changed recently is that I added DDR52 support to the =
controller.
>>=20
>> My quick attempt at identifying the history point was poor. It
>> looks like I should have referenced before and during the ccu-ng =
switch,
>> before and during the USB being temporarily unsupported in the
>> similar time frame. I held back to materials that allowed USB use and
>> did not update past that until just recently. (This is still just a =
summary,
>> not the full history of my builds based on the older materials in =
this area.
>> But it should be good enough.)
>>=20
>>>>> 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.
>>>=20
>>> Loaded use u-boot driver and it only work with HS mode iirc.
>>=20
>> Sounds likely. Good to know. Thanks.
>>=20
>>>>> 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%20=
Rev%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.)
>>>=20
>>> 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
>> Ahh, I see. All the control of such is at DC/DC1 and the rest follow
>> together.
>>=20
>>>>=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.
>>>=20
>>> It doesn't, see
>>> =
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinne=
r/sun50i-a64-pine64.dts#L151
>>>=20
>>> Again, 1.8V is in theory possible, but I wouldn't try that on my
>>> boards.
>>=20
>> So it looks like if the e.MMC on an adapter card were to be =
supported,
>> it would be via Bit 1 or Bit 0 below, much like u-boot is apparently
>> doing.
>>=20
>>>> =46rom 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 =
voltage(s)"
>>>> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device =
voltage(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:
>>>=20
>>> 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.
>>=20
>> Okay. It would be nice if the e.MMC on an sdcard adapter also did so
>> someday, somewhat like u-boot apparently does (up to clock rate
>> differences?). Even going slower, I'd prefer e.MMC media.
>>=20
>>>> 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 allwinner,sun50i-a64-mmc (no driver attached)
>>>> simplebus0: <mmc@1c11000> mem 0x1c11000-0x1c11fff irq 6 disabled =
compat allwinner,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 50.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
>=20
> Just to see what a modern linux with a modern kernel
> might do I downloaded:
>=20
> https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z
>=20
> which is:
>=20
> nightly mainline kernel master branch 4.17.y or 4.18.y
>=20
> # uname -ap
> Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 =
aarch64 aarch64 aarch64 GNU/Linux
>=20
> I put it on an e.MMC and used it to boot the pine64+ 2GB
> via the e.MMC adapter and it booted fine.
>=20
> # cat /sys/kernel/debug/mmc0/ios
> clock: 52000000 Hz
> actual clock: 50000000 Hz
> vdd: 21 (3.3 ~ 3.4 V)
> bus mode: 2 (push-pull)
> chip select: 0 (don't care)
> power mode: 2 (on)
> bus width: 2 (4 bits)
> timing spec: 8 (mmc DDR52)
> signal voltage: 0 (3.30 V)
> driver type: 0 (driver type B)
>=20
> # hdparm -t /dev/mmcblk0
>=20
> /dev/mmcblk0:
> Timing buffered disk reads: 134 MB in 3.04 seconds =3D 44.03 MB/sec
>=20
> # hdparm -T /dev/mmcblk0
>=20
> /dev/mmcblk0:
> Timing cached reads: 1298 MB in 2.00 seconds =3D 649.15 MB/sec
>=20
> For interpreting those (-t vs. -T):
>=20
> QUOTE
> -t Perform timings of device reads for benchmark and =
comparison purposes. For meaningful results, this operation should be =
repeated 2-3 times on an otherwise inactive system (no other
> active processes) with at least a couple of megabytes =
of free memory. This displays the speed of reading through the buffer =
cache to the disk without any prior caching of data.
> This measurement is an indication of how fast the drive =
can sustain sequential data reads under Linux, without any filesystem =
overhead. To ensure accurate measurements, the buffer
> cache is flushed during the processing of -t using the =
BLKFLSBUF ioctl.
>=20
> -T Perform timings of cache reads for benchmark and =
comparison purposes. For meaningful results, this operation should be =
repeated 2-3 times on an otherwise inactive system (no other
> active processes) with at least a couple of megabytes of =
free memory. This displays the speed of reading directly from the Linux =
buffer cache without disk access. This measurement
> is essentially an indication of the throughput of the =
processor, cache, and memory of the system under test.
> END QUOTE
>=20
> So it appears to me that the DDR52 over 4 data bits is real,
> despite the apparent 3.3V usage for VCCQ (and so VCC as well).
>=20
> In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2:
>=20
> Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V =
I/O
>=20
> and were not restricted to just the microSDHC speed and I/O voltage
> combinations by the Pine64+ 2GB.
I discovered another command:
# mmc extcsd read /dev/mmcblk0 | more
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Extended CSD rev 1.8 (MMC 5.1)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
. . .
Card Type [CARD_TYPE: 0x57]
HS200 Single Data Rate eMMC @200MHz 1.8VI/O
HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O
HS eMMC @52MHz - at rated device voltage(s)
HS eMMC @26MHz - at rated device voltage(s)
. . .
Which is interesting by having 5 bits set in 0x57
but only listing 4 of the alternatives. The missing
one would be for:
HS400 DDR e.MMC @ 200 MHz - 1.8V I/O
(In essence, no 1.2V alternative is supported.)
It did not pick to attempt a 1.8V-only mode but
instead to pick the fastest of the 3V-compatibile
modes (in e.MCC terms).
=3D=3D=3D
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?33AFF697-FB1E-4349-93C7-888C184CBBD4>