Closed Icenowy closed 5 years ago
While I totally support this PR, I wonder if anyone sees any issues with the current code? The U-Boot build process keeps the version number at 2, it's only the SPL that increases it to 3 dynamically at runtime, in SRAM only. sunxi-fel shouldn't see it there, it just cares about the field in the SPL file header. Of course we should merge it anyways, to prepare for the next version bump, which might be in the file header then.
I had to use this development version, because it was not supporting the newer u-boot version...
@apritzel sunxi-fel will read back from SRAM to check the header version, regardless of the header version of the SPL image on the disk (and passed onto the device). So if SPL changes it to 3 in SRAM, sunxi-fel will read back 3.
This is to support the situation that write command is not executed at the same time with spl command.
By the way, FEL booting of mainline U-Boot have been broken for at least 2 released versions.
I'm going to merge this pull request.
thanks for merging!
Every addition of a new feature to the SPL header currently requires us to update the FEL tool, to teach it about the new supported maximum value. Many times the FEL tool doesn't really care, but complains anyway - and refuses to load. Let's introduce semantic versioning [1] for this field, where backwards compatible additions just increase a minor number, but incompatible changes require bumping the major version. We have 8 bits for the SPL header version, let's split this to have 3 bits for the major and 5 bit for the minor version number.
[1] https://semver.org
Signed-off-by: Andre Przywara osp@andrep.de Signed-off-by: Icenowy Zheng icenowy@aosc.io
=========================
As the semantic versioning of SPL header is already accepted by mainline U-Boot 2018.11, and the header version is raised to v0.3, it's now needed to merge this patch into sunxi-tools, otherwise sunxi-tools will fail to FEL boot U-Boot 2018.11.
Thanks Icenowy