于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard maxime.ripard@bootlin.com 写到:
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.
I guess we'd need to find another way (put some information in an SRAM somewhere?) to try to do that for all variants.
Extend the SPL header again? If we found SPL v3+, use the DRAM size encoded and bypass ram_get_size, otherwise fallback to ram_get_size?
(Although it will lead to some days of mess on sunxi-tools, this is a reasonable choice.)
Maxime