On 11/18/23 18:58, Simon Glass wrote:
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?
Is there any ofnode API to retrieve reservations as easily as with
fdt_get_mem_rsv(), fdt_num_mem_rsv()?
boot/image-fdt.c, boot/fdt_region.c, boot/fdt_support.c, cmd/fdt.c all
use the libfdt API directly.
Best regards
Heinrich
