[PATCH] Revert "common/memsize.c: Fix get_effective_memsize() to check for overflow"

[Pali Rohár]

On Friday 06 January 2023 12:25:24 Tom Rini wrote:
> On Fri, Jan 06, 2023 at 05:45:43PM +0100, Pali Rohár wrote:
> > 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.
> 
> Are you able to test on one of these PowerPC platforms currently?  As
> the stm32 problem shows, not everything is getting tested frequently
> enough, so how many other cases are lurking out there.  And, I think
> overall issue is that the overflow check-and-change you introduce here
> should just be in the CONFIG_MAX_MEM_MAPPED==true case.  As that's the
> case you're dealing with, yes?

I was planning to do big retest again after all powerpc patches are
reviewed and merged...

Anyway, if the issue here is with ram_size and its reduction was needed
for mpc85xx (at the time of introduction of that patch), what about
putting mpc85xx ifdef around ram_size reduction? For arm boards it would
have same behavior as revert of that commit and for mpc85xx it would be
no change.

I agree that this code needs to be revisited, together with ram_top
issue and also code which fills DDR banks. Because really mapped memory
for u-boot and real size of DDR are two different things here.