Date: Wed, 8 Aug 2018 02:02:58 -0700 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org>, 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: <D83A4360-AF95-4299-95C0-BBC677EF7633@yahoo.com> In-Reply-To: <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.] >=20 > On 2018-Aug-6, at 11:39 AM, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> [Fixing a confusing "slower" reference . . .] >>=20 >> On 2018-Aug-6, at 11:26 AM, Mark Millard <marklmi at yahoo.com> = wrote: >>=20 >>> On 2018-Aug-6, at 10:37 AM, Emmanuel Vadot <manu at = bidouilliste.com> wrote: >>>=20 >>>> On Mon, 6 Aug 2018 10:12:43 -0700 >>>> Mark Millard <marklmi@yahoo.com> wrote: >>>>=20 >>>>> On 2018-Aug-6, at 3:44 AM, Emmanuel Vadot <manu at = bidouilliste.com> wrote: >>>>>=20 >>>>>> On Mon, 6 Aug 2018 02:48:57 -0700 >>>>>> Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> wrote: >>>>>>=20 >>>>>>> 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.) >>>>>>>=20 >>>>>>> The kernel config has GENERIC included but the various >>>>>>> debug features disabled. (My typical operating >>>>>>> environment.) >>>>>>>=20 >>>>>>> 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.) >>>>>>=20 >>>>>> emmc to sd ? that's weird ... >>>>>=20 >>>>> An example of the adapter I've used for this is: >>>>>=20 >>>>> = https://ameridroid.com/collections/storage-emmc-and-microsd/products/emmc-= adapter >>>>=20 >>>> So this is a passive adapter, maybe that's something that should = work >>>> but it's definitly is something that calls for problems. >>>>=20 >>>>> 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. >>>>=20 >>>> I didn't understand a word. >>>=20 >>> 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.) >>>=20 >>> The output reported: >>>=20 >>> 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 >>>=20 >>> The e.MMC bus speed modes with I/O Voltage 3V allowed are: >>>=20 >>> Backwards Compatibility with legacy MMC card, data rate single, 3V = allowed, bus widths 1,4,8, 0-26 MHz >>>=20 >>> High Speed SDR, data rate single, 3V allowed, bus widths 1,4,8, 0-52 = MHz >>>=20 >>> High Speed DDR, Data rate dual, 3V allowed, bus widths 4,8, 0-52 MHz >>>=20 >>> (The last being the fastest for maximum transfer rate with 3V.) >>>=20 >>> 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. >>>=20 >>> 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). >>=20 >> "slower" lacks context: I should have said . . . >>=20 >> "a slower than HS200 3.? V mode" >>=20 >> 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. >>=20 >>>>>=20 >>>>> (I had to modify the case the pine64+ 2GB is in in order for >>>>> the adapter/emmc combination to fit in all the way.) >>>>>=20 >>>=20 >=20 > 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: >=20 > 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 >=20 >=20 >=20 > Prior to the last 2 lines above looks normal to me for the > MMC material. >=20 > 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. >=20 > My hope would be for the Pine64+ 2GB with e.MMC on a MicroSD > e.MMC reader to be tried via: >=20 > 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. >=20 > (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.) >=20 > 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. =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?D83A4360-AF95-4299-95C0-BBC677EF7633>