On Thu, Mar 29, 2018 at 01:21:38PM +0100, Andre Przywara wrote: > 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 > >> <[email protected]> 写到: > >>> On Mon, Mar 26, 2018 at 03:11:04PM +0800, Icenowy Zheng wrote: > >>>> > >>>> > >>>> 于 2018年3月26日 GMT+08:00 下午3:06:33, Maxime Ripard > >>> <[email protected]> 写到: > >>>>> On Fri, Mar 23, 2018 at 05:41:43PM +0800, Icenowy Zheng wrote: > >>>>>> > >>>>>> > >>>>>> 于 2018年3月23日 GMT+08:00 下午5:40:41, Maxime Ripard > >>>>> <[email protected]> 写到: > >>>>>>> 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?
That would definitely make sense yes. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
