From owner-freebsd-arm@freebsd.org Fri Aug 10 08:10:47 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 262B71061598 for ; Fri, 10 Aug 2018 08:10:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) (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 A7DC47E6DF for ; Fri, 10 Aug 2018 08:10:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: p9xEZY8VM1mQ3yPyUYf94xJjpNL_96F6I6dAk7SwaxV0EI1VqmkSlSHoTyGytcf Nl138o4b_nbPBZ6I9QrFDtJF3RcjwnZwt6ObMdMwbM4pXLrE7_SKXy6OCammNhmQTmhH59oFxmdp gqPeNmUG3TlHlcQ66U5M3qv6zFNb.D4Js_.IdEjYwSH1uuwQ7edYzIVQOmbjuvaPKPnLHOkyKOao 4j4pHsp0VpnsOpT9Cl7JISuH1E10uF.9_gC7brCxW2Q2El0Zgr6KPv5MC__9aR_3RcaxrJwfAc.K omK5ImXPY3ErB1Yt_xkBrdcrtpIdF6e4oVTOq9datsdE50Xzq.WwGyWrgcWCM9tZFaxPycCzusbA 0O.CEcPfumKeeneqeN_yEMlbD6g1J3Zyz8EFhbaPgswWmEgNTlvUixMEWjf3x_l8kU03W72hVOfi vpZoIheRZ39V7luRjT9oxyZi4UhPbgX1gQpg3diniFn_tt_og_icz5FZNHCh72E7K9KFS.0K9KcH fP4HRZVbOyJ0b84aX.D9KsgWPZw09WVx8hrX4o3NDoxWeysxQLJ.z_wPJ6VKsI8p0RPP1mHobiLp jS9reevvX0cSdnpHxqgJWGl8evL44rdPBPrqEywH6kO0AVd7jImWCB08RFku__haxJK2Os4XKPII CIk8EJvLcmePzKZ7nbZKHE_n1g2e6imOsZdwuRqgeKBy6uUBh9USYI7AvAABgvzzECd_vov_2fif 8qaLj_.nREbhsyw_AFe8r7_syuUwXewGieGFvAsDji0xNmPxe7XDGU0yQz2zHWaWgg4.oXxAKB5c xypKoC8UsGhMD75HgtyBWLJq45ce2aJ7wmnvlIWO2NwbttaP0Fg55Y2cSbOZLAtDjdud7qKDAUwH SyTI2lFd45EFO7ElRfjqGuohnhHh9567P4coaOitj3qME0iwYQheaFO71hkcXtnPMfGdK1xVN4YM jU_k1CUv.DAcZGXiBitjVb958MtarbxjGltaP0fqWJ6uLCVoZmxt6y_w3eAHnc.hGgp6Zf3CDBeQ ee9Cb0RALMm35PoodkA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 10 Aug 2018 08:10:44 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52a5f6a814245449beb1f499505c1e7b; Fri, 10 Aug 2018 08:10:43 +0000 (UTC) From: Mark Millard Message-Id: <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> 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 Date: Fri, 10 Aug 2018 01:10:41 -0700 In-Reply-To: <20180810085932.248050e3383151efb41c967c@bidouilliste.com> Cc: Marius Strobl , Mark Millard via freebsd-arm To: Emmanuel Vadot 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> X-Mailer: Apple Mail (2.3445.9.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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 08:10:47 -0000 On 2018-Aug-9, at 11:59 PM, Emmanuel Vadot = wrote: > On Thu, 9 Aug 2018 23:39:35 -0700 > Mark Millard wrote: >=20 >> 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 = (apparently, >>>> they are intended for different purposes, i. e. eMMC, eSD, SD, = SDIO). >=20 > 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. >=20 >>>> 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 >=20 > That seems the easiest fix. >=20 >>>> 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. >=20 > We always used official DTS for aarch64. > What changed recently is that I added DDR52 support to the controller. My quick attempt at identifying the history point was poor. It looks like I should have referenced before and during the ccu-ng switch, before and during the USB being temporarily unsupported in the similar time frame. I held back to materials that allowed USB use and did not update past that until just recently. (This is still just a = summary, not the full history of my builds based on the older materials in this = area. But it should be good enough.) >>> 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. >=20 > Loaded use u-boot driver and it only work with HS mode iirc. Sounds likely. Good to know. Thanks. >>> 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%20= Rev%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.) >=20 > VCC-CARD is indeed DCDC1, but DCDC1 also provide power to VCC-IO, > VCC3V3-USB etc .... so it needs to stay at 3.3V Ahh, I see. All the control of such is at DC/DC1 and the rest follow together. >>=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. >=20 > It doesn't, see > = https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinne= r/sun50i-a64-pine64.dts#L151 >=20 > Again, 1.8V is in theory possible, but I wouldn't try that on my > boards. So it looks like if the e.MMC on an adapter card were to be supported, it would be via Bit 1 or Bit 0 below, much like u-boot is apparently doing. >> =46rom 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 = voltage(s)" >> Bit 0: High-Speed MultimediaCard @ (up to) 26 MHz "at rated device = voltage(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: >=20 > 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. Okay. It would be nice if the e.MMC on an sdcard adapter also did so someday, somewhat like u-boot apparently does (up to clock rate differences?). Even going slower, I'd prefer e.MMC media. >> 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 allwinner,sun50i-a64-mmc (no driver attached) >> simplebus0: mem 0x1c11000-0x1c11fff irq 6 disabled = compat allwinner,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 50.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 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)