When constraining the highest DDR address that U-Boot will use for its
data & relocated self, we need to handle the common case in which a 32
bit system with 2GB DDR will have a zero gd->ram_top, due to the
addition of 2GB (0x80000000) to the base address of kseg0 (also
0x80000000) which overflows & wraps to 0.
We originally had a check for this case, but it was lost in commit
78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE") causing
problems for the affected 32 bit systems.
Signed-off-by: Paul Burton <paul.bur...@mips.com>
Fixes: 78edb25729ce ("boston: Provide physical CONFIG_SYS_SDRAM_BASE")
Cc: Daniel Schwierzeck <daniel.schwierz...@gmail.com>
---
Feel free to fold this into 78edb25729ce ("boston: Provide physical
CONFIG_SYS_SDRAM_BASE") if you prefer Daniel.
board/imgtec/boston/ddr.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/board/imgtec/boston/ddr.c b/board/imgtec/boston/ddr.c
index 00428496bd..892bb1754c 100644
--- a/board/imgtec/boston/ddr.c
+++ b/board/imgtec/boston/ddr.c
@@ -26,6 +26,15 @@ int dram_init(void)
ulong board_get_usable_ram_top(ulong total_size)
{
DECLARE_GLOBAL_DATA_PTR;
+ ulong max_top;
- return min_t(ulong, gd->ram_top, (ulong)phys_to_virt(SZ_256M));
+ /* Limit memory use to the top of (c)kseg0 */
+ max_top = (ulong)phys_to_virt(SZ_256M);
+
+ if (gd->ram_top < (ulong)phys_to_virt(0)) {
+ /* >= 2GB RAM on a 32 bit system wrapped around to 0 */
+ return max_top;
+ }
+
+ return min_t(ulong, gd->ram_top, max_top);
}
--
2.15.1
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
