[U-Boot] [RFC PATCH 2/2] sunxi: add "fel" boot target

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

On Mon, 14 Sep 2015 13:46:57 +0200
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 14-09-15 13:42, Hans de Goede wrote:
> 
> >> Supporting both boot.scr and uEnv.txt for FEL boot seems to be
> >> reasonably simple to me. You can even do it in a single patch
> >> series. As Hans suggests, please take care of the boot.scr case
> >> first. Then maybe introduce uEnv.txt support with an additional
> >> patch.
> >
> > I'm still not convinced that support uEnv.txt is necessary at all,
> > but I agree that if we this having this done through extra fields,
> > rather then through a union would be better.
> 
> p.s.
> 
> As for the version byte vs minor/major scheme discussion. Why not
> simply declare that we will always be backwards compatible, and
> only ever add new fields ? Then we can simply add version checks
> around those new fields, and have both back and forward compatibility.
> 
> In this case the single byte should suffice nicely.

Regarding "Why not simply declare that we will always be backwards
compatible". Certain things are not always in our perfect control.
It's better not to make unnecessary promises, otherwise they can
become a liability :-)

For example, let's suppose that we have added data fields for
both "uEnv.txt" and "boot.scr" in the SPL header. Then suppose
that later U-Boot maintainers decide to deprecate and drop support
of one of these methods in favour of the other.

This situation can be handled by doing the major version increase
and removing the obsolete field from the SPL header. The "fel" tool
would notice that the U-Boot binary is incompatible and complain,
providing the user with all the necessary hints.

But if we don't have the concept of major/minor versions, then the
"fel" tool would be just assuming full backwards compatibility and
happily trying to pass the obsolete data to U-Boot.

Yes, we can also always change the SPL header signature in the case
of introducing incompatible changes. But the down side is that the
"fel" tool would treat this situation as "unknown bootloader"
instead of "incompatible U-Boot".

Anyway, nothing really needs to be changed on the U-Boot side at
this moment and the Bernhard's patches don't need any modifications.
It's up to the "fel" tool how to interpret the version byte. For
example, we can arbitrarily decide that the top 4 bits are used for
the major version part and low 4 bits are used for the minor version
part. If only the minor version number is changed, then assume
backwards compatibility. If the major version number has changed,
then complain to the user.

-- 
Best regards,
Siarhei Siamashka