Hi,
On 29/03/18 10:37, Maxime Ripard wrote:
On Wed, Mar 28, 2018 at 07:31:51PM +0800, Icenowy Zheng wrote:
于 2018年3月28日 GMT+08:00 下午7:28:07, Maxime Ripard maxime.ripard@bootlin.com 写到:
On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote:
于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard
On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
> On Fri, Mar 23, 2018 at 04:18:56PM +0800, Icenowy Zheng wrote: >> The get_ram_size() function in U-Boot can only deal with memory
size
>> smaller than 2GiB. To enable the support of 3GiB DRAM on newer
64-bit
>> SoCs, an alternative way to detect DRAM size is needed. > > Why not just fixing get_ram_size then?
Even if it's fixed it won't support 3GiB DRAM at all.
Why?
It has an assumption that the size is pow of 2.
I guess this would be fixable too? (or one could create a variant without that assumption).
I don't think its principle allows such kind of fix, as it just checks writing then reading at some offset that is pow if 2.
You could do have a bunch of algorithm actually. One would be to write the address in memory and try to detect where exactly it starts to loop.
You could do a bisection in the opposite direction once you settled for the upper limit (so you would have for example a workable 2G, a non-workable 4G, and then you try intervals that you always divide by two, so testing then 3G (that works), then halfway between 3G and 4G, etc.
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?
Cheers, Andre.