On 03/09/2018 01:48 PM, Alexander Graf wrote:
On 03/03/2018 03:48 PM, Heinrich Schuchardt wrote:
When running on the sandbox the stack is not necessarily at a higher memory address than the highest free memory.
There is no reason why the checking of the highest memory address should be more restrictive for EFI_ALLOCATE_ANY_PAGES than for EFI_ALLOCATE_MAX_ADDRESS.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
lib/efi_loader/efi_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c index cc271e0709d..0efbb973231 100644 --- a/lib/efi_loader/efi_memory.c +++ b/lib/efi_loader/efi_memory.c @@ -294,7 +294,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type, switch (type) { case EFI_ALLOCATE_ANY_PAGES: /* Any page */ - addr = efi_find_free_memory(len, gd->start_addr_sp); + addr = efi_find_free_memory(len, (uint64_t)-1);
This will break on systems that do not map high address space into the linear map (IIRC nvidia systems had that issue).
The memory map is also passed on to the operating system when booting. If a memory reservation is missing for any board it has to be fixed in the board or driver files, cf.
sunxi: video: mark framebuffer as EFI reserved memory https://lists.denx.de/pipermail/u-boot/2018-March/321820.htm
For type = EFI_ALLOCATE_MAX_ADDRESS we don't care about gd->start_addr_sp. So if the memory map is incomplete the current code may fail. Keeping things as they are is not a viable option.
Could you, please, identify for which Nvidia system a problem was reported? Then we can add a call to efi_add_memory_map() for the board.
Best regards
Heinrich