physmem: Move the ram0 device earlier in the boot

[andrew]

Summary

If the ram driver is unable to reserve a memory range it will panic
with no real information why. Move this driver earlier in the boot so
any devices that cause the conflict will fail to attach.

This should make it easier to debug why the conflict exists.

Sponsored by: Arm Ltd

[mhorne]

Yes, this is smarter.

I kind of regret adding this thing. Although it is conceptually helpful/correct, its positive practical impact has so far been zero, while it has created several headaches.

[kevans]

In D48766#1112402, @mhorne wrote:

Yes, this is smarter.

I kind of regret adding this thing. Although it is conceptually helpful/correct, its positive practical impact has so far been zero, while it has created several headaches.

Meh, it'll turn its life around- more failure to attach because of it rather than panicking will trend it back towards positive practical impact and fewer headaches, and it's a pretty small diff to get there.

[markmi_dsl-only.net]

I will note that this "fixed" the ability to boot RPi4 via its EDK2. Instead of the prior panic, in this order the overlap testing ends up doing (I explain the result being okay afterwards):

rman_reserve_resource: <I/O memory addresses> request: [0x7e20c000, 0x7e20c027], length 0x28, flags 0, device (null)
rman_reserve_resource: trying 0x3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x2ebfffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3017dfff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x37fbffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x37feffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x380dffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3813ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3851ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3875ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3877ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x387bffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38960fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38963fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3897ffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38980fff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38eaafff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x38eabfff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x39bdffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x39fbffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x3b3fffff <0x7e20c000,0x27>
rman_reserve_resource: tried 0x4024afff <0x7e20c000,0x27>
considering [0x4024b000, 0xbfffffff]
region is allocated
considering [0xc0000000, 0xfd57ffff]
s->r_start (0xc0000000) + count - 1> end (0x7e20c027)
no unshared regions found

The RPi4's have DMA engines (or other such) that do not use the aarch64 address space and [0x7e20c000, 0x7e20c027] with length 0x28 (which is for PWM0) is one of them and is used only with those DMA engines (or whatever). The overlap with [0x4024b000, 0xbfffffff] for ram0 is actually irrelevant. But in the old ordering it was treated as relevant and reported the overlap via a panic. As stands with the new order, the overlap is the indication of the address space not being the aarch64 address space and allowing the (fake) overlap is the right thing to do.

The RPI4's have other such ranges tied to hardware interfaces that do not use the aarch64 address space. For contexts that are analogous, knowing the address space is a mismatch with ram0, via the position in the (here PWM0) _CRS information being one that is not expressed in aarch64 address space terms, would be more direct for avoiding even testing such for an overlap with the aarch64 ram0 ranges. But the overall result (other than the "no unshared regions found" message) seems to be the same.

I'll note that in the edk2-platform code the relevant _CRS text is:

MEMORY32FIXED (ReadWrite, BCM2836_PWM_BUS_BASE_ADDRESS, BCM2836_PWM_BUS_LENGTH, )

The BCM2836_PWM_BUS_BASE_ADDRESS name is suggestive of the address space issue and gives some terminology to help look up to discover the address space distinction. The ", )" indicates the lack of any hook for dynamic change to the address value involved. Having a name instead of empty is associated with later code making an adjustment for what _CRS produces. The lack of use of MEMORY32SETBASE is relevant here as well.