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.
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.
Regards, B. Nortmann
--
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
