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

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