From owner-freebsd-arm@freebsd.org Fri Aug 10 06:59:42 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 C0B32105F1CB for ; Fri, 10 Aug 2018 06:59:41 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 081E17C560; Fri, 10 Aug 2018 06:59:40 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id efb8ab38; Fri, 10 Aug 2018 08:59:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=p3UypAs2jQqa6buj8eEscj29VsE=; b=Z/vpRn5uizafUUBKigT3W/OdP+8E uxoQu+oOLjwvZdPHtnx3MEafk2OyUdr0KqRGrDo7klxJMryd8RO9WXcr8BNr2+ok yqLsTHnkZ1e1WagK1SgB+oU+1Q968uSQoSLICfWdwDdpCiXOp8igu99CiEe3TqEM 0yRPyJ4drNPK+CQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gFt7KyA6Dn6XvnJuY+XqrJ0B6kKnTSJBW8Zu84b+iNMD+GEx4vgoB+Lx UtrClfUBXcekH8twY8gX06dCB9bw5cGj/N+AZJIFN7n3x1zeHqZZcFk+hLwuPgOP GcQ259xbu6qwtALnruXwBWDVfGNbYQYVfpAEq4okwRlZdouMVU4= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8fccee04 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 10 Aug 2018 08:59:32 +0200 (CEST) Date: Fri, 10 Aug 2018 08:59:32 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Marius Strobl , Mark Millard via freebsd-arm 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: <20180810085932.248050e3383151efb41c967c@bidouilliste.com> In-Reply-To: <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@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> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Fri, 10 Aug 2018 06:59:42 -0000 On Thu, 9 Aug 2018 23:39:35 -0700 Mark Millard wrote: > On 2018-Aug-9, at 8:02 PM, Mark Millard wrote: >=20 > > On 2018-Aug-9, at 3:00 PM, Marius Strobl wrote: > >=20 > >> On Wed, Aug 08, 2018 at 02:02:58AM -0700, Mark Millard wrote: > >>> . . . > >>=20 > >> 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 (apparentl= y, > >> they are intended for different purposes, i. e. eMMC, eSD, SD, SDIO). Yes, the first controller is usually used for SD, second for SDIO and the third for eMMC. I don't know if any of them can be used for any of the function or if they are intended to be used for a specific mode. > >> 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.=20 That seems the easiest fix. > >> 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. > >=20 > > Thanks for the notes. > >=20 > > Clearly there is something that I'm missing because: > >=20 > > *) Historically (before the switch to official dts's and such) > > I was able to boot, buildworld, buildkernel, poudreire-devel > > and the like booting from the e.MCC over the sdcard > > adapter plugged into the Pine64+ 2GB's sdcard slot. We always used official DTS for aarch64. What changed recently is that I added DDR52 support to the controller. > > It had been my standard configuration for some time before > > I made the jump to a more modern environment. > >=20 > > As for now: > >=20 > > A) u-boot successfully gets the loader from the e.MCC over the sdcard > > adapter plugged into the Pine64+ 2GB's sdracard slot. > >=20 > > B) The loader successfully loads the kernel from the e.MCC over the > > sdcard adapter plugged into the Pine64+ 2GB's sdracard slot. Loaded use u-boot driver and it only work with HS mode iirc. > > C) The first failure is from the kernel attempting to deal with > > the e.MCC (via the adapter). > >=20 > > I may have read into this (and the messages from boot -v and what > > was said about them) the wrong assumptions about what is wrong. > >=20 > > What I can say is that the issue looks to be specific to the > > FreeBSD kernel but not to the prior loader (nor to u-boot). >=20 > As for the Pine A64+ 2GB specifics . . . >=20 > Quoting pine6.org about the microsd support for Pine A64: >=20 > QUOTE > The Pine A64 board supports SD, SDHC, and SDXC format microSD card ? this= means the largest capacity is 256GB. Please note that if a microSD card is= formatted as an FAT32 file format, the maximum capacity is 32GB. > END QUOTE >=20 > I would expect supporting SDHC and SDXC to mean support for > various 1.8V modes of use: Such required if UHS-I is > supported (UHS50 or UHS104). Also DDR50 is required for > microSD (but not Standard SD). This would seem to match what > the schematics suggest to me (see below). >=20 > I looked and the Power Tree page of the schematics for > the Pine A64+ 2GB at: >=20 > http://files.pine64.org/doc/Pine%20A64%20Schematic/Pine%20A64plus%202GB%2= 0Rev%20C-20160113_Release.pdf >=20 > and the page shows DC/DC1 as "1.6~3.4V@ 1.5A" to > "3.3V Nand/Emcc/SDCard(ON)/WiFi-IO". In turn, the Power page > shows DCDC1 tied to VCC-CARD and the T-CADD/USB page shows > VCC-CARD connected to T-CARD, with "R58 0R R0603" in-line to > VDD. T-CARD looks to me like the sdcard slot connections. > (Yes: the mix of T-CADD and T-CARD naming is as in the > document.) (I'm not listing the capacitor and such.) VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, VCC3V3-USB etc .... so it needs to stay at 3.3V >=20 >=20 > For reference, for the e.MCC adaptor for anyone that cares: > (things like "3.3V" are as labeled in those schematics, > whatever the actual voltage of use for some mode of use) >=20 > https://forum.odroid.com/download/file.php?id=3D1036&mode=3Dview >=20 > shows a 49.9K resister in line between 3.3V and RSTN at the > e.MMC end of things. It also shows a 10uF capacitor between > 3.3V and ground on VDD from the micrSD end of things. >=20 > The rest is direct connections. >=20 > But the connections are for using a Hardkernel eMMC module, > in my case V0.3. >=20 > http://forum.odroid.com/download/file.php?id=3D433 >=20 > is for that module. Other than some parallel capacitors to > ground off of VDD and VDDF, and one off of VDDI, it looks > like direct connections there to the e.MMC device as well. >=20 > End "for reference". >=20 >=20 >=20 > The above does not say the the loader and u-boot are using > a 1.8 V mode instead of a 3.3V mode of operation for the > sdcard interface, even if 1.8V is possible. It doesn't, see https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner= /sun50i-a64-pine64.dts#L151 Again, 1.8V is in theory possible, but I wouldn't try that on my boards. > From an e.MMC CARD_TYPE/DEVICE_TYPE point of view it could be > any of (for 3V): >=20 > Bit 2: High-Speed DDR MultimediaCard @ (up to) 52 MHz 3V > Bit 1: High-Speed MultimediaCard @ (up to) 52 MHz "at rated device voltag= e(s)" > Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device voltag= e(s)" >=20 > that match up with one of the sdcard 3.3V modes: >=20 > UHS-I modes: > DS: Default Speed up to 25 MHz 3.3V signaling > HS: High Speed up to 50 MHz 3.3V signaling > (Looks like the signal timings are distinct from 1.8 V modes.) >=20 > So not bit 2 if 3V, unsure about the other two bits for 3V. >=20 > In fact, for the SanDisk Extreme 32 GB microSDHC I V30 A1 > UHS Speed Class 3 card (that I showed that the Pine64+ 2GB does > boot from) the kernel seems to pick the UHS-I HS mode, > instead of SDR50 or DDR50 or higher: Because SDR50 or DDR50 needs 1.8V signaling. So the maximum mode that we can select is HS at 50Mhz which is using 3.3V signaling. > aw_mmc0: mem 0x1c0f000-0x1c0ffff= irq 4 on simplebus0 > aw_mmc0: vmmc-supply regulator found > mmc0: on aw_mmc0 > random: harvesting attach, 8 bytes (4 bits) from mmc0 > random: harvesting attach, 8 bytes (4 bits) from aw_mmc0 > simplebus0: mem 0x1c10000-0x1c10fff irq 5 disabled compat a= llwinner,sun50i-a64-mmc (no driver attached) > simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled compat a= llwinner,sun50i-a64-emmc (no driver attached) > . . . > aw_mmc0: Powering up sd/mmc > mmc0: Probing bus > . . . > mmc0: SD 2.0 interface conditions: OK > mmc0: SD probe: OK (OCR: 0x40ff8000) > mmc0: Current OCR: 0x00ff8000 > mmc0: Probing cards > mmc0: New card detected (CID 0353445345333247800978130301171d) > mmc0: New card detected (CSD 400e00325b590000edc87f800a4040c3) > mmc0: Card at relative address 0xaaaa added: > mmc0: card: SDHC SE32G 8.0 SN MFG 07/2017 by 3 SD > mmc0: quirks: 0 > mmc0: bus: 4bit, 50MHz (high speed timing) > mmc0: memory: 62333952 blocks, erase sector 8192 blocks > mmc0: setting transfer rate to 50.000MHz (high speed timing) > mmcsd0: 32GB MFG 07/2017 by 3 SD> at mmc0 5= 0.0MHz/4bit/32768-block > random: harvesting attach, 8 bytes (4 bits) from mmcsd0 > GEOM: new disk mmcsd0 > mmc0: setting bus width to 4 bits high speed timing > mmc0: ACMD42 failed, RESULT: 4 > mmc0: Card at relative address 43690 failed to set bus width >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) --=20 Emmanuel Vadot