On 11/18/23 18:10, Simon Glass wrote:
Hi Heinrich,
On Thu, 16 Nov 2023 at 02:29, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
ACPI tables cannot convey memory reservations for least ARM and RISC-V. x86 uses the BIOS E820 table for this purpose. We cannot simply ignore the device-tree when booting via ACPI.
Why is that? I had thought that we had to use one or the other. Isn't the devicetree irrelevant when booting with ACPI, so we can just drop it?
Linux Documentation/arch/arm64/acpi_object_usage.rst, line 718f describes the mechanism to convey memory information as follows:
"For arm64, we will only support UEFI for booting with ACPI, hence the UEFI GetMemoryMap() boot service is the only mechanism that will be used."
With the patch we tell the UEFI sub-system which memory areas are reserved (e.g. for TF-A on ARM or for OpenSBI on RISC-V). This information is inferred from the device-tree. The operating system will collect this information by calling GetMemoryMap() immediately before ExitBootServices().
Without the patch Linux on RISC-V using ACPI crashed when illegally accessing the memory reserved for OpenSBI.
Best regards
Heinrich
We have to assign EfiReservedMemory according to the prior stage device-tree ($fdtaddr) or as fallback the control device-tree ($fdtcontroladdr).
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
cmd/bootefi.c | 25 ++++++++++--------------- lib/efi_loader/Makefile | 2 -- 2 files changed, 10 insertions(+), 17 deletions(-)
The code looks fine, but I would like to better understand why this is needed.
Regards, Simon