Hi Heinrich,
On Sat, 18 Nov 2023 at 16:06, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 11/18/23 18:58, Simon Glass wrote:
Hi Heinrich,
On Sat, 18 Nov 2023 at 10:34, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
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.
OK thank you, I misunderstood it.
Reviewed-by: Simon Glass sjg@chromium.org
Perhaps someone could convert efi_carve_out_dt_rsv() to use the ofnode API?
Is there any ofnode API to retrieve reservations as easily as with fdt_get_mem_rsv(), fdt_num_mem_rsv()?
Not yet :-)
boot/image-fdt.c, boot/fdt_region.c, boot/fdt_support.c, cmd/fdt.c all use the libfdt API directly.
Yes, but it is starting to change. Ultimately we will likely use livetree for fixups due to efficiency.
Regards, Simon