Hi Heinrich, On Sat, 18 Nov 2023 at 10:34, Heinrich Schuchardt <heinrich.schucha...@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.schucha...@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 <s...@chromium.org> Perhaps someone could convert efi_carve_out_dt_rsv() to use the ofnode API? Regards, Simon
