Broken support for 4GB DDR on 32-bit platforms
Pali Rohár
pali at kernel.org
Sat May 14 01:00:06 CEST 2022
Hello! I tried to enable support for 2GB+ of DDR memory (with 4GB DDR3)
on powerpc P2020 board in 32-bit addressing mode and U-Boot crashed
during startup.
I figured out that issue is not powerpc specific, but rather generic to
all 32-bit platforms. U-Boot stores memory size into phys_size_t type
(gd->ram_size) and last mapped memory address increased by one byte into
phys_addr_t type (gd->ram_top).
Despite size 4GB fits into 32-bit addressing mode, it does not fit into
above two variables, and it overflows to zero. U-Boot then see zero RAM
size and crashes.
I tried to workaround this issue by changing both phys_size_t and
phys_addr_t types to 64-bit. But it did not helped because U-Boot on
many places cast gd->ram_size or gd->ram_top to ulong type, which is
32-bit on 32-bit platforms.
Next I changed ulong parameters of board_get_usable_ram_top() function
to u64.
This still was not enough because config value CONFIG_MAX_MEM_MAPPED is
ignored on one important place -- in function get_effective_memsize().
This config value takes effect only when also CONFIG_VERY_BIG_RAM is
set.
Finally With this change I was able to start U-Boot with more than 2GB
of DDR memory inserted in SODIMM slot on P2020.
How to fix issues with gd->ram_size and gd->ram_top? That +1 byte is
really stupid limitation. Changing phys_size_t and phys_addr_t types
unconditionally to 64-bit? Or something else?
And what is the purpose of CONFIG_VERY_BIG_RAM config option? Why is
CONFIG_MAX_MEM_MAPPED check skipped in get_effective_memsize() function,
but is not skipped on many more places?
More information about the U-Boot
mailing list