From nobody Mon Apr 04 11:53:14 2022 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 3CA091A820A0 for ; Mon, 4 Apr 2022 11:53:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (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 4KX8LG0LJSz3npg for ; Mon, 4 Apr 2022 11:53:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649073198; bh=zOrp4o2GrDF0IJ/MJMWYorc9R2ZJUN4jlsuHDMpdMjg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=BEyATo3cp1P+3c7YYi/My77TgJTOuWyVWL3k0Cxm6BG4az79B4WDvaRjXrg0ZKhJfXv+w03YgG+UiVamuhXkJ981MC0Rt0bITsI+0YQhdHMOcSTRWOGDRII0s+FKqHYjxQQjSr11ZY1dLhKZUSjg/t88TQ/SRJ7GD0ypH+NiwZBtzVWc79Z88vZB8byJpXlDxX59k6yKW39y375/b+8XnbMKZMgI82TYkxgs/D1T3vVwAXi+lr1q2LD9Dl4RxiwsCiWDAlezHOcolLPS6sBrMrGV0uDPALBzavsKEIc+XIX6SlvrFY4Of3tAd05hNH4oAdBuHaDs44tYNso1K3ufqA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649073198; bh=9ZB0O9TSIrg2HoDvfoQ4yK25UUV/BEVEDcXaijqvx+D=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KpBMdzKpZlhz+QJU6RNNFwvy7a7NLA7dYq4S+US532Wb8zI8jTvax3MGN1GvbBheZzzWkBXtWzQlZM3kR+nH+vZd4B8xlBPYpnBurwrcq5XvoQRP53zaputqqysC2xXFFRQSy29ztzVHh/DU6kbSzoi1OxRfhJCioYKrhH3+G564cPavL0PhM9RFcWJxtl8fd+3ZQpTC7fn/KaXv/0rcLDrNKusnxen1NX6HMa5DK1YumNBCfHybDg60Lo29QY0PJMXLZg+dfFmuvChDo54tGJYDPzFwHldfhUdaXubNi1NZsww4Gb2XT+eUTAvd3SWB+1l8tddsR7Zk5vMQcT2olg== X-YMail-OSG: NlyJiT8VM1l8jZJ3fSoOBS_oDugkLWlMERAY1.G1C_AzadFUsGY9dRbWuI4SN_a 3L7ZjuTT44rREWBR.CakVOIiTTpvPTMW9R8GAyQnOiuc6ylsHM8i4mUAZmSOK81eftFvY5LQWKv7 KJ8_nKABRinRYvUEKAOu5u_U2scZi_zCzeZBNYdfWJJl2cJsg3fZ6nh8luUCEloEt_k3fSJuGoCw ISe2u1GHeawvPFf1o0epfihqQpB6Xj6bM8FrEMwE4t0zRH.E6b6OitlXU3kNOD3zIRrgo.W.Sd02 QOARAKzqEJJQ7Zg6H2C6t99Zhv.XMbNZV_Hb20u2eSxe4nW_3AzGvcZsvVk8WkZfkbv8oQtJzXu9 nL6zHo69pGCG8hqi48bwxDQNaWnCvdHDi2dzrXlR7_LLUX7__.tJK3.Q5p5PEHngWWQddTQvX2Dc EkagLDOSMx7FIoNMarAM.bKMCuG9wOZ4zTU_qk81Ak4W1cKGkPkC8SKB8l8moC4dM3YGxTQLuCfq wuwm4z0HalkiFA3NMs1sM.pcrBVgrsHNJ_xKuPycoBn3gk_RyvzdfqdIvaaQb7MEEkbN0o.m7FG_ 0JNNnFmsw.o4HwjxHvgEe92Gqk7H_3gLgKNqEhnEjKy6DXbozk9eFnljOyrA2m.nkbFuN5E1mplb AdIbQXOO4UJ7a6dNuUsmZtGYh5XUElOjAwQy2_xc638IHJVPtWqKwBLF.gFSjzk9vGHDXnBNrYJX 3XznJx4DlJYEpeAbMPvA4GUre4tjbz5S4eWKYQpXFSmpFAqKyptLAMLa5JsBTp9hTdlP3KnVn1QP 3sHqJ9lk6V1zsxZLJFjaZhRjRXDJkG_xRVFGuQWaGlDWL0Bu7fBQ82LoB2ysWa7K9TKbPhG2MQ.X MbF_oSJBWeA1GAtbPTS7tgkb_1zbR0tM64UALiNCvRMm.KEbIR47pa5rjJRc4C9EHuboqXw.H9NE X1Iepx8dSNxaksS1Xv5Rd9FwkAwBqbaw.1._iOEplIk9hc3mzc75EMxP7dLiq8WjtRt1WNKoJjfX Cy77fZ80cE5gywODixuI9H3pYyIn83sP8NxvPEV5T_6dT.RD1lP8Yxg4ttz637wNjC1Jqfn9R7VT 72u_lBLEsocCpgfKjTJVglt_8EJlaw_Ycxe7.4ItGzZ9tnCeVgBaXPWb2odLqs3VNz3FGHA_CgAx TCCl7VG3a7MJ1K0zazrqFppqfIlzHoNXacfyralowKvdVHozoEgYKZ1jhWr2mZkCq9WkY9g.dHOi fCtjAYZkJWbXT_zx8z_bAsUHja9MlF9AjAy5.luCHZuLna0EzheTn6v0ThyUuZSQ7P6xj.VawXCj T6n.7m0NSbtuOQGt9QTBD8EE6TYw3V8qUw_eMhDBwgALt_pWmh1w_KOy4Zrw00wV0fwHP9uRCfHT 5OwSuxKtDE.bKkz6Yv1SD71NH6fLMWMEZV0q7YPIocIaGPhZg40idrWhfCUhaUSpArgc6JUwVXOa fdMP_gIuxr3EUby8q4CwqPep_F_rA2Ss8Q6v2wHsf06L8zTElZyzGwIsyH05qTFTrQPadXSUBW8q ujZGa1rleRFxYv2s2n7g.OGU8IEu8c6etEjRyg0khlyxMwgzq2nA_eEgsYtXP8a7gxLRCCaSDklM iiAzl1wNJSQr_pbDf_5qkG8pY41b3xnl4hgGNqHVEPMmFo2mnTJZYTLoLOXT50rklbwxjEPysqyo LkslKeNLe7uFNnDgxgNMwhp79cHYZMRjbZDNeSkrPn_hzS5_ANOftmwMRRsxqVJD1IRMCkq4zQTv SOso3Diee3Aw2C6om7IW3SEK_eQfzmNWvF5AK97Hft6kviZ3B5hGDLrgaDS1lmGaGwbq3iitJy5e g0xpYH3tKO7QY_lE2SqSldyVCT_L5_eoqn4_mD01raiEl0Gn_3OZDJZnBrOGY4d4hfxmteLW5cDq 1jf2.iw7SUde200u6s3U5snXti_LwJ9PRwVlp3_CcD18K1khV7BGJmt0Ip.YwrxE.cb88Jb5aIvt i1lyoaZ2rq61za1AdOSgCskro44aXw.5jfSxr6XKBElEq32xNiwwGqEzGrecjwrRF2bNrxfk_DQV U4RGnYJRxTPaL2x8s6esKlSDmSCjPzT.Ri7Bibj.djv_Xdp6sbIeDbaAftDHzaFAn9AsFUkJmFXJ Dtq790N0XmzWBBztdQ2X6.FVkEsfBzeC4oHJYY_1KCj3Q6CocTJbeCo.UIii_gG6WkN7eEo1VeHz 88BP3ckkxtS7DF0qnyboAXPaa7ghq58sv3EAQDDVakbmNGo8Aqb7lQdfGKor4w_l06cUc_A.EVVI - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 4 Apr 2022 11:53:18 +0000 Received: by kubenode522.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 688755483e26b384645d51c1fc052df7; Mon, 04 Apr 2022 11:53:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants with matching firmware requirements; more Date: Mon, 4 Apr 2022 04:53:14 -0700 References: To: Free BSD In-Reply-To: Message-Id: <8A72AF2D-339D-4A31-B31F-524E29E9A327@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KX8LG0LJSz3npg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=BEyATo3c; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 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)[-0.999]; 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]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-3, at 23:44, Mark Millard wrote: > The 2022-Feb-08 https://forums.raspberrypi.com/viewtopic.php?t=3D329299 > reports about v1.5 (via a "Moderator" "Engineer"): >=20 > QUOTE > The PMIC has been changed. Needs firmware from April 21 or later. > . . . > The bootloader has supported this since Apr 2021 (previous default = release). > END QUOTE >=20 >=20 > I will note that, separately from this, the 2021-Nov-24 >=20 > https://forums.raspberrypi.com/viewtopic.php?t=3D324653 >=20 > reports about the stepping with the C0T labeling (via a "Moderator" = "Engineer"): >=20 > QUOTE > Any current production of 8GB will be C0 anyway. > . . . > And just informationally, the C0 stepping fixed a bug in the = accessible memory region for one of the peripherals, and improved some = power gating on some HW blocks. The first means a driver no longer needs = bounce buffers, and the second we save a tiny amount of power. > END QUOTE >=20 > Other sources report the EMMC2 bus addressing as no longer limited to = 1 GB > and the PCIe interface addressing as no longer limited to 3 GB. The > following information is listed (in a different form) in >=20 > = https://github.com/raspberrypi/linux/issues/3210#issuecomment-680007995 = : >=20 > Old (B0T): emmc2bus dma-ranges ending in 40 00 00 00 > New (C0T): emmc2bus dma-ranges ending in fc 00 00 00 >=20 > (Not visible via a separate .dtb file: the device tree is dynamically > adjusted to match the stepping before being handed over to later = stages.) >=20 > =46rom what I've seen checking on the web and the like, it looks like = the > C0T stepping usage is not limited to the 8 GiByte RPi4B's (or even 8 = and > 4 GiByte): 2 GiByte examples are also reported as having been = received. >=20 >=20 > =46rom what I saw, U-Boot had some 0xff800000UL instance with a = matching > size of 0x800000UL that was proposed as changed to 0xffc00000UL and > 0x400000UL to avoid overlapping newly updated ARM/VideoCore firmware > memory use. (I'm unsure if this is related to the wider addressing > ranges reported above leading things to have been moved around.) The > reference is from 2021-Jun-17: >=20 > https://www.mail-archive.com/u-boot@lists.denx.de/msg409182.html >=20 > I do not know the first U-Boot release to have a change for the type > of issue. >=20 >=20 > Overall I do not know the implications for FreeBSD's status. I only = have > access to older RPi4B's. >=20 FYI: I did an experiment with modern RPi* firmware, with both U-Boot and RPI4-UEFI-dev v1.33 (but having the 3GB limit enabled). It appears that there are possibly significant additions/changes to the device tree content presented to U-Boot but I've no clue if this explains some of the below or not. I did not expect this experiment to end up correctly booted via U-Boot/Device-Tree usage. It did not. Note: My new understanding is that 2021.10 is the first release with the 0xffc00000UL and 0x400000UL usage. The U-Boot I had around to test was based on building 2021.07 from one of the ports (with some historical patches for my context). This contributed to my expectations. RPI4-UEFI-dev v1.33 based booting with the 3GB limit enabled worked with the firmware/dtb combination. FreeBSD got "clk_fixed4: Cannot FDT parameters" (and another message) over 50 times if I counted about right --and crashed with a backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x30 vpanic() at vpanic+0x178 panic() at panic+0x44 data_abort() at data_abort+0x2bc handle_el1h_sync() at handle_el1h_sync+0x10 --- exception, esr 0x96000004 bcm_dma_allocate() at bcm_dma_allocate+0x88 bcm_sdhci_attach() at bcm_sdhci_attach+0x310 device_attach() at device_attach+0x3f8 bus_generic_new_pass() at bus_generic_new_pass+0x120 bus_generic_new_pass() at bus_generic_new_pass+0xb0 bus_generic_new_pass() at bus_generic_new_pass+0xb0 bus_generic_new_pass() at bus_generic_new_pass+0xb0 root_bus_configure() at root_bus_configure+0x40 mi_startup() at mi_startup+0x224 virtdone() at virtdone+0x7c KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x48: undefined f901c11f But I've no clue if the U-Boot vintage might be the fundamental issue, such as via trashed memory content vs. the RPi* firmware. The "Using DTB provided by EFI at 0x7eef000" does not have the historical address listed. The boot also reported: WARNING: Cannot find freebsd,dts-version property, cannot check DTB = compliance My guess is that RPI4-UEFI-dev v1.33 with the 3GB limit enabled(?) has a good chance of booting the modern RPi4B's. But it will have the historical lack of support via ACPI booting for: the built in EtherNet the built in microsd card slot I've no clue if a RPi4B that has no 3 GB limitation would happen to be handled appropriately by FreeBSD under ACPI use that does not impose the size limit. It might, for all I know. So there may end up being a class of RPi4B's that are more supported by using RPI4-UEFI-dev v1.33 than by using the U-Boot ports. (To my knowledge no one is working on keeping things working for RPi4B's [or pi400's or such].) =3D=3D=3D Mark Millard marklmi at yahoo.com