Re: RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants with matching firmware requirements; more

In reply to: Mark Millard : "RPi4B's got a PMIC replacement, so now there are Rev 1.5 variants with matching firmware requirements; more"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Mon, 04 Apr 2022 11:53:14 UTC
On 2022-Apr-3, at 23:44, Mark Millard <marklmi@yahoo.com> wrote:

> The 2022-Feb-08 https://forums.raspberrypi.com/viewtopic.php?t=329299
> 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=324653
> 
> 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.)
> 
> From 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.
> 
> 
> From 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.
> 

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].)


===
Mark Millard
marklmi at yahoo.com