On 21.11.18 10:19, Stefano Babic wrote:
Hi Simon,
On 20/11/18 22:11, Simon Goldschmidt wrote:
On 04.09.2018 12:30, Andreas Reichel wrote:
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.
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 did some tests, but I have found the way quite fragile. We should need
at least markers to identify begin and end of the environment because
size differs for each board.
I do think the current situation should be improved, making
fw_setenv independent of the target that is built.
A simple way is to let fw_setenv to get the default env via a parameter
(file), but this is also error prone if u-boot is updated and the file
with default env not.
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...
I do not prefer this - SWUpdate should be as much as possible self
contained (also for security reasons). Linking libubootenv.a is like
linking any other library. The weirdness is just with the default
environment, that should be addressed.
I'm not sure if this is still on the radar as requirement, but it would be great
if we could kick all the board dependencies out of that library, make them
config files. That would make the lib compatible with common binary distros like
Debian.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
