Date: Mon, 4 Apr 2022 04:53:14 -0700 From: Mark Millard <marklmi@yahoo.com> To: Free BSD <freebsd-arm@freebsd.org> Subject: Re: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants with matching firmware requirements; more Message-ID: <8A72AF2D-339D-4A31-B31F-524E29E9A327@yahoo.com> In-Reply-To: <BC0F3716-4598-4D9B-924D-35DF219A40FE@yahoo.com> References: <BC0F3716-4598-4D9B-924D-35DF219A40FE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Apr-3, at 23:44, Mark Millard <marklmi@yahoo.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A72AF2D-339D-4A31-B31F-524E29E9A327>