15 & 14: ram_attach vs. its using regions_to_avail vs. "bus_alloc_resource" can lead to: panic("ram_attach: resource %d failed to attach", rid)

ram_attach is based on regions_to_avail but that is a problem for
its later bus_alloc_resource use --and that can lead to:

panic("ram_attach: resource %d failed to attach", rid);

Unfortunately, the known example is use of EDK2 on RPi4B
class systems, not what is considered the supported way.
The panic happens for main [so: 15] and will happen once
the cortex-a72 handling in 14.0-* is in a build fixed by:

    • git: 906bcc44641d - releng/14.0 - arm64: Fix errata workarounds that depend on smccc Andrew Turner

The lack of the fix leads to an earlier panic as stands.


sys/kern/subr_physmem.c 's regions_to_avail is based on ignoring
phys_avail and using only hwregions and exregions. In other words,
in part:

 * Initially dump_avail and phys_avail are identical.  Boot time memory
 * allocations remove extents from phys_avail that may still be included
 * in dumps.

This means that early, dedicated memory allocations are treated
as available for general use by regions_to_avail . The distinction
is visible in the  boot -v output in that:

real memory  = 3138154496 (2992 MB)
Physical memory chunk(s):
0x00000000200000 - 0x0000002b7fffff, 727711744 bytes (177664 pages)
0x0000002ce3a000 - 0x0000003385ffff, 111304704 bytes (27174 pages)
0x000000338c0000 - 0x000000338c6fff, 28672 bytes (7 pages)
0x00000033a30000 - 0x00000036efffff, 55377920 bytes (13520 pages)
0x000000372e0000 - 0x0000003b2fffff, 67239936 bytes (16416 pages)
0x00000040000000 - 0x000000bb3dcfff, 2067648512 bytes (504797 pages)
avail memory = 3027378176 (2887 MB)

does not list the wider:

0x00000040000000 - 0x000000bfffffff

because of phys_avail . But the earlier dump based on hwregions and
exregions shows:

Physical memory chunk(s):
  0x001d0000 - 0x001effff,     0 MB (     32 pages)
  0x00200000 - 0x338c6fff,   822 MB ( 210631 pages)
  0x33920000 - 0x3b2fffff,   121 MB (  31200 pages)
  0x40000000 - 0xbfffffff,  2048 MB ( 524288 pages)
Excluded memory regions:
  0x001d0000 - 0x001effff,     0 MB (     32 pages) NoAlloc 
  0x2b800000 - 0x2ce39fff,    22 MB (   5690 pages) NoAlloc 
  0x33860000 - 0x338bffff,     0 MB (     96 pages) NoAlloc 
  0x33920000 - 0x33a2ffff,     1 MB (    272 pages) NoAlloc 
  0x36f00000 - 0x372dffff,     3 MB (    992 pages) NoAlloc 

which indicates:

  0x40000000 - 0xbfffffff

is available as far as it is concerned.

(Note some code works/displays in terms of: 0x40000000 - 0xc0000000
instead.)

For aarch64 , sys/arm64/arm64/nexus.c has a nexus_alloc_resource
that is used as bus_alloc_resource . It ends up rejecting the
RPi4B boot via using the result of the call in ram_attach:

                if (bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, start, end,
                    end - start, 0) == NULL)
                        panic("ram_attach: resource %d failed to attach", rid);

as shown by the just-prior start/end pair sequence messages:

ram0: reserving memory region:   200000-2b800000
ram0: reserving memory region:   2ce3a000-33860000
ram0: reserving memory region:   338c0000-338c7000
ram0: reserving memory region:   33a30000-36f00000
ram0: reserving memory region:   372e0000-3b300000
ram0: reserving memory region:   40000000-c0000000
panic: ram_attach: resource 5 failed to attach

I do not see anything about this that looks inherently RPi*
specific for possibly ending up with an analogous panic. So
I expect the example is sufficient context to identify a
problem is present, despite EDK2 use not being normal for
RPi4B's and the like as far as FreeBSD is concerned.

===
Mark Millard
marklmi at yahoo.com