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

[Dr. Philipp Tomsich]

> On 3 Apr 2018, at 12:39, Icenowy Zheng <icenowy at aosc.io> wrote:
> 
> 
> 
> 于 2018年4月3日 GMT+08:00 下午6:13:17, Andre Przywara <andre.przywara at arm.com <mailto:andre.przywara at 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.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?
>>>> 
>>>> 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.