From nobody Sun Dec 12 08:29:25 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 04EFA18CA431 for ; Sun, 12 Dec 2021 08:29:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4JBd9G52npz3NlY for ; Sun, 12 Dec 2021 08:29:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639297771; bh=wiDcUPQ7O3TKeizJJYAmHAgzBjsHWbTVwM9ci6K7sHg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Nw7a9ZVaN/c/fGJqqZiZtRuRYT6ZZBrBuF0R/fI5oBNqri0XsuNEFhF3wbjFkzXt0l2LnFQYAUhuvvKg/orlCkZT5t378jlvxrRqxBSYqZ/B6oRGnWzXoEainvOgWHBxt6OV9P2hmfLJiQAWRdP7n0Wtteiw+dg9mX1uNlwI+PdRak/9drI6MmwqbpNj+mXj7KAP26cVRjcS55OJvdQrCwh6ZyMlePiTZ5HJlm/Y6sB0LgRVUdIz3qjPkttK6iK89T1PWHO4lO2gZsF7rs8n2UEUT/71O5F6AGnr2LJvKg+7KMvgaLmyPod/EhbxO+2DB882AqXBzFBh0ZDo5v3KEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639297771; bh=SoSOWO6S2U7m8Hg6ZW1aZq4FTewecqgcw7guMYO7E2y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EyEOJe2GXA9Rq1ZMFym/pCXLnn+qPvTtTUna9PhKuSck8UyuXcpxA2NlaRPWFGOuP8R5NIgOPptlgpKIgrk5xMwH9asMRGedXBMocgMKmabkT/TUrdwo91eVr0m7MMwyBYM5LXt7Ipg5FozCBhAfWsSSutYZGBc1rg3OwSRubwuwzE25ps3tQ8Ogs83DaxZSmyDvcakiOaev7clx8iOYcQ2VzK5MgnayqrLQGGEog7XyAfutE1rOCyzZsp1DaNU7w0KYWosiAcOfMBO7wSqIHdDg/HGd0WbM4dsbS6Rg4J5g/FzHJsFDEtAGYWGvJFfSyMfVo97L86IroLqNsBG/rw== X-YMail-OSG: gpTNmzwVM1nBOsinrh61BFPCpgHqPFe6cakCDwwm1miSVMdSGqaAQhRa6.Y..5y TtWm3kVeZYShypql3WcHqK9ZYA9T6lu2CSZzT.hqu9mDh0zUxu0GwiE3CE8MUvYWDpFoSah0M5KA hLVmCVSS_0UwUNY5iM_eDgC7F3fKF.CrKrDz4MJw3V0hVYkJxGfK7xhFgEkEMc3D6cTxACBQrJx2 9Oh5ziP1LNWmPqp95ohy5EuhOOep5f2fwnXjjtCeAtt31c68vDEWDwuZaP39M3zMh.D5OsJC5pHX IHOVp5.skqD1wkN9NtSM_ekdjDcE7cUQg0088Mi10U9VM7CY2NsoMNJXHJnAoJTPyBvFkZOs1Z.Y 5w_c10bJeHpK2GlRzoR7VaXk2pNTDOgFZfZvm4Lnq.IY_Fh2h0.Jv6F7XKOve2VTEYfdkoOSNa8W wonifBJ2j3B_mp0dFHe2P8Q5JZ1e23j.6r784gtTPgvYeMpmis_YGprzvAftAZ4Mx66P_6HH_EZM oQiTf4BbCu.JvrFor.dhbhWkkB1D4vmBEj2Wt_VHpfUcvLW4_EVxmiqIaeWpOVkqaqazle3lOM7w SdrFvB4MI3WGbOmhC_XOuFBtHg1h7lRNroSA1agSdjZv13gfwQR749C.dsxjFG.jHcIps9Z.FxZq AlAwBnr1SF82KU.KV7MFLz.qtzkeDjzlyLthSjmoIxJFjjNr66EEGvC9_5OYcbA3Sx4MCkYpmAr1 FQyyzvQyzu.baRmeWQV8TYefzEsb1pWwBhyZOSPL4sMDuLpOlvMSMcxq83n0B1FeaxracTyECqMv YvPTeMptW7ieVRNTC2EVBatWes6qZR6n.KnQutjo48E0fj15yU2EvEmuNc7ifyoVpViZeJIua9CN CDXq_VmLs.UyHwk4gq7ICMbj31Nx9YpuezVaYid2HRX9KGs0mo2VUIkYmpXqtjZAQqQ_xCziD9uH l7U3FjfYTAjRxIvzNnaNEyu8ZyQpMpD1cXkHTP5PNzoB2vEtn7CKjt13dnbCV9.FrxRev8YyRrZg paLWfIulXWAuc.ELgO91bkqwDPfKp2Om2p_6jxMWApyV7LSaMQzbGf35SRDOoghzyKzNoYOn6s9A wE8Ft6deIuYJW1Q6i5zWUpmG.a7q355Z9WmzvWdBlcAjb4sytU.SAZytj_MolneRWHm6HhePgm6E UWR42mHlGVWEp1BMUeOQ2Zd0M7koChHB_0BDscMnxkgUQnzLjnGYYAEfupBcAI1wMFbcNtK.Uqe1 owTXdZgq_agoGTLIBxKh5owOzKVtXDJnQl3IF0GifBxF5dlStj3.5wVlQ.FlEFnbJydfxUX.LQJi xutLNs3s4A9EzGfmfps3bCEB8i_Xf3Ojl7ZcDsHaQDQTckxPGGO3rsDlKfV0zaaL3Ulrxv_nnctU 8p.hwYPmMgXny4JETx3R5Cr7IK7A0rGQNNy2EJOATlDCbiB4mBf06IVz3fX4H.qCpnoZv8611NyB OgPycjqrp44A3MuvEHA1FQ_j4OvldwTatNGN5qYd8udq6uwVQdKTzf4rmQe9he5rrarw54Pk8Usu qVNJ4uQTLszYMnv4lnaE5oUL_M_AZUKMsug_wi3RTvEJyUBY8tMEoKaQ7s7MClnIBFjF4LicOq3A c65w4vO9XSFcxeIdRfJQ5aU8LDjlQ5io1FMITg6sEwE5x_QCnmoMsn9FqTa.elju4i1MGRhU4csN QbAYPpDcWBDulzquUkOtqkhwP55129rZXdLQb.OZip9Dz3ibKiYJXOXli1W6dKMN7f1k_4j1phvB oAqYaluF7Bo8XP6uqYkoY2HPMhGjbEWUv2KNQxdtd3l.7m03helaEFVmK6ZrHhe1kVI.WQeMF336 UQLG0gFxC1iRQf76fuARPvs.qz67pGt7jzpVW8GMBiVcuG4NXJkjuI1DB_Y11nMGPw1.J_Sii5UA pTU56mqXbhq8fHSBcL8Q71Q5JHxH2GE9YstcjPWawn.nX9f3HX6VoEDphlg7Ivw8hxVjzqJrWpin DoHgFaMGQzTI1xkDimCdp39jFAD.zTOYp_y_LLywHKG0oWfhowBYcjGETVw.i8vHYhgoEjdSVBBq ix_kdqa2gvfYhvaauvDakcVryhBnEi_aa5715n4T6i9_JZks5Jtw9g40JH3FoYUd5ZABpCK3DXds PWB.jAUJYPmgXhiHydeUaJj9NnTdBE9dPgVRDb8DWG19h54b53AMUIeUC7eeHAUUaHfB5DoWI_A7 QWryk5Gdb1ha77J9LWddUCwMXkCLmTT6zzKhWTonIzjJGU83b X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 08:29:31 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3b3441adc3c3cae74acbccbea9c5b164; Sun, 12 Dec 2021 08:29:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled? In-Reply-To: <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> Date: Sun, 12 Dec 2021 00:29:25 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> References: <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D.ref@yahoo.com> <243CBFC7-DFB5-4F8B-A8A3-CFF78455148D@yahoo.com> <20211209081930.7970b6995a8f7c5f7466227d@bidouilliste.com> <053617FD-AA34-4A3F-853A-4D2E44F8254B@yahoo.com> <43901D57-9C39-4FAC-A2BE-CCE642791705@yahoo.com> <8DAA50A1-3CF0-4AFA-9977-58FE15D4F171@yahoo.com> <21B0478B-340F-4BB2-9189-B5A6AE458134@yahoo.com> <7717F6CF-0239-4DC0-B23F-B9D5F75C0A8D@yahoo.com> To: =?utf-8?Q?Kornel_Dul=C4=99ba?= , Emmanuel Vadot X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JBd9G52npz3NlY X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Nw7a9ZVa; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Dec-11, at 16:19, Mark Millard wrote: > [I've cut out the history: just presenting some new evidence.] >=20 > First, a little context from getting to the db> prompt. >=20 > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 18 0 0 0 DL syncer 0xffff000000eca5a8 [syncer] > 17 0 0 0 DL vlruwt 0xffffa00007d2ea60 [vnlru] > 16 0 0 0 DL (threaded) = [bufdaemon] > 100089 D qsleep 0xffff000000ec9478 = [bufdaemon] > 100092 D - 0xffff000000c11100 = [bufspacedaemon-0] > 100093 D - 0xffff000000c21680 = [bufspacedaemon-1] > 9 0 0 0 DL psleep 0xffff000000ef0650 [vmdaemon] > 8 0 0 0 DL (threaded) = [pagedaemon] > 100087 D psleep 0xffff000000ee2b38 [dom0] > 100094 D launds 0xffff000000ee2b44 [laundry: = dom0] > 100095 D umarcl 0xffff0000007b38d8 [uma] > 7 0 0 0 DL mmcsd d 0xffffa00007b72e00 = [mmcsd0boot1: mmc/sd] > 6 0 0 0 DL mmcsd d 0xffffa00007b71300 = [mmcsd0boot0: mmc/sd] > 5 0 0 0 DL mmcreq 0xffff00009b5d0710 [mmcsd0: = mmc/sd card] > 4 0 0 0 DL - 0xffff000000ccc020 = [rand_harvestq] > 15 0 0 0 DL (threaded) [usb] > . . . >=20 > and "mmcreq" is from the while loop in: >=20 > static int > mmc_wait_for_req(struct mmc_softc *sc, struct mmc_request *req) > { >=20 > req->done =3D mmc_wakeup; > req->done_data =3D sc; > if (__predict_false(mmc_debug > 1)) { > device_printf(sc->dev, "REQUEST: CMD%d arg %#x flags = %#x", > req->cmd->opcode, req->cmd->arg, req->cmd->flags); = =20 > if (req->cmd->data) { > printf(" data %d\n", (int)req->cmd->data->len);=20= > } else > printf("\n"); > } > MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); > MMC_LOCK(sc); > while ((req->flags & MMC_REQ_DONE) =3D=3D 0) > msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); > MMC_UNLOCK(sc); > if (__predict_false(mmc_debug > 2 || (mmc_debug > 0 && > req->cmd->error !=3D MMC_ERR_NONE))) > device_printf(sc->dev, "CMD%d RESULT: %d\n", > req->cmd->opcode, req->cmd->error); > return (0); > } >=20 > So it appears that the error report: >=20 > mmcsd0: Error indicated: 4 Failed >=20 > ends up associated with (req->flags & MMC_REQ_DONE) =3D=3D 0 staying > true in the above code: an unbounded loop with MMC_LOCK(sc) active. > The "4" in the error report seems to be from: >=20 > #define MMC_ERR_FAILED 4 >=20 > It looks like there are some problems with handling errors, problems > such that it gets stuck looping (no panic, no progress). >=20 > That seems to be separate from why the MMC_ERR_FAILED was generated > in the first place. So: 2 problems, not just one. Thus it may be a > good context for tackling the looping problem with a known example > failure to look at. >=20 >=20 >=20 > Just for reference, I tried "boot -v" with debug.verbose_sysinit=3D1 = in place, > just to capture and report the tail of the output for the boot = failure. >=20 > . . . > subsystem f000000 > release_aps(0)... Release APs...done > done. > intr_irq_shuffle(0)... Trying to mount root from = ufs:/dev/gpt/Rock64root []... > done. > netisr_start(0)... done. > taskqgroup_bind_softirq(0)... done. > GEOM: new disk mmcsd0 > GEOM: new disk mmcsd0boot0 > GEOM: new disk mmcsd0boot1 > smp_after_idle_runnable(0)... done. > taskqgroup_bind_if_config_tqg(0)... done. > taskqgroup_bind_if_io_tqg(0)... done. > tmr_setup_user_access(0)... done. > subsystem f000001 > mmcsd0: Error indicated: 4 Failed > epoch_init_smp(0)... done. > subsystem f100000 > racctd_init(0)... done. > subsystem fffffff > start_periodic_resettodr(0)... done. > oktousecallout(0)... done. > clknode_finish(0)... Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > done. > regulator_constraint(0)... done. > regulator_shutdown(0)... regulator: shutting down unused regulators > regulator: shutting down vcc_sd... busy > done. > uhub0: 1 port with 1 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 1 port with 1 removable, self powered > uhub1: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub2 > umass0: on = usbus4 > umass0: SCSI over Bulk-Only; quirks =3D 0x0000 > umass0:0:0: Attached to scbus0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=3D0x2 > da0: Delete methods: > random: unblocking device. >=20 > No more output after that. As for why MMC_ERR_FAILED results, the following code diff is intended to suggest what I think may be incomplete about sticking to what the device-specific code supports vs. does not support (not supporting HS200 here). The code does compile in my context but is untested. The email handling may mess up some leading whitespace --but, again, I'm only trying to suggest a type of change. # git -C /usr/main-src/ diff /usr/main-src/sys/dev/mmc diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c index 9c73dfd57ce0..dffd1c382684 100644 --- a/sys/dev/mmc/mmc.c +++ b/sys/dev/mmc/mmc.c @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing timing) static bool mmc_host_timing(device_t dev, enum mmc_bus_timing timing) { + kobjop_desc_t kobj_desc; + kobj_method_t *kobj_method; int host_caps; =20 host_caps =3D mmcbr_get_caps(dev); @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) case bus_timing_mmc_ddr52: return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); case bus_timing_mmc_hs200: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); case bus_timing_mmc_hs400: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); case bus_timing_mmc_hs400es: - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 | - MMC_CAP_MMC_ENH_STROBE)); + /* + * Disable eMMC modes that require use of + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the + * tune or re-tune method is the default NULL = implementation. + */ + kobj_desc =3D &mmcbr_tune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) + return (false); + kobj_desc =3D &mmcbr_retune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) { + return (false); + } + + /* + * Otherwise track the host capabilities. + */ + if (timing =3D=3D bus_timing_mmc_hs200) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); + if (timing =3D=3D bus_timing_mmc_hs400) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); + if (timing =3D=3D bus_timing_mmc_hs400es) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | + MMC_CAP_MMC_ENH_STROBE)); } =20 #undef HOST_TIMING_CAP In other words: have mmc_host_timing avoid returning true for some combinations that definitely do not have sufficient software support present at the time. (So far as I can tell, the rk3328's get the NULL-implementations as things are.) I expect that this sort of thing would go back to using MMC_CAP_MMC_DDR52 for the rk3328's, as an example. Working, but in a slower mode, the same mode as FreeBSD was previously using. A possible incompleteness in the suggestion is that there is also a drive-strength setting involved. If that also had "kobj" interfacing and NULL-implementation possibilities, then in the future there would be more to test for possibly forcing return-false than I did above. Hopefully this sort of thing would help, possibly more than just for rk3328's. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)