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 01:25:48 UTC 2018

[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.

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