Page MenuHomeFreeBSD

kboot: aarch64 memory enumeration enumerate_memory_arch()
ClosedPublic

Authored by imp on Jan 29 2023, 3:14 PM.
Tags
None
Referenced Files
F84596413: D38249.id116250.diff
Sun, May 26, 12:19 AM
F84596411: D38249.id116007.diff
Sun, May 26, 12:19 AM
F84596408: D38249.id116293.diff
Sun, May 26, 12:19 AM
F84596404: D38249.id.diff
Sun, May 26, 12:19 AM
F84596402: D38249.id116405.diff
Sun, May 26, 12:19 AM
F84596200: D38249.id116340.diff
Sun, May 26, 12:14 AM
Unknown Object (File)
Fri, May 24, 4:05 AM
Unknown Object (File)
Sat, May 18, 5:59 PM
Subscribers

Details

Summary

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

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

Event Timeline

rebase / refactor / redo

stand/kboot/arch/aarch64/load_addr.c
32

fd2 seems to only exist to close it upon error

121

Doing try or Attempting, perhaps?

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

stand/kboot/arch/aarch64/load_addr.c
32

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

121

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...

stand/kboot/arch/aarch64/load_addr.c
127

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

stand/kboot/arch/aarch64/load_addr.c
127

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.