Page MenuHomeFreeBSD

kboot: aarch64 memory enumeration enumerate_memory_arch()

Authored by imp on Jan 29 2023, 3:14 PM.
Referenced Files
Unknown Object (File)
Sun, May 26, 3:44 AM
Unknown Object (File)
Sun, May 26, 12:19 AM
Unknown Object (File)
Sun, May 26, 12:19 AM
Unknown Object (File)
Sun, May 26, 12:19 AM
Unknown Object (File)
Sun, May 26, 12:19 AM
Unknown Object (File)
Sun, May 26, 12:19 AM
Unknown Object (File)
Sun, May 26, 12:14 AM
Unknown Object (File)
Fri, May 24, 4:05 AM



We have an odd situation with aarch64 memory enumeration. The fdt that
we can get has a PA of the UEFI memory map, as modified by the current
running Linux kernel so it can retain those pages it needs for EFI and
other services. We have to pass in this EFI tablem but don't have access
to it in the boot loader. We do in the trampoline code, so a forthcoming
commit will copy it there for the kernel to use. All for want of /dev/mem
in the target environment sometimes.

However, we also have to find a place to load the kernel, so we have to
fallback to /proc/iomem when we can't read the UEFI memory map directly
from /dev/mem. It will give us good enough results to do this task. This
table isn't quite suitable to be converted to the EFI table, so we use
both methods. We'll fall back to this method also if there's no EFI
table advertised in the fdt. There's no /sys file on aarch64 that has
this information, hence using the old-style /proc/iomem. We're unlikely
to work if there's no EFI, though.

Note: The underlying Linux mechanism is different than the amd64 method
which seems like it should be MI, but unimplemented on aarch64.

Sponsored by: Netflix

Diff Detail

rG FreeBSD src repository
Lint Skipped
Tests Skipped
Build Status
Buildable 49470
Build 46360: arc lint + arc unit

Event Timeline

rebase / refactor / redo


fd2 seems to only exist to close it upon error


Doing try or Attempting, perhaps?

From review comments: kill fd2 and better printfs about what's going on with
UEFI memory.


killed. It was the detritus of too many code move / refactors.


What do you think of just reporting when we fail to get it? These printfs are left over from a by-gone series of "WTF is going on?" debugging...


Should we print the message on the fdt == -1 case when the open call fails?


Yes, I think so. If we can't open the FDT at all, we can't get the UEFI memory address, table length, entry size and version. There's no other interface on aarch64 for this data.

Fold D38311 into this... it belongs here really

This revision was not accepted when it landed; it landed in state Needs Review.Feb 3 2023, 3:52 PM
This revision was automatically updated to reflect the committed changes.