Date: Fri, 10 Aug 2018 00:00:12 +0200 From: Marius Strobl <marius@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: Emmanuel Vadot <manu@bidouilliste.com>, Mark Millard via freebsd-arm <freebsd-arm@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: <20180809220012.GU21523@alchemy.franken.de> In-Reply-To: <D83A4360-AF95-4299-95C0-BBC677EF7633@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: > 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.] > > > > 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@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@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. > > 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. It's true that an eMMC chip can support DDR52 at 3.0 V VCCQ. However, with eMMC devices on SDHCI controllers, eMMC DDR52 translates to SD DDR50 which - like any UHS-I mode - requires 1.8 V signaling (see for example figure 3-14 in the SD physical layer specification version 6.00). Thus, DDR52 at 3.0 V VCCQ is not supposed to be possible with SDHCI controllers and at the time DDR5{0,2} support for FreeBSD was written, Linux didn't support the former either so I saw no point in adding a MMC_CAP_MMC_DDR52_300 to FreeBSD (Linux grew MMC_CAP_3_3V_DDR a bit later in January 2017, though). While I have no problem with support for DDR52 at 3.0 V VCCQ being added to mmc(4), I doubt that will solve your problem given that Linux doesn't set mmc-ddr-3_3v and MMC_CAP_3_3V_DDR respectively for Pine64+ or any other Allwinner gear. Based on what I could figure out about Allwinner MMC controllers, their capabilities actually differ depending on the particular instance of MMC controller of a given SoC (apparently, they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). So I guess what needs to be done is to let aw_mmc(4) announce and support different sets of capabilities depending on which instance of the controller it is driving. For your adapter this likely means that high-speed at 3.0 V VCCQ is the achievable maximum so that the microSD slot complies with the SD physical layer specification if 1.8 V VCCQ isn't supported by the particular board. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180809220012.GU21523>