From owner-freebsd-arm@freebsd.org Mon Aug 20 02:01:58 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18619107FC3D for ; Mon, 20 Aug 2018 02:01:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A40D97515B for ; Mon, 20 Aug 2018 02:01:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pyGL9U8VM1kel8XOe9_eUogAuzeyOJYwUE1Gu5bB3HIkfSjPQoLvfS.x9fvf_y0 iLPOOIKiNa7sAKQ8.Mm8nn9aWdqvpFHH72uJcG.yjmVWxEoKCePIRAMRDmJMvfpVwG4DfUvj1U_s 4B0y7lSDM3CvtH2EH8Wsh_tMAKW717TcutbXqrEexD41c1BjjKP9ZkdD3mIz8vNp4YfuoeHL6R9u n0UzyRH0XSdXbyWaMStd3x0cdzPLJ3s19AncqqMGuSinRTikFgweDzYuAzZvpf5zcH7.tOBXGm6y uWEV7dfmlvA6zNdpLxioeIx82y9PwYAUDtyZqRk0ogbTLkJBRgRBkz5yTaTo7Qze8dcWkp5gSp80 vtmIqrN06fkvW5SNjIgnKJAXGCdXBjBVEmpZ_t9lX_XwFIH00T5a2UP_6FmbYYRZ_r2W24YTTx4F DFwQDKzrKHkhYpTk7B0xSxlo5aPqki1YVezuwG_b1jhfmr.fXiRKMB_Ca1.nA.YBTfOUf1D48dW6 1IipElhknCAlikwymvB1n8kdZ40mBs.VSU_N1hVbcXRVb5oyAmhcJIVO93APS4gDOCBjslQDDiYF AwVZLepcenvs4sR5XGEp0l_c62mKePcmRWolSJSZhhi36FdXL.4NUzr8BUeNda9yWh_.WQvWhMLg efqRzXSlfSQIl7kunA5Ut7Qb6cCdP7m9YhjE4vwBfOI0sTExkDvN.qKmkeD1fLHoOE2J_mQgMHTk IeGFTwzVeWXbEe0aroFE1rA5nFxE0fYrvwcjm8iq8s5sfKFKaIRj1m5p8ViCuKPGkUBcVbCgIlKs JNh.wQ.czD3qBz_RGB8CWgMJymX5vox1O9hG7FKcNVH.ZNiO7dmc5WTce4VwV1ya1qFsOMXzJpbv ooTIFjfrT16e.brNjaRiO6x8SVHYL5c8sx3hdX895jwlo5CtzfUwREs8oj2na17flz8LjJ8v8MSV n5RzwEOxqiKnzfM1E1GWAqnI.74RC_qReY_l3vExCaU9xHI_snziWRW0YzZKuHNEhBCo5yBH_Xlu c3btAD3KlGj4p0vsElRa1OmYBwRpny4j5CWcOQ7MkYyP4_QHAjRVgQ_GG.tHxBAaH Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 20 Aug 2018 02:01:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 692bb5a3356159167badf07f79769be0; Mon, 20 Aug 2018 01:41:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) 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 From: Mark Millard In-Reply-To: <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> Date: Sun, 19 Aug 2018 18:41:32 -0700 Cc: Mark Millard via freebsd-arm , Marius Strobl Content-Transfer-Encoding: quoted-printable Message-Id: <75CA8B85-3EB8-4C03-AADC-3560B600B99F@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> <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> <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 02:01:58 -0000 [Add a note about High Speed on both USB connectors under that modern linux.] On 2018-Aug-10, at 4:45 AM, Mark Millard wrote: > [A note about CARD_TYPE/DEVICE_TYPE is added.] >=20 > On 2018-Aug-10, at 3:53 AM, Mark Millard wrote: >=20 >> [A note about linux booting is added.] >>=20 >> On 2018-Aug-10, at 1:10 AM, Mark Millard = 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)