board_get_usable_ram_top() conflated the RAM size with the top address
of RAM. On systems where RAM starts at address 0 these numbers are the
same so it went unnoticed. Update board_get_usable_ram_top() to take
CONFIG_SYS_SDRAM_BASE into account when determining the top address.
Signed-off-by: Chris Packham <judge.pack...@gmail.com>
---
I've got a 64-bit mvebu SoC/board that I plan on submitting in a few
weeks. One of the gotchas with this board is that the physical address
of the RAM starts at 0x2_00000000 (there's some seemingly unmovable I/O
occupying the lower addresses).
This was one of the earlier issues I hit with porting. I figured it was
independent enough that I could send it out while I'm still working on
the rest of the series.
arch/arm/mach-mvebu/arm64-common.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-mvebu/arm64-common.c
b/arch/arm/mach-mvebu/arm64-common.c
index 5357aa554db4..238edbe6ba56 100644
--- a/arch/arm/mach-mvebu/arm64-common.c
+++ b/arch/arm/mach-mvebu/arm64-common.c
@@ -28,14 +28,13 @@ DECLARE_GLOBAL_DATA_PTR;
* Currently only 2GiB are mapped for system memory. This is what
* we pass to the U-Boot subsystem here.
*/
-#define USABLE_RAM_SIZE 0x80000000
+#define USABLE_RAM_SIZE 0x80000000ULL
ulong board_get_usable_ram_top(ulong total_size)
{
- if (gd->ram_size > USABLE_RAM_SIZE)
- return USABLE_RAM_SIZE;
+ unsigned long top = CONFIG_SYS_SDRAM_BASE + min(gd->ram_size,
USABLE_RAM_SIZE);
- return gd->ram_size;
+ return (gd->ram_top > top) ? top : gd->ram_top;
}
/*
--
2.36.1
