Re: https://github.com/pftf/RPi4 EDK2 RPi4B booting ram_attach crash re-tried via 2024-Jan-11 snapshot, with debug.rman_debug=1 and details about what is wrong
Date: Sun, 04 Feb 2024 08:09:16 UTC
I did some more investigation (EDK2 code and Linux handling) and then got an independent rpi4-uefi-dev "Mario" confirmation of the following about the EDK2 implementation: QUOTE It is indeed a mistake to expose it in _CRS like this, because it does not mean the same thing in the CPU's view of memory. 0x7EXXXXXX is mapped as DRAM in Arm space. END QUOTE So the FreeBSD panic/crash has exposed an error in the RPi4B EDK2 design (lack of address space identification based handling for BCM2844's (a.k.a. \_SB_.GDV0.PWM0 's) [0x7e20c000, 0x7e20c027]). That FreeBSD sees 0x7e20c000..0x7e20c027 as an ARM "Low Peripheral" System RAM address range is what EDK2 is reporting via the _CRS it uses. So the split: QUOTE splitting region in three parts: [0, 0x7e20bfff]; [0x7e20c000, 0x7e20c027]; [0x7e20c028, 0xfd57ffff] END QUOTE is following what EDK2 indicated to do for the range. But FreeBSD later interprets other material as having a range that spans the 0x28 bytes already reserved: ConventionalMemory 000040000000 000000000000 000bc000 WC WT WB which indicates no hole exists in the range. This results in the attempt: QUOTE ram0: reserving memory region: 40000000-fc000000 rman_reserve_resource_bound: <I/O memory addresses> request: [0x40000000, 0xfc000000], length 0xbc000000, flags 0, device ram0 . . . s->r_start (0x7e20c028) + count - 1> end (0xfc000000) no unshared regions found panic: ram_attach: resource 5 failed to attach END QUOTE So, likely, the only question is if the handling should be a panic vs. a error report with error handling that would allow continuing. (But there might not be a generally good way to set up for continuing.) It appears that Linux handles it (views it) as (quoting Mario): "Ultimately it shouldn't cause any issues, it's just reserving away a bit of usable RAM." So: no error reports, no warnings, and no rejection happen. (I've no clue if EDK2 will be updated now that the issue is publicly reported/known. But I doubt Linux will start reporting warnings or such.) Linux shows its results for the EDK2 oddity as: /sys/bus/acpi/devices/BCM2844:00/path : \_SB_.GDV0.PWM0 /proc/iomem : . . . 40000000-fbffffff : System RAM 7e20c000-7e20c027 : BCM2844:00 . . . ff20c000-ff20c027 : BCM2844:00 . . . (That last is what the valid ARM "Low Peripheral" address space range actually is for the 0x28 Bytes. The _CRS had that too. The _CRS just is inappropriate for describing addresses in a pair of address spaces with an address offset involved for going back or forth between the spaces.) === Mark Millard marklmi at yahoo.com