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

[Patrick DELAUNAY]

Hi Wolfgang,

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> 
> Dear Patrick,
> 
> In message <10532397af3d416f9a1b30f0b09a94f1 at SFHDAG6NODE3.st.com>
> you wrote:
> >
> > > You should keep the functionality, but move it to where it belongs,
> > > i. e. to the SPL running from OCM.
> >
> > I remove it in U-Boot and I call it only in SPL, executed in onchip
> > RAM, juste after DDR controller initalisation
> >
> > So for my board, I have no more issue with the function.
> 
> Can you please do me the favour and verify that with this change no memmory
> corruption / modification happens?

OK I will check, I will indicated the test done in V2 comment.
And potentially I will check if I can implement a test in sandbox.

> 
> > For the last case (return (maxsize)),
> > when no overlap is detect, the content of base is not restored.
> > So for me, the function get_ram_size is not safe for the DDR content.
> 
> What exactly do you mean by "overlap" here?

Perhaps I don't use the correct term...
When the higher bit of address are not used physical for ram access 
(when size is lower than the max size)
access to  2 address access to the same physical
=> I use overlap to indicate this case

example for physical size limited to 128MB = bit 0 to 26 mapped to the memory, bit 27 used
access to 0x0000000 => physical access to 0x00000000
acesss to 0x7FFFFFFF => physical access to 0x7FFFFFFF
access to 0x8000000 => physical access to 0x00000000 overlap detected here by the code !


> > Do you think, that I need to continue with the patchset, (I need a v2
> > to remove the uncessary restore in the second loop after code
> > analysis) even it is no more usefull for me.
> >
> > Or do you prefer that I drop the patchset to avoid regression ?
> 
> I would really like to finally find an explanation why this code is (or has been)
> working well on so many boards, while on a few boards this problem gets
> reported - and the supposed fix (which looks reasonable when lookingon it)
> breaks other boards.
> 
> So I would really appreciate if you could continue to work on this.

Ok, I will do it but only in background...
I will propose a V2 and I will crosscheck with previously broken board if it is still the case.

> 
> Thanks!
> 
> Best regards,
> 
> Wolfgang Denk
> 

Best Regard,

Patrick Delaunay