Hi Wolfgang,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de]
Dear Patrick,
In message 10532397af3d416f9a1b30f0b09a94f1@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