Hi,
On 03/04/18 12:34, Maxime Ripard wrote:
On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
For hacking it, see my implementation in v1, which assumes the only size supported bigger than 2GiB is 3GiB (which is acceptable on sunxi, but might not work on other platforms).
As Andre said, that function has another big problem -- it detects memory with writing to it. This is risky.
How is it risky when it's done by the SPL?
Originally that was my confusion as well: It's not the SPL calling that function. The DRAM controller init function in there knows very precisely how much DRAM we have, but we don't communicate this to U-Boot proper. So U-Boot *proper* goes ahead and probes the DRAM. This means it could step into secure memory, for instance. On sunxi64 we have the ATF running between SPL and U-Boot, also all kind of secure payloads could already have been registered. So I wonder if it would be easier to somehow pass on this *one* word of information between SPL and U-Boot proper to avoid calling this function altogether?
That would definitely make sense yes.
So since the SPL loads the DT anyway (from the FIT image) and puts it at the end of the U-Boot (proper) binary, wouldn't it be the easiest to just patch the actual DRAM size in there? IIRC we don't have any FDT write code in the SPL at the moment, and pulling it in would probably push it over the edge again, but:
That assumes that you are loading a FIT image, which might or might not be the case, and on most arm32 chips, most likely won't.
That's true, but my understanding is that this >4GB is only relevant for 64-bit SoCs, where we mandate FIT images, don't we?
I guess we'd need to find another way (put some information in an SRAM somewhere?) to try to do that for all variants.
Oh, so your aim at getting rid of the call to the memory probing function at all? I was just assuming that we change it for the purpose of this 3GB support, which would be 64-bit only?
Cheers, Andre