Pi 5: dtoverlay=ramoops merged with 12-byte reg (2+1 cells) despite /reserved-memory #size-cells=2 — kernel rejects region, ramoops never probes

[serialseb]

Describe the bug

On a Pi 5, dtoverlay=ramoops (with or without parameters) produces a
/reserved-memory/ramoops@b000000 node whose reg is 12 bytes —
2 address cells + 1 size cell — while the bcm2712 base DTBs declare
#address-cells = <2> and #size-cells = <2> under /reserved-memory.
The kernel therefore rejects the region and ramoops never probes:

OF: reserved mem: invalid reg property size in 'ramoops@b000000' - firmware out-of-date?
ramoops b000000.ramoops: failed to locate DT /reserved-memory resource
ramoops b000000.ramoops: probe with driver ramoops failed with error -22

Observed merged node (/proc/device-tree), with
dtoverlay=ramoops,total-size=0x40000,record-size=0x10000:

/reserved-memory/#address-cells = <2>
/reserved-memory/#size-cells    = <2>
/reserved-memory/ramoops@b000000/reg = <0x0 0x0b000000 0x00040000>   ; 12 bytes

The shipped ramoops.dtbo carries reg = <0xb000000 0x10000> (1+1 cells),
so the bootloader's merge regenerated the property: the address was widened
to 2 cells but the size was left at 1 — consistent with using the DT-spec
default cell counts (2/1) instead of the values the parent node declares
(2/2). Both the Debian-packaged 6.18.34 DTB and the current rpi-update
master DTB declare 2/2, so the failure is independent of which kernel's DTB
is in /boot/firmware.

Merging the same node offline into bcm2712-rpi-5-b.dtb with fdtoverlay
(from an overlay carrying an explicit reg = <0x0 0xb000000 0x0 0x40000>)
produces a spec-valid 16-byte reg, so only the boot-time merge path
appears to be at fault.

To reproduce

1. Pi 5, Raspberry Pi OS (trixie), bootloader pieeprom-2026-06-29.
2. Add dtoverlay=ramoops (parameters optional) to /boot/firmware/config.txt; reboot.
3. dmesg | grep -i ramoops shows the probe failure above;
   fdtget -t bu /proc/device-tree /reserved-memory/ramoops@b000000 reg | wc -w prints 12.

Expected behaviour

reg emitted with the parent's declared cell counts (16 bytes:
<0x0 0xb000000 0x0 0x40000>), ramoops probes, /sys/fs/pstore becomes
available.

System

• Raspberry Pi 5 Model B Rev 1.1, NVMe boot
• Bootloader: f68405bcf704b03511bf1656e86924e8cd6398b4 (release, 2026/06/29 00:07:01) — newest available in both apt (rpi-eeprom 28.28-1, trixie) and this repo as of 2026-07-23
• Kernels checked: 6.18.34+rpt-rpi-2712 (apt 1:6.18.34-1+rpt1) DTB and 6.18.38-v8-16k+ #1991 (rpi-update 2026-07-15 build, running)
• Context: needed ramoops to capture traces for Pi 5: NULL deref oops in dma_direct_unmap_sg via drm_gem_prime_fd_to_handle error path during HDMI hotplug (6.18.34+rpt) #7504

[pelwell]

#7518 should fix it for you - it adds a Pi5-specific version of the overlay, compatible with #size-cells = <2>;. In about 25 minutes you should be able to install a trial build of the kernel using sudo rpi-update pulls/7518. Be sure to read the caveats first.

[serialseb]

Thanks for the quick turnaround — much appreciated. I'll install the pulls/7518 trial build and report back with the boot log — whether the ramoops region survives the firmware merge on the 2026-06-29 EEPROM, plus the resulting /proc/device-tree reg — as soon as I can reboot this machine; it's mid-use right now, so within a day.