[U-Boot] [PATCH] common/memsize.c: restore content of the base address

[Wolfgang Denk]

Dear Patrick,

In message <6daf1478e4284b8590c2862c6a504e9c at SFHDAG6NODE3.st.com> you wrote:
> 
> After investigation, I found an potential issue when the current code of get_ram_size() 
> is loaded near of power of 2 offset (just before an address modified by the code)... 
> In fact the content of the RAM is modified during the code execution just after the
> PC address, and the code is not yet in instruction cache, so this the code crash.
> I try to found a good solution (limit the min offset to be tested, 
> to avoid to modify the address used by U-Boot code)

You mean you are running this code from the very memory you are
sizing?  This is fundamentally broken.  You must not do this!

get_ram_size() is supposed to run from some _different_ memory (at
least a different memopry bank, usually better from a different
memory type).

> You can found analysis in :
>   [U-Boot] questions about get_ram_size usage in U-Boot = DDR modification during code execution
>   From Patrick DELAUNAY Mon Apr 24 16:11:41 UTC 2017
>   https://lists.denx.de/pipermail/u-boot/2017-April/288709.html

You write there:

| Today, I found a issue with  get_ram_size() usage in U-Boot, when
| U-Boot is executed in the tested memory.

You must not do this.  The memory under test is supposed to be
otherwise idle.

> and finally the function return max size

For the test to work correctly, max test size should be chosen at
least twice as big as the maximum possible memory configuration.

> Perhaps other board failed because size of function code increase (not fully inside instruction cache page) 

No.  We are talking of boards that were implemented properly, i. e.
the tested RAM was NOT the memory where get_ram_size() was running
from.

> or it  is the same issue indicated previously: the address of function change and so code change during execution.

Code location or size does not play a role here.  The code was
running from parallel NOR flash, and testing the actual RAM size, so
thsi is totally independent.

> If the same patch come again I think that this function have really a problem and we could
> solve the issue (with my patch for exmale) and then understood the regression on other the boards.

I agree there appears to be a problem,  but it should be
understood..

In your case you use the code in an illegal way, so I tend to
argument you are provoking undefined behaviour.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth