Date: Sun, 19 Aug 2018 18:41:32 -0700 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org>, Marius Strobl <marius@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: <75CA8B85-3EB8-4C03-AADC-3560B600B99F@yahoo.com> In-Reply-To: <33AFF697-FB1E-4349-93C7-888C184CBBD4@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> <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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.] >=20 > On 2018-Aug-10, at 3:53 AM, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> [A note about linux booting is added.] >>=20 >> On 2018-Aug-10, at 1:10 AM, Mark Millard <marklmi at yahoo.com> = wrote: >>=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. >=20 > I discovered another command: >=20 > # 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) > . . . >=20 > Which is interesting by having 5 bits set in 0x57 > but only listing 4 of the alternatives. The missing > one would be for: >=20 > HS400 DDR e.MMC @ 200 MHz - 1.8V I/O >=20 > (In essence, no 1.2V alternative is supported.) >=20 > 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.) =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?75CA8B85-3EB8-4C03-AADC-3560B600B99F>