Hi all,
as Stefano Babic was so friendly and pointed out a few things already, we come the following problematic points:
For SWupdate to access U-Boot's environment, it uses code from U-Boot. Before 2015, fw_env.c was copied - hence out of version control, afterwards and since then, a lib.a produced by U-Boot has been used and renamed to libubootenv.a to link against.
However, this approach creates several difficulties:
* 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. 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).
* 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.
* 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.
First proposal by Stefano and me would be to somehow split the default environment from the library to have a board-independent component and board specific data that is passed to U-Boot and SWUpdate somehow.
Goal is to factor out U-Boot environment support for other software like SWUpdate and not patching and hacking like its the case with recipes as in openembedded atm.
Thanks, Andreas