On Friday 06 January 2023 10:51:43 Tom Rini wrote:
> This reverts commit 777aaaa706bcfe08c284aed06886db7d482af3f8.
>
> The changes to this generic function, which is intended to help with
> 32bit platforms with large amounts of memory has unintended side effects
> (which in turn lead to boot failures) on other platforms which were
> previously functional.
As mentioned previously, unfortunately this revert breaks 32-bit u-boot
on 36-bit mpc85xx boards with 32-bit e500v2 cores and 4GB DDR module.
Which platforms currently have broken u-boot without this revert? The
only one which was reported is stm32mp but for it there different
workaround patch waiting in the queue.
> Reported-by: Marek Vasut <ma...@denx.de>
> Cc: Patrick Delaunay <patrick.delau...@foss.st.com>
> Cc: Pali Rohár <p...@kernel.org>
> Signed-off-by: Tom Rini <tr...@konsulko.com>
> ---
> common/memsize.c | 18 +++---------------
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/common/memsize.c b/common/memsize.c
> index 3c80ad2c8346..31884acca0df 100644
> --- a/common/memsize.c
> +++ b/common/memsize.c
> @@ -94,23 +94,11 @@ long get_ram_size(long *base, long maxsize)
>
> phys_size_t __weak get_effective_memsize(void)
> {
> - phys_size_t ram_size = gd->ram_size;
> -
> - /*
> - * Check for overflow and limit ram size to some representable value.
> - * It is required that ram_base + ram_size must be representable by
> - * phys_size_t type and must be aligned by direct access, therefore
> - * calculate it from last 4kB sector which should work as alignment
> - * on any platform.
> - */
> - if (gd->ram_base + ram_size < gd->ram_base)
> - ram_size = ((phys_size_t)~0xfffULL) - gd->ram_base;
> -
> #ifndef CONFIG_MAX_MEM_MAPPED
> - return ram_size;
> + return gd->ram_size;
> #else
> /* limit stack to what we can reasonable map */
> - return ((ram_size > CONFIG_MAX_MEM_MAPPED) ?
> - CONFIG_MAX_MEM_MAPPED : ram_size);
> + return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
> + CONFIG_MAX_MEM_MAPPED : gd->ram_size);
> #endif
> }
> --
> 2.25.1
>
