Date: Sun, 3 Apr 2022 23:44:29 -0700 From: Mark Millard <marklmi@yahoo.com> To: Free BSD <freebsd-arm@freebsd.org> Subject: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants with matching firmware requirements; more Message-ID: <BC0F3716-4598-4D9B-924D-35DF219A40FE@yahoo.com> References: <BC0F3716-4598-4D9B-924D-35DF219A40FE.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The 2022-Feb-08 https://forums.raspberrypi.com/viewtopic.php?t=3D329299 reports about v1.5 (via a "Moderator" "Engineer"): 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 I will note that, separately from this, the 2021-Nov-24 https://forums.raspberrypi.com/viewtopic.php?t=3D324653 reports about the stepping with the C0T labeling (via a "Moderator" = "Engineer"): 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 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 https://github.com/raspberrypi/linux/issues/3210#issuecomment-680007995 = : Old (B0T): emmc2bus dma-ranges ending in 40 00 00 00 New (C0T): emmc2bus dma-ranges ending in fc 00 00 00 (Not visible via a separate .dtb file: the device tree is dynamically adjusted to match the stepping before being handed over to later = stages.) =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. =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: https://www.mail-archive.com/u-boot@lists.denx.de/msg409182.html I do not know the first U-Boot release to have a change for the type of issue. Overall I do not know the implications for FreeBSD's status. I only have access to older RPi4B's. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC0F3716-4598-4D9B-924D-35DF219A40FE>