[U-Boot] [RFC PATCH 0/3] sunxi: extend SPL header to propagate DRAM size

[Andre Przywara]

Hi,

On 17/05/18 09:35, Icenowy Zheng wrote:
> 
> 
> 于 2018年5月17日 GMT+08:00 下午4:16:58, Andre Przywara <andre.przywara at arm.com> 写到:
>> This series tries to solve three issues we currently have on
>> Allwinner boards:
>> - The DRAM sizing routine can only cope with power-of-two sized DRAM.
>> - The DRAM sizing routine steps through all DRAM, possibly hitting
>> secure
>>  memory.
>> - The SPL header versioning is quite strict and tends to break every
>> time
>>  we need to update it.
>>
>> So I thought about introducing something along the lines of semantic
>> versioning[1], where we can add backwards-compatible changes to the SPL
>> header without breaking every tool. This is introduced in the first
> 
> How to define the "backwards-compatible"?

Yeah, that's a good question I was hoping to get some input on.
Ideally backwards-compatible means that older tools can cope with the
new feature, so for instance anyone not knowing about the DRAM size
introduced in v3 would still be happy (either ignoring it or not using it).

Now what's special about our situation is that we have several agents
dealing with the SPL header:
- The BootROM puts the boot source in there. That's probably a
no-brainer for now, but later BootROMs might behave differently. We
might need to update the major version when they do so without changing
the magic number.
- mksunxiboot creates the header and puts the version number in there.
It populates the DT name field since v2. I kept it at v2 for now, since
it's only the SPL populating the v3 DRAM size field.
- sunxi-fel reads the header and adds the FEL script address in there,
requiring at least v1. In the moment it insists on the version number
being at most 2, which my sunxi-tools patch tries to fix.
- Now the SPL and U-Boot use a field themselves (DRAM size), and I
bumped the version if needed.

> Should it have a standard? (e.g. tools have no change needed
> and U-Boot will have fallback code)

Yeah, that sounds like some sensible definition.

The only problem I see is what happens when we need a v4 feature for
mksunxiboot. This would lead U-Boot proper to believe the DRAM size
field is valid, even though the SPL might not have populated it. Not
sure we care about it, or if there is a better solution (feature bits?).

Cheers,
Andre.

>> patch.
>> The second patch does some refactoring, so that the third patch can use
>> the newly gained freedom to store the DRAM size. The SPL knows the DRAM
>> size very well, so we store this in the SPL header, so that U-Boot
>> proper
>> can pick it up from there. This saves the call to get_ram_size() with
>> its deficiencies.
>> More information in the respective commit messages.
>>
>> I understand that this versioning solution is not fully future-proof,
>> but
>> we have only one byte for the version, and I just wanted to start
>> discussion on this.
>> There is a corresponding patch for sunxi-tools as well I am posting
>> shortly.
>>
>> [1] https://semver.org
>>
>> Cheers,
>> Andre.
>>
>> Andre Przywara (3):
>>  sunxi: Extend SPL header versioning
>>  sunxi: board.c: refactor SPL header checks
>>  sunxi: store DRAM size in SPL header
>>
>> arch/arm/include/asm/arch-sunxi/spl.h | 22 ++++++++----
>> board/sunxi/board.c                   | 66
>> ++++++++++++++++++++++++++++-------
>> 2 files changed, 70 insertions(+), 18 deletions(-)