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

Wed Aug 8 09:13:17 UTC 2018

On 2018-Aug-7, at 6:25 PM, Mark Millard <marklmi at yahoo.com> wrote:

> [FYI: I duplicated the e.MMC to a microsdhc, made minor
> changes, and tested booting: it did.]
> 
> On 2018-Aug-6, at 11:39 AM, Mark Millard <marklmi at yahoo.com> wrote:
> 
>> [Fixing a confusing "slower" reference . . .]
>> 
>> On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>> 
>>>> On Mon, 6 Aug 2018 10:12:43 -0700
>>>> Mark Millard <marklmi at yahoo.com> wrote:
>>>> 
>>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>>> 
>>>>>> On Mon, 6 Aug 2018 02:48:57 -0700
>>>>>> Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:
>>>>>> 
>>>>>>> I amd64 -> aarch64 cross built -r337347 and installed it
>>>>>>> (and 2018.07 u-boot-sunxi-with-spl.bin and loader.efi as
>>>>>>> bootaa64.efi) as an update. My attempted synchronization
>>>>>>> of loader.conf and ttys and devd.conf may be incorrect.
>>>>>>> (Previous to this the Pine64+ 2GB seemed to be working
>>>>>>> okay but it was at a very old build.)
>>>>>>> 
>>>>>>> The kernel config has GENERIC included but the various
>>>>>>> debug features disabled. (My typical operating
>>>>>>> environment.)
>>>>>>> 
>>>>>>> For all I know what the below shows might be expected
>>>>>>> at this point. The kernel seems to have problems with
>>>>>>> the MMC (that the kernel was loaded from). No other
>>>>>>> media are attached. mmcsd0 is really an 128 GiByte
>>>>>>> emmc on an adapter. (This historically worked for me.)
>>>>>> 
>>>>>> emmc to sd ? that's weird ...
>>>>> 
>>>>> An example of the adapter I've used for this is:
>>>>> 
>>>>> https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-adapter
>>>> 
>>>> So this is a passive adapter, maybe that's something that should work
>>>> but it's definitly is something that calls for problems.
>>>> 
>>>>> emmc is multi-mode for its allowed modes of operation. Thus
>>>>> its ability to frequently be used this way, such as via HS200.
>>>>> emmc is commonly more robust as I understand.
>>>> 
>>>> I didn't understand a word.
>>> 
>>> I got the HS200 reference from the boot -v output. Such is currently from the
>>> JEDEC standard "JESD84-B51 e.MMC v5.1" from looking around . (JEDEC
>>> members have free access, others do not.)
>>> 
>>> The output reported:
>>> 
>>> mmc0: Card at relative address 0x0002 added:
>>> mmc0:  card: MMCHC DJNB4R 0.7 SN <REPLACED> MFG 06/2016 by 21 0x0000
>>> mmc0:  quirks: 0
>>> mmc0:  bus: 4bit, 200MHz (HS200 timing)
>>> mmc0:  memory: 244277248 blocks, erase sector 1024 blocks
>>> 
>>> The e.MMC bus speed modes with I/O Voltage 3V allowed are:
>>> 
>>> Backwards Compatibility with legacy MMC card, data rate single, 3V allowed, bus widths 1,4,8, 0-26 MHz
>>> 
>>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 MHz
>>> 
>>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz
>>> 
>>> (The last being the fastest for maximum transfer rate with 3V.)
>>> 
>>> There is another 1.8V/1.2V mode: HS400 that is dual data rate and always 8 bit,
>>> unlike HS200's single data rate and 4 or 8 bit. Both are 0-200 MHz. HS400
>>> is optional and sufficiently old e.MMC standard vintages would likely not
>>> even have it.
>>> 
>>> So a slower 3.? V mode of use used to be selected (based on the constraints
>>> on the board's voltages in some way, possibly hard coded).
>> 
>> "slower" lacks context: I should have said . . .
>> 
>> "a slower than HS200 3.? V mode"
>> 
>> As I remember, the 3V range is from 2.7 V to 3.6 V or some such.
>> So 3.3 V would be in range, at least if I remember right.
>> 
>>>>> 
>>>>> (I had to modify the case the pine64+ 2GB is in in order for
>>>>> the adapter/emmc combination to fit in all the way.)
>>>>> 
>>> 
> 
> I duplicated the e.MMC partition content to a microsdhc
> for each partition (and u-boot but no swap), made minor
> changes, and tested booting. It booted, with messages
> like:
> 
> Trying to boot from MMC1
> . . .
> MMC:   SUNXI SD/MMC: 0
> . . .
> mmc0 is current device
> Scanning mmc 0:1...
> Found EFI removable media binary efi/boot/bootaa64.efi
> . . .
> Scanning disks on mmc...
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 3 disks
> . . .
> aw_mmc0: <Allwinner Integrated MMC/SD controller> mem 0x1c0f000-0x1c0ffff irq 4 on simplebus0
> mmc0: <MMC/SD bus> on aw_mmc0
> . . .
> mmcsd0: 32GB <SDHC SE32G 8.0 SN 09781303 MFG 07/2017 by 3 SD> at mmc0 50.0MHz/4bit/32768-block
> mmc0: ACMD42 failed, RESULT: 4
> mmc0: Card at relative address 43690 failed to set bus width
> 
> 
> 
> Prior to the last 2 lines above looks normal to me for the
> MMC material.
> 
> So the only issue seems to be having an e.MCC device and
> how it is handled (mode of attempted operation, including
> voltage), given the limitations of the Pine64+ 2GB board.
> 
> My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD
> e.MMC reader to be tried via:
> 
> High Speed DDR mode (Data rate dual), 3.3V (so in the range
> allowed around 3V), full bus width that can be used (4 in my
> current context), 52 MHz or so.
> 
> (At least for any vintage of e.MMC recent enough to have that
> available. This e.MMC mode has been around since e.MMC 4.4
> (2009). I've seen claims that at the host controller level
> it is basically the same configuration used for SD DDR50,
> with different arguments in CMD6 for configuration.)
> 
> But I've no clue if this fits well with the upstream status
> of things or not. I've seen claims that, unlike for UHS-II
> and UHS-III, Linux has e.MMC speed mode support being "quite
> complete" in the more generic parts not specific to each
> controller. (Only a quick summary.) So I'm hopeful for
> upstream.

The 3V problem for e.MCC DDR @ 52 MHz looks more
generic than the Pine64's or even aarch64 or even arm
in general. Likely not your issue directly [Emmanuel].

Looking around some more I see that the card-type/device-type
bitfield had as of JESD84-A441 (March 2010) [JESD84-A44 was
apparently withdrawn, not just updated]:

Bits 7:4 reserved (defined in sufficiently more recent vintages)
Bit 3: DDR MMC @ 52 MHz 1.2 V I/O
Bit 2: DDR MMC @ 52 MHz 1.8 V or 3V I/O
Bit 1: SDR @ 52 MHz at rated device voltage(s)
Bit 0: SDR @ 26 MHz at rated device voltage(s)
(more modern has 3-0 being the same)

but the only valid bit patterns with 7:4 being zero
were(/are): 0x01, 0x03, 0x07, 0x0B, and 0x0F.

Note also that an e.MCC device can for DDR @ 52 MHz:

support 1.2 V without supporting 1.8 V/3 V
or:
support 1.8 V/3 V without supporting 1.2 V

(What I was using supports 3V and u-boot through
loading the kernel worked fine.)

Presuming the environment can supply an I/O voltage in the allowed
range around 3V, such as 3.3V being the the range 2.7 V to 3.6 V:
(The environment might not have 1.8V available as an
alternative even though E.MMC devices have 1.8V and 3V paired, for
example the Pine64+ 2GB, from what I'm told, lacks 1.8V.)

Then 0x07 implies DDR @ 52 MHz with 3V I/O is available for use
And  0x0F implies DDR @ 52 MHz with 3V I/O is available for use
(Otherwise DDR @ 52 MHz with 3V I/O is unavailable.)
If the e.MCC supports DDR @ 52 MHz with 1.8 V it also supports
3V --and the other way around.

So the code is odd/incomplete in /usr/src/sys/dev/mmc/bridge.h :

#define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V */
#define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V */
#define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180)

unless MMC_CAP_MMC_DDR52_180 implicitly also covers 3V. If so, the
comment should mention 3V, as might the macro name.

Another possibility is that there should be another macro. Something
like:

#define MMC_CAP_MMC_DDR52_120   (1 << 11) /* Can do eMMC DDR52 at 1.2 V (nominal) */
#define MMC_CAP_MMC_DDR52_180   (1 << 12) /* Can do eMMC DDR52 at 1.8 V (nominal) */
#define MMC_CAP_MMC_DDR52_300   (1 << ??) /* Can do eMMC DDR52 at 3.0 V (nominal) */
#define MMC_CAP_MMC_DDR52       (MMC_CAP_MMC_DDR52_120 | MMC_CAP_MMC_DDR52_180 | MMC_CAP_MMC_DDR52_300)

(I do not claim such is sufficient, just suggestive.)

It looks like this goes back to -r315598 (2017-Mar-19)
when the code as 1st added by marius. I've not found any
representation of the 3V DDR @ 52 MHz case for e.MMC
so far.

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