On Mon, 14 Sep 2015 12:20:39 +0200 Bernhard Nortmann <[email protected]> wrote:
> Hi! > > Am 14.09.2015 um 00:05 schrieb Siarhei Siamashka: > > Version mismatch probably deserves a special error message. So that > > the user knows what exactly is outdated (U-Boot or sunxi-tools) and > > needs upgrading. > > > > And also about SPL header versioning in general. Most likely we are > > going to prefer backwards compatible changes (if any) in the future. > > So that the offset 0x14 will be still used for storing a pointer to > > boot.scr data even if we add more fields to the SPL header later. > > However we can't rule out compatibility breaking changes either. So > > it might be a good idea to have a 'major' version number and a 'minor' > > version number. In the case only a minor version number is increased, > > then we know that the changes are backwards compatible. But if a major > > version number is changed, then we can't assume anything and should > > treat it as an error. > > > > Am I trying to over-engineer it unnecessarily? > > Maybe. :D (also see below for my "size" field) > > For now I had introduced a very basic check. The test for equality > may be overly simple, and should probably be replaced by some "<=" > (for 'backwards' compatibility) once actual versioning actually starts > to matter. For the time being I anticipate(d) the "sunxi" SPL to > preserve fields once they are established (and not discard them later), > following your argument that it's simple enough to extend the header > (space) when necessary. > > I haven't really thought of / planned on more sophisticated checks > (SPL_MIN_VERSION, SPL_MAX_VERSION) or major/minor numbers. The latter > might be achieved by (ab)using nibbles of the version uint8_t, turning > our initial version to 0.1 (with room for up to 0.15) and making 0x10 > the next "major" version 1.0. > > But I think all of this could be dealt with later, when the need for a > SPL change arises that would actually introduce "incompatible" versions. No, we can't just do nothing now and fix the problem later in this particular case. Right now your patch is silently doing nothing if it does not recognize exactly the first version of the SPL header. Now imagine that we decide that it is good enough for now. Then some Linux distribution packages sunxi-tools in this state. Then at a later date, the SPL header in U-Boot may need to be extended (for example, add uEnv.txt support or introduce a flag to redirect serial console to the SD breakout board or anything else). Then we can have the users trying to follow some tutorial and expecting their boot.scr to be picked up by U-Boot. And if boot.scr is just silently ignored, then they can have a lot of fun troubleshooting or pestering people for support. If the boot.scr format is recognized by the 'fel' tool and the U-Boot image is recent enough to have the SPL header with the slot for boot.scr address reserved, then the users should get comprehensive error messages in the case of encountering an unexpected version of the SPL header. > > The necessity of this 'fel_data_size' field (and the naming of the SPL > > header fields) is still being discussed in U-Boot: > > > > http://lists.denx.de/pipermail/u-boot/2015-September/227650.html > > > > After the discussion in the U-Boot mailing list comes to a conclusion, > > we are going to know what to do. > > Yes. Hans seems to share your initial thought on this field (being not > really necessary), and argues against "covering exotic variants of what > is already a corner case". So I feel inclined to follow this train of > thought more strictly, and avoid the "overengineering" when there's no > need for it. This includes dropping the "size" field and simply revert > it to a "uint32_t reserved;" instead. OK. Let's follow what happens in the U-Boot mailing list. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
