Hi,
On 17/05/18 09:35, Icenowy Zheng wrote:
于 2018年5月17日 GMT+08:00 下午4:16:58, Andre Przywara andre.przywara@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.
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(-)