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 alternative. > 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. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
