[PATCH] efi_loader: fix memory type for memory reservation block
The devicetree specification clearly states that:
As with the /reserved-memory node, when booting via UEFI entries in the Memory Reservation Block must also be listed in the system memory map obtained via the GetMemoryMap() toi protect against allocations by UEFI applications. The memory reservation block entries should be listed with type EfiReservedMemoryType.
This restores the behaviour that was changed by commit 4cbb2930bd8c ("efi_loader: consider no-map property of reserved memory").
Signed-off-by: Mark Kettenis kettenis@openbsd.org --- lib/efi_loader/efi_dt_fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c index a4529ee3ef..b6fe5d2e5a 100644 --- a/lib/efi_loader/efi_dt_fixup.c +++ b/lib/efi_loader/efi_dt_fixup.c @@ -61,7 +61,7 @@ void efi_carve_out_dt_rsv(void *fdt) for (i = 0; i < nr_rsv; i++) { if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0) continue; - efi_reserve_memory(addr, size, false); + efi_reserve_memory(addr, size, true); }
/* process reserved-memory */
On Sun, Mar 14, 2021 at 7:04 PM Mark Kettenis kettenis@openbsd.org wrote:
The devicetree specification clearly states that:
As with the /reserved-memory node, when booting via UEFI entries in the Memory Reservation Block must also be listed in the system memory map obtained via the GetMemoryMap() toi protect against allocations by UEFI applications. The memory reservation block entries should be listed with type EfiReservedMemoryType.
This restores the behaviour that was changed by commit 4cbb2930bd8c ("efi_loader: consider no-map property of reserved memory").
Signed-off-by: Mark Kettenis kettenis@openbsd.org
Tested-by: Peter Robinson pbrobinson@gmail.com
This fixes the issue that I reported last week with the Raspberry Pi 3. https://lists.denx.de/pipermail/u-boot/2021-March/444139.html
lib/efi_loader/efi_dt_fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c index a4529ee3ef..b6fe5d2e5a 100644 --- a/lib/efi_loader/efi_dt_fixup.c +++ b/lib/efi_loader/efi_dt_fixup.c @@ -61,7 +61,7 @@ void efi_carve_out_dt_rsv(void *fdt) for (i = 0; i < nr_rsv; i++) { if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0) continue;
efi_reserve_memory(addr, size, false);
efi_reserve_memory(addr, size, true); } /* process reserved-memory */-- 2.30.2
On 14.03.21 20:04, Mark Kettenis wrote:
The devicetree specification clearly states that:
As with the /reserved-memory node, when booting via UEFI entries in the Memory Reservation Block must also be listed in the system memory map obtained via the GetMemoryMap() toi protect against allocations by UEFI applications. The memory reservation block entries should be listed with type EfiReservedMemoryType.
Thank you for your patch.
Please, mention in your commit message that you are not citing from the released specification but from a work in progress version.
The text was introduced with commit f998b10c3e78 ("Add details of UEFI interaction with /memory and /reserved-memory").
Please, add a Fixes line.
Otherwise
Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de
This restores the behaviour that was changed by commit 4cbb2930bd8c ("efi_loader: consider no-map property of reserved memory").
Signed-off-by: Mark Kettenis kettenis@openbsd.org
lib/efi_loader/efi_dt_fixup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c index a4529ee3ef..b6fe5d2e5a 100644 --- a/lib/efi_loader/efi_dt_fixup.c +++ b/lib/efi_loader/efi_dt_fixup.c @@ -61,7 +61,7 @@ void efi_carve_out_dt_rsv(void *fdt) for (i = 0; i < nr_rsv; i++) { if (fdt_get_mem_rsv(fdt, i, &addr, &size) != 0) continue;
efi_reserve_memory(addr, size, false);
efi_reserve_memory(addr, size, true);}
/* process reserved-memory */
participants (3)
-
Heinrich Schuchardt -
Mark Kettenis -
Peter Robinson