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