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 10:53:58 UTC 2018
[A note about linux booting is added.]
On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>
>> On Thu, 9 Aug 2018 23:39:35 -0700
>> Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2018-Aug-9, at 8:02 PM, Mark Millard <marklmi at yahoo.com> wrote:
>>>
>>>> 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).
>>
>> 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.
>>
>> 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.
>>>>
>>>> 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.
>>
>> We always used official DTS for aarch64.
>> What changed recently is that I added DDR52 support to the controller.
>
> 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.)
>
>>>> 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.
>>
>> Loaded use u-boot driver and it only work with HS mode iirc.
>
> Sounds likely. Good to know. Thanks.
>
>>>> 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).
>>>
>>> As for the Pine A64+ 2GB specifics . . .
>>>
>>> Quoting pine6.org about the microsd support for Pine A64:
>>>
>>> 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
>>>
>>> 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).
>>>
>>> I looked and the Power Tree page of the schematics for
>>> the Pine A64+ 2GB at:
>>>
>>> http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%20Rev%20C-20160113_Release.pdf
>>>
>>> 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
>
> Ahh, I see. All the control of such is at DC/DC1 and the rest follow
> together.
>
>>>
>>>
>>> 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)
>>>
>>> https://forum.odroid.com/download/file.php?id=1036&mode=view
>>>
>>> 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.
>>>
>>> The rest is direct connections.
>>>
>>> But the connections are for using a Hardkernel eMMC module,
>>> in my case V0.3.
>>>
>>> http://forum.odroid.com/download/file.php?id=433
>>>
>>> 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.
>>>
>>> End "for reference".
>>>
>>>
>>>
>>> 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.
>
> 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.
>
>>> From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be
>>> any of (for 3V):
>>>
>>> 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)"
>>>
>>> that match up with one of the sdcard 3.3V modes:
>>>
>>> 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.)
>>>
>>> So not bit 2 if 3V, unsure about the other two bits for 3V.
>>>
>>> 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.
>
> 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.
>
>>> 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 at 1c10000> mem 0x1c10000-0x1c10fff irq 5 disabled compat allwinner,sun50i-a64-mmc (no driver attached)
>>> simplebus0: <mmc at 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
>>>
>>>
>
Just to see what a modern linux with a modern kernel
might do I downloaded:
https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z
which is:
nightly mainline kernel master branch 4.17.y or 4.18.y
# uname -ap
Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
I put it on an e.MMC and used it to boot the pine64+ 2GB
via the e.MMC adapter and it booted fine.
# 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)
# hdparm -t /dev/mmcblk0
/dev/mmcblk0:
Timing buffered disk reads: 134 MB in 3.04 seconds = 44.03 MB/sec
# hdparm -T /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 1298 MB in 2.00 seconds = 649.15 MB/sec
For interpreting those (-t vs. -T):
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.
-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
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).
In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2:
Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V I/O
and were not restricted to just the microSDHC speed and I/O voltage
combinations by the Pine64+ 2GB.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list