On 03/09/2018 04:58 PM, Heinrich Schuchardt wrote:
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.
Git blame points to this commit. I guess -1 should do the same thing
then, true.
Andreas, would you see any reason -1 will not work?
Alex
commit dede284d1ce9f9d9e79a5114fe7eb814fec07679
Author: Andreas Färber <afaer...@suse.de>
Date: Wed Apr 13 14:04:38 2016 +0200
efi_loader: Handle memory overflows
jetson-tk1 has 2 GB of RAM at 0x80000000, causing gd->ram_top to be
zero.
Handle this by either avoiding ram_top or by using the same type as
ram_top to reverse the overflow effect.
Cc: Alexander Graf <ag...@suse.de>
Signed-off-by: Andreas Färber <afaer...@suse.de>
Reviewed-by: Alexander Graf <ag...@suse.de>
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index df995858ed..71a3d19269 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -220,7 +220,7 @@ efi_status_t efi_allocate_pages(int type, int
memory_type,
switch (type) {
case 0:
/* Any page */
- addr = efi_find_free_memory(len, gd->ram_top);
+ addr = efi_find_free_memory(len, gd->start_addr_sp);
if (!addr) {
r = EFI_NOT_FOUND;
break;
@@ -320,9 +320,9 @@ efi_status_t efi_get_memory_map(unsigned long
*memory_map_size,
int efi_memory_init(void)
{
- uint64_t runtime_start, runtime_end, runtime_pages;
- uint64_t uboot_start, uboot_pages;
- uint64_t uboot_stack_size = 16 * 1024 * 1024;
+ unsigned long runtime_start, runtime_end, runtime_pages;
+ unsigned long uboot_start, uboot_pages;
+ unsigned long uboot_stack_size = 16 * 1024 * 1024;
int i;
/* Add RAM */
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
