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

[Andre Przywara]

Hi Icenowy,

On 03/04/18 12:51, Icenowy Zheng wrote:
> 
> 
> 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard <maxime.ripard at bootlin.com> 写到:
>> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote:
>>>>>>> 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:
>>
>> That assumes that you are loading a FIT image, which might or might
>> not be the case, and on most arm32 chips, most likely won't.
>>
>> I guess we'd need to find another way (put some information in an
>> SRAM somewhere?) to try to do that for all variants.
> 
> Extend the SPL header again? If we found SPL v3+, use
> the DRAM size encoded and bypass ram_get_size,
> otherwise fallback to ram_get_size?

Yes, that would be a possibility as well. Though I believe at the moment
we don't access the SPL header from U-Boot proper, do we? Not a real
show-stopper, but we probably need to document that the SPL header would
need to stay around.
But if we have a fallback anyway ...

> (Although it will lead to some days of mess on sunxi-tools,
> this is a reasonable choice.)

True, but actually I wonder why we have SPL_MAX_VERSION in there in the
first place. Can't we just postulate that every new SPL version stays
backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would
still be fine, you would just loose the v3 features (if at all)? We can
just put a warning in there, to ask users to upgrade.
That would have worked already with the v1/v2 transition, I believe.

Probably worth a separate discussion with some sunxi-tools stakeholders.

Cheers,
Andre.