From nobody Sun Dec 12 21:38:19 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 65B4418D4D5B for ; Sun, 12 Dec 2021 21:38:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4JBygZ0Mrbz4pLb for ; Sun, 12 Dec 2021 21:38:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639345106; bh=/JHnhbsIw4UJhFzD2BJi54InuVFSsGe0sl0ng/D8VFk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=R5W0N8hqKi5MANU4ar5JMc43UHZQeKr6OBW+JMqF7TA28Pwj6f/ySYWDPAT0K5dfnk7BkVhhRv7B0nVSChfRVxG7Yn2sR8SEdntbvb6zcU92IA7BrRPuSe5qrhjXfgakdmcKSYAmwdVHkD1aXGIztfATm/SGyrYh4BP3EwfN5BG5hH7ucbbSSqZCIWsscMfBxKCm16WygpweKJNr3UGUHpnqJo+46xhsMwodUAkuXDBnmpspQziAle5GB7ElK0UQ4gxBGDHVsTEjzntnj4Xva5rE8b1S1Bfbe2w6HSUVLB63fWhTHMOXqt0CaLAl0lbesfifvebV+Kyb448QaTylFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639345106; bh=pBhb8ubbxAiy7RcFG0PoGGylUf56AWojSPMlfO/p/zn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=G+tXpOvHr94rsO17kzC9dx6BU7fR44kOyAaenyk1NCYH8K4cbT7/n4QJvotRHjVPJGAPdpb6CEXvXJSv3EiWMRckIxeSkSJZZKGoeEgXDebBRZN75BJ4pYlaz0dyVqXx4mIk1a9s6UhRQQgy9JgZcTXCVQW6zY5v8Sp0jYRGF9nVH3vhnqrUqtUc+j0mXs5XJmfnerZclNMtxtjHbh493uUxC8l9QI/urR7FecxXDke5QvG13ykCfx5+qKKfkGV/a0x3VsmBzJxGb3Cc1lpnDgmQ9Y2j1oJ1tip+4iKRnd+ALKVRgmr1wZStVnWf7cLlqx/n8YtW3ouHEz1LS0fIcw== X-YMail-OSG: ctsW4vIVM1l0SrZzcnr572jz3H2EnD1tOJ5XtplmLsE0supg1fLVuWUntWgRqSb L41eMHDyFqufXiKkzdyrJgkNOHXK5Kr3qS1rE5xgd5h49gwbO5gGsOJei3cndteiC11HvHZ4tfyd Y8BCsc5ifY2ue7G6YuYbXin0gk1XAhGhzMa9h83_Q7GknYKB71cv1go.7K0yTvpIWwAveWEcuQ4v AKIPvXCL88AdUxICoVrASAQ663k0vcg9q0bPdMqJWdVu6Lh1XhVhZcI3L2xJczyu2_.dNTK36ejg Md2hUKxGpRt4.X7DVxxvGxnnLVceDWZNWMAY4ThgVdm8UDNTKAHZAV_V_nGf0lDb1PBreDsJXDLJ ZtGx4bmZ6kqxh7yW.2KzvblDo5u1ECx5_ffFEmOT6LxZbNSLcUcW1rDdpxF33.jboz22MLP643gB 9FOiCVGjORllS4j_Eou83Bq9tND3rsfb0FrP1LDYRYg5MXOFEtGRurhMzOEbQVq0Xeod7aP7WyAX JTqX.ZykgAHOE6kVjgwnYVJE83fK65NYmET2D9Dp3h.6cQMa13aSR5Y.1O5zrgup.f4ax9mm7DrS IPj92Bgzer9dHbGseRfc.5IKgGjxOs4rCbHJjcRJOgnxAWbLhAF1c3RohXJDXrEnFezXqXohoe.J ZSBPfavLITRGTHu_hur5_iC9pslNAiihzMlIpDLkzm0iCxbYP5bvySCplJjUws3YT1_8jNovUyJN vSTjCkJmaJzSxV3HVcQTtfKoGf41r8eL31u5IT9XwKreqOEy5vFJSSRNK6sjc3hT7SA6fbI596iW ofrdDyIKF5pXC0o02boDGvt9FJYGGgXw9410Kz8Xp3LyA_66P2O5Vs2mZE7jaAtKGkqpvyHeqGd_ Syc12YfiwluhcC18wq8tYsb3tVtLfdKUfnVPAMOPaY7T_epOSCW._7Ku_0_5XZQRr_qrRPEcvbz5 G9S.Cuz26Axmdb.bMqqj6ph.9l3za4Wktx383bL4jqCbgGdpImpbfuhCaRW9nG6Z1AIOWfUl5gKE 5YJKuRH.VadPNhlrUQpzf3plAbMZiXRuFKLK2uJcGyCZ.Iuo167Uct8DsEdIqryMvSHAoOFywgFD U7KFBnxPCdrnobR0ws1YTXxn4MYw3dazBzWFM7HtIhyK.kAafsW2elejJW3sRYSyWOv2.hQFUhiE 0pv54hoSdu9BXVGISDXBPGUzxAoMOgHfOZCelvr1BiqOo7ouWoyeMFvPSEc_MUmiuD2qjKJBrRVJ Ol_mxZIplg5IiReQSizOvLk0Vh8DlfIXgB74P.pfdnvf.HjJJEgkZZplSIujAFrB7swDaZ3q9nKc OVMGcWT.rAuZ7y7dhjrgbN24fR1TU.8oQ2NJ95IJSdsamRaW4m0MzdTxV.oH0uVEdqU3vu78PvZ9 w0rHW8M7B2nn6TZF5Eus1aVzvVSvVN0qF7SCOqDPhpHwavmdLvaLejFA35gbhRu0cdnMGMBU_6So BbU.P2sCftIOdPFMkPq.zg8ooDfMCmXdIeh6VN9mbGxRkU0HKcZhe9mFqXL7G6XYj6zjTFbnue7I 0vvTa6SNDpDkfeU9mddWoNbV7gkscsMqtxScWW4T2J9.OXBLD7IdeaBnnJqVOcMJ7r4KDSM_lCgg 1tcUy_8wBSsdaGIUyxefB2A3NDJ1vK4mIPLeDSbrs3hBO23MPvxZpQgKQkBF9hYwpqoYghqGo5.G G2dKD4lTYo74oGVk8TRhxAWZ.ldFQzMVS5bkEEZJm7amEYk_YqySUTbSmGCjWrjroZmBu6IpuOMd F0ET5ocqhWFjHqYuMt5xfNvm1n6KkoioCtqnMR4em95l_c0GjLHnpCQi8MQs17UNJm2DwGmBYiRM VYhug8T3Lu41tbuVy0jlZfg7b.BLZ3rt7AN.N7rdWvAwzsKb3aWfZx2g6pAT8BwSLwMZI1mwNzDp QZMKXP.G1tb6.IEOJVNRyKVtfieWMEXbxRnyf1biPZ5XyGsBGF.bHxrNwUQRwqddJgkkaXKgk4Yw X6BprgWethoR.TGGe9r1inurzvjceG.mGNFCe6megZM34VNQN10rHjvpW50iduZXCYoqAthr.RXa tA3x5MiN5wLeyYtK1NPAOPLXra4JTQTmcz9ZBHHfALwqOhaF3qZSeWzMT_cCQ2vhgGL38DJiiAmS bvufSviCK9GMaGyFtPc_EneLJ.5Nf.WGp0HRqY0PWztLyGVK.1XK51GZXf9YXSQXtTpXbdhjLf0W eGfONT0iU_1l7Gf2t6hFtGfT2dVtRtXi.2hPO7WQSy3JBe4INhx5gxdBp4bv6JiKyDsNm3Lm17Tg dqMBDkA_6i6a5hMZleLfaG_1wz93z X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Dec 2021 21:38:26 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4af5f81e35173ada683013ac15b3d8f3; Sun, 12 Dec 2021 21:38:21 +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: Date: Sun, 12 Dec 2021 13:38:19 -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: 4JBygZ0Mrbz4pLb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=R5W0N8hq; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.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]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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)[-0.997]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147: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-12, at 00:59, Mark Millard wrote: > On 2021-Dec-12, at 00:29, Mark Millard via freebsd-arm = wrote: >=20 >> 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. >=20 > It is now tested (at least to be a useful hack): no longer am I > running an older 1400042 kernel. For reference, >=20 > # 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 >=20 > And it reports during the boot (other than the "REPLACED"): >=20 > mmcsd0: 125GB = at mmc0 52.0MHz/8bit/1016-block >=20 > So it no longer sets up a mode that the rk3328-specific-code does not > actually support. >=20 > (Nothing that I've done here deals with the looping issue when there > is a MMC_ERR_FAILED or the like.) >=20 >> 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. >=20 >=20 As for what was happening without my patch . . . sys/dev/mmc/mmcbr_if.m defines: static int null_retune(device_t brdev __unused, device_t reqdev __unused, bool reset __unused) { return (0); } static int null_tune(device_t brdev __unused, device_t reqdev __unused, bool hs400 __unused) { return (0); } . . . # # Called by the mmcbus with the bridge claimed to execute initial = tuning. # METHOD int tune { device_t brdev; device_t reqdev; bool hs400; } DEFAULT null_tune; # # Called by the mmcbus with the bridge claimed to execute re-tuning. # METHOD int retune { device_t brdev; device_t reqdev; bool reset; } DEFAULT null_retune; . . . It is these success-reporting no-op routines that were being used to attempt the tuning: so there was no tuning done. The code that I added detects that these routines would be used and avoids allowing contexts that would involve putting them to use with HS200 mode. I'll note that there is another such null_* routine that the code (even with my patch) does not deal with avoiding the use of: . . . static int null_switch_vccq(device_t brdev __unused, device_t reqdev = __unused) { return (0); } . . . # # Called by the mmcbus to switch the signaling voltage (VCCQ). # METHOD int switch_vccq { device_t brdev; device_t reqdev; } DEFAULT null_switch_vccq; . . . /usr/main-src/sys/dev/sdhci/sdhci.c has somewhat analogous code for somewhat analogous null_* routines. null_set_uhs_timing for that is from sys/dev/sdhci/sdhci_if.m (but the other two are again the above null_tune and null_retune routines, so not repeated here): . . . static void null_set_uhs_timing(device_t brdev __unused, struct sdhci_slot *slot __unused) { } . . . METHOD void set_uhs_timing { device_t brdev; struct sdhci_slot *slot; } DEFAULT null_set_uhs_timing; . . . sdhci_init_slot(device_t dev, struct sdhci_slot *slot, int num) in sdhci.c looks like (in part): . . . /* * Disable UHS-I and eMMC modes if the set_uhs_timing method is = the * default NULL implementation. */ kobj_desc =3D &sdhci_set_uhs_timing_desc; kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) host_caps &=3D ~(MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | = MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_DDR52 | MMC_CAP_MMC_HS200 | = MMC_CAP_MMC_HS400); #define SDHCI_CAP_MODES_TUNING(caps2) = \ (((caps2) & SDHCI_TUNE_SDR50 ? MMC_CAP_UHS_SDR50 : 0) | = \ MMC_CAP_UHS_DDR50 | MMC_CAP_UHS_SDR104 | MMC_CAP_MMC_HS200 | = \ MMC_CAP_MMC_HS400) =20 /* * Disable UHS-I and eMMC modes that require (re-)tuning if = either * the tune or re-tune method is the default NULL = implementation. */ kobj_desc =3D &mmcbr_tune_desc; =20 kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) goto no_tuning; kobj_desc =3D &mmcbr_retune_desc; =20 kobj_method =3D kobj_lookup_method(((kobj_t)dev)->ops->cls, = NULL, kobj_desc); if (kobj_method =3D=3D &kobj_desc->deflt) { no_tuning: host_caps &=3D ~(SDHCI_CAP_MODES_TUNING(caps2)); } . . . What I've done in my patch is analogous to what the the code shown after the #define SDHCI_CAP_MODES_TUNING above does, translated to fit the mmc's pre-existing code structure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)