On 06.04.18 11:25, Mark Kettenis wrote:
>> From: Alexander Graf <ag...@suse.de>
>> Date: Fri,  6 Apr 2018 09:42:47 +0200
>> With legacy boot (booti, bootz), people can declare memory regions as
>> reserved using device tree memory reservations. This feature is some
>> times used to indicate memory regions that should not be touched.
>> Since in a UEFI world, the DT memory reservations do not get honored,
>> let's copy them into the UEFI memory map so everyone has a coherent
>> view of the world and we give people the chance to add reservations
>> on demand.
> This won't fix the issue raised here:
>   https://lists.denx.de/pipermail/u-boot/2018-March/324336.html

Oh, I must've missed that email.

> but would open up yet another way to solve that issue.

My main goal with this is to allow memory reservation overrides for
platforms where people don't want to or can not touch U-Boot source code.

Doing explicit reservations in board files is obviously the much better

> But with my analysis of that issue still in the back of my mind I have
> a question.  What happens with regions added by U-Boot itself through
> fdt_add_mem_rsv() calls?  Also note that the is code in
> arch/arm/mach-meson/board.c that explicitly calls efi_add_memory_map()
> to reserve memory it adds using fdt_add_mem_rsv().

There are way too many layers around for memory reservations :).

We have implicit memory reservations that get handled through
CONFIG_LMB. These are not mirrored into the EFI memory map FWIW.

Explicit calls to fdt_add_mem_rsv() with this patch also get mirrored
into the EFI memory map *if* a DT is used. That means in this case calls
to both end up redundant. I don't think that's an issue - especially
given that maybe not everyone wants to boot using DT.

U-Boot mailing list

Reply via email to