From nobody Sun Dec 12 08:59:13 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 7D38E18CF7EA for ; Sun, 12 Dec 2021 08:59:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.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 4JBdqd28B9z3RHj for ; Sun, 12 Dec 2021 08:59:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639299558; bh=SaPkxJkFi3A3XzhGx25thMwY6EMg2iRUkpTBzv/l504=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=fBlHrF7+IxYSYQmrptWZbxUKNZsB4Pnx2+vWVuf8vquHgnulEit02rC6ZTCvVzR4yh9/3tf6/SNYUOLsdUC7Gv0NHEJSBQhEy4ZcvY8hQ3NuDgXEHaLxJM50jqAapWu3HDNCknFm+ivILhHynrcoYeFqn3C6TZpwbr07lSwPgCpHus+DRwUHRK+yPdNQzkqzwGLmvDixfKXVAT49C1sO3dj4YLaTOn1n5uPAh8rIjPvUKSxcUs8VcyuUslQfqKf2AsRNQihaYTdQ/IG2IfjdQEx5G7fMxVQExUkgEBL2254OetkxPt6xPT9yEcvqc9bPgEmN+CC/r1vZozdga4jbHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639299558; bh=cieuYr4Tt7ymZyTDEyu7S/bA3AMvqZjVTyDWfZQ7y4u=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fhGWCCdYJ6sM8zPsB9/Re1NXjIoEgVPNjMoQlnF1hlqsXWir9eOcvURwLPivCVt7JeFeVdy4D3DMLyyDO9Pmv3r3oWZduyxRxaxcCc2SFzepG0ua3TRrcbj0/HVO/SAyA9TKaCBldbNNSBz0JW/+oKngS43FBy/LOgJaORwPwvxRuAQuLJWPxx6BVoK3d3g5eJNUzXTC7fKUD3nbPpV6WDwxThQ8hiDRtpipW1LM4x/j2gIrc54CIkBCwtOPFe1bN8mNqwWcOdUBlrIr8la/bMzboEVkrkr5bXGpb85zKL1Z3LdgPBY/0WryayPhjlnIPtBpfcIF0uN/Dn6dIvLJOA== X-YMail-OSG: oBMCNtMVM1l2FdZ6QtaLQkw.pKZUCyZ6h1t7HwFsWh.5g7OP0rNbGsIB1zer1Va oVRwfhRCb_7UhmY_AzPbAMFOSHJLmX3hOb2DsiYEGGw2i1BGqX.37PMkhlvFH9mJoAk42TvfkEmr 9uV2ZGiQ4oXbF5ZgeohxHdRVR3fxa4gfGYQhq6Zj8mES3rdJ_MCx97KEfQ8KSgGrTDgZvI_inprL 62b4TCg07IJ0_7zWF1CuGYpmH9vmp6TxSU7BpIviA4j4h6faTbytcIW2RQEQZn8qXvnzkF8ufZEr evtBP2TuzqTNkskyhe7jCE7fDGhKZNWxX0SWf6ijxX8p8WAa3S.UxSicBEX0X8Nv7C5ZLqBoCr9G 2zew55qEpwnMS2K1zotP5M3KxEjfAV8f5BZ4ZRGfgmH39tdCc_4ByCRvKIvKyNGdGadpw.YtPDUN n8OMJiQxlkl1.UZpanY7I17Qh00QN1u.vz09PBaIjGtZCbi432o66NCg7fMu82A6rWv_s2iLlwv1 4..wqm7xJzLNeadB4dFwzkBP4_rvXa.wkNsVOH0JEI4RvQ4VV2aOI80_.0W4uXKWhpuaKs4qzmMD iONG..bITcZxTyuicyUoPL.b.VPuVEaSG0cd7npoDjMGyZut3i1G.bqRyqgceEl3khcHgyfP60I0 zMV7X_USvoHFmv6_hqmVgY.uJTAXP6UQJhoXMzBhxp3JrXqlf0bUFqj6h1zG_4r._ymXkdXaJZO5 AQA2fGKUfYAU4UYnn4ODU6N40l3wsNrkw3A14.083pb55.Q17xYXSTpBn6wdECvYNG.on1c8011T iwAJDyHZxMNxaeQ0WZ3laN1aHioQ813sPYplNuwP9jRFdGvumx17DWzl2J8fVsoglpgQrAam7Ggi VIWFrvwNFIMASl_LUp7CKWWjp5ZA44S5cslP.Ludh9fnQu4cleYMBpNGnXKkdwgKBQ3c7pMIk4OJ 5aKafLa4fneovuYdk55PxaVfmp6okGyYCpRbnG9iDPUu5gSYhe7ABzAX74QaJALl7kUAxhrV6L.z eNDlr5hWUj7BZGXS70zN8j8NeoeoH5fNrk1yNPVCYcWoUnTS.dlhYfTiZdrnoaERP.bTOUFp1gdI ZqOJ6o6SFAKDPSPANjeMTipAHTQC4mPY1izkwPvtp4FtSRkQyaWoHzMq78hgmc9dOpPYvrIj3nlN Yv7T9mHAgB8JhSMVKDjoSBZv6gyT0Nw4vfpIWgeUnYmKB_GE0jTUqtltaJCfvuP14n4pmjIPaJaM 2JAm8w01xW4Z4QhHyfBjmez9MTDhSTC07fZpDg0xFM07mzaDxY5nb9x.gFWuCY7eIpgqfsgzLJ0G VDoAFKNWQWAW_DuCngQYjsuB_N7s75tJ8zKA3gzfTNpJ1YlQsKffYXI6rNF6HJGmgHqdKaWWzcyM tuMpTIiNw5uV1dWYM0fswzzTwb6DGqy9Ze24QQuVrjYfuqt9ctv3zPb_YJFYAHYjG4f9eV7jHJQ8 0hfdKOZnPWjxRYFR_rBOG2CBUUEQNbV6bUids2x2UoLn1fy2bL2KstuUwhLq18tl2dM3.qbOgIo1 5NmCBbR4ZAoGCE8KIWM9TPsjcDcwMx05u8dtclKWX.1KoOFLIx25glCh2UCl2S5LmAx8bJ0nJg97 c21xUXBAnxyY_1v1FgIQppvR6y.Yda_s0d4E8sNdSgZCCUY4EgCxD.JB3VWOQkMKboC.ktogrQTX DZmipUz32YPD14OUTwagjzamKxFEcawXTMRVAHrUesO.RhDk46Kdss9VWd5cO0hbd2.Cj2.DPO47 ip2vs4UDRMVa4zeWC.m0pggFSJRQXSrAwLpL6qG6zAR8j3h6iPE69A_VNyLz1Zr0n2oWtRbapTjC g.CV5KPW928JdWcBIDthFdl2B8Po4JqoaEry4lHfhHPXQ0lM_94d7RhIZybLZfCMfd1zfjA9bbGy MhoezhS1.8CYoaUTCnRFwrIIiN7k8JLJoATsEG1lPUmaCgMjB7UPKgT2X62TxajxDjHF0Mn3ag6s 3_gwmZ5PtBzQ0ugfSjhWz9P64jrKkEFUZ3InsEU0rtFZe2EwuTcpy.5yPBfsA81W9mAxSwXNUeQU zQT6xbmM1dj0CMPTgQW8rW37wT172Gxe6ujSs96.EtdApTDF0xIcSc4LJ1ctFdTxKZbBmbRy3ATY A.ynf1DKEyyGvaGRLu2Q3SvMNysc7ofgmkRoHouLI9QUS.4JEsht_102kLp6o55VJlozRVi.HGJg iE2yuEwKy1dfCYi5kxO5J5AEVY7wcGBc3BlM8rEq4eiLpMvns X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 08:59:18 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7c20201941fc613fa1e8542dbbb437db; Sun, 12 Dec 2021 08:59:15 +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: <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@yahoo.com> Date: Sun, 12 Dec 2021 00:59:13 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: 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> <7EFA98DF-325F-4821-A040-FB4A9E66AB8F@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: 4JBdqd28B9z3RHj X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=fBlHrF7+; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.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)[1.000]; 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.65.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.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 Status: O Content-Length: 10825 Lines: 291 On 2021-Dec-12, at 00:29, Mark Millard via freebsd-arm = wrote: > On 2021-Dec-11, at 16:19, Mark Millard wrote: >=20 >> [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. >=20 > 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. It is now tested (at least to be a useful hack): no longer am I running an older 1400042 kernel. For reference, # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #18 = main-n251456-22c4ab6cb015-dirty: Sun Dec 12 00:34:53 PST 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400043 1400043 And it reports during the boot (other than the "REPLACED"): mmcsd0: 125GB at = mmc0 52.0MHz/8bit/1016-block So it no longer sets up a mode that the rk3328-specific-code does not actually support. (Nothing that I've done here deals with the looping issue when there is a MMC_ERR_FAILED or the like.) > The email handling may mess up some leading > whitespace --but, again, I'm only trying to suggest a type of > change. >=20 > # 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 >=20 >=20 > 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.) >=20 > 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. >=20 > 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. >=20 > 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)