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?
Maxime