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]

[Add a note about High Speed on both USB connectors
under that modern linux.]

On 2018-Aug-10, at 4:45 AM, Mark Millard <marklmi at yahoo.com> wrote:

> [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.]
>> 
>> On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> . . .
>> 
>> 
>> 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.
> 
> I discovered another command:
> 
> # mmc extcsd read /dev/mmcblk0 | more
> =============================================
>  Extended CSD rev 1.8 (MMC 5.1)
> =============================================
> . . .
> 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).

Just an FYI . . .

I booted that modern linux again again and plugged
in 2 USB 3.0 capable contexts that allow for USB 2.0
as well, one in the upper USB connector and one in
the lower one. Then using lsusb -v I found:

For the card reader (with multiple ports) and
plugged into the lower USB connector:

Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x00e9
    Per-port power switching
    Per-port overcurrent protection
    TT think time 32 FS bits
    Port indicators
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent    100 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0507 highspeed power suspend enable connect

For the powered hub with a USB stick plugged into
the upper USB connector:

Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
Device Status:     0x0001
  Self Powered

So both USB ports are selecting high-speed at the same
time on the Pine64+ 2GB.

It is definitely seeing both storage devices, one per USB
connector, which I can tell from:

# ls /dev/disk/*label/* | more
/dev/disk/by-label/BFAT
/dev/disk/by-label/PINE642Grootfs
/dev/disk/by-label/PINE64P2Grootfs
/dev/disk/by-partlabel/PINE642Gboot
/dev/disk/by-partlabel/PINE642Groot
/dev/disk/by-partlabel/PINE642Gswap
/dev/disk/by-partlabel/PINE642Gswp2


(Personally I do fine with one highspeed port
connection on the Pine64+ 2GB --unless I forgot
my powered hub that I use.)

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