[U-Boot] [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot

[Maxime Ripard]

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 at 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
> ><maxime.ripard at bootlin.com> 写到:
> >> >On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote:
> >> >> 
> >> >> 
> >> >> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard
> >> ><maxime.ripard at bootlin.com> 写到:
> >> >> >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

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180329/9343859e/attachment.sig>