[U-Boot] SWUpdate - U-Boot environment library dependency

[Wolfgang Denk]

Dear Simon,

In message <90014ca9-64d8-8e38-a6c0-4c06e991c92c at gmail.com> you wrote:
>
> > However, this approach creates several difficulties:

As usual, "difficulties" are made for solving.

I mean, none of these are technically challenging in any way.

> > * Distros like Debian cannot provide a devel package for SWUpdate like
> >    u-boot-dev, since U-Boot has its default environment code compiled
> >    board-dependently and Debian needed it board-independent.

Thta's fine.

> >    If a board-independent libubootenv.a was provided without
> >    a specific default environment, the first update process would destroy
> >    the U-Boot environment if it had had bad CRC before.
> >    (Thanks Stefano for this good point).

One possible way to fix this is not to use a compiled in default
environment for the fw_env tools (or only use this as a very last
resort), but instead provide a configuration option to read the
default settings from a file.  In this case the user could provide
his own, board specific default environment.

> > * If we have a board with U-Boot already preinstalled and want to
> >    compile SWUpdate for it, we need the sources of this very U-Boot to
> >    get the propper lib. For example in a debian-like build system we had to
> >    compile U-Boot again, although it is already installed since we lack
> >    a dev package.

- Why does building the U-Boot package not also create these
  libraries, either directly or as a separate package?
- What prevents the creation of such a dev package that only builds
  the needed lib?

> > * U-Boot does not provide any default means to install a development
> >    library. Thus anything we modify on-top might break with the next
> >    version.

Why don't you add this, then?  Patches are welcome!

> Has there been any progress in the SWupdate/fw_setenv integration? I 
> thought I remember reading something about letting fw_setenv extract the 
> environment from the U-Boot binary in the target, but I cannot find the 
> thread. I do think the current situation should be improved, making 
> fw_setenv independent of the target that is built.

To be honest, I think this is not a clever approach.  This whole
concept of the compiled in default environment is antediluvian.  It
comes from a time where we were booting from parallel NOR flasah (or
other boot ROM where you directly started executing code) and where
we wanted to make sure that we can read the console baud rate very,
very soon.  Today, many boards don't have environment access in the
SPL, and nobody complains that these run with a fixed baud rate
only.

Did anybody ever ask who actually _needs_ this compiled in default
environment?  We could provide other, more efficient configurations
if we drop a few of the old requirements (which are not met by many
recent boards anyway).

> And as this thread is on the swupdate group as well: I would prefer 
> calling an external fw_setenv tool instead of linking in the static 
> library libubootenv.a...

IMO this is just a matter of taste.  Both ways should be possible.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who isn't confused here doesn't really know what's going on.