> On 3 Apr 2018, at 12:39, Icenowy Zheng <icen...@aosc.io> wrote: > > > > 于 2018年4月3日 GMT+08:00 下午6:13:17, Andre Przywara <andre.przyw...@arm.com > <mailto:andre.przyw...@arm.com>> 写到: >> Hi, >> >> On 03/04/18 10:29, Maxime Ripard wrote: >>> 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 >> <maxime.rip...@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.rip...@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.rip...@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? >>>> >>>> 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: >> We should be able to somewhat short-cut it, if it's just about to >> actually *patch* an existing value, as of: >> - make sure we have a memory node and a reg property in the DT >> - in the SPL learn the fdt offset of that reg property >> - <hack> patch in the memory size into the second word </hack> >> - teach U-Boot proper to read the memory size from the DT >> - optionally look at #address-cells and #size-cells to make this >> "second >> word hack" more robust >> >> This could actually be a rather generic patch, just with some "avoid >> libfdt write library" hack to address our size issue. Maybe we already >> have something like that for some platform (Rockchip comes to mind?) > > Rockchip recalculates the memory size with the parameters > in GRF when running the main U-Boot, so both TPL/SPL > and miniloader can load mainline U-Boot.
More accurately, the GRF currently is used to store an encoded DRAM configuration and the next stage can rely on this being there. If the memory is initialised by miniloader, U-Boot reads the GRF and calculates the memory size from that. If U-Boot sets up DRAM, then it also populates the GRF registers. With more and more SOCs moving away from miniloader, there’s a good chance that this will change at some point in the future and the GRF may not necessarily be populated anymore. —Philipp. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
