Hi Marek,
On 21/11/18 00:10, Marek Vasut wrote:
On 11/20/2018 10:11 PM, 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 do think the current situation should be improved, making fw_setenv independent of the target that is built.
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...
Wouldn't it make sense to have U-Boot build the env code as LGPL library, in addition to executable ?
+1
The library is already built (tools/env/lib.a), but IMHO the best thing is to export it official and let that in OE we have a u-boot-fw-tools-dev with header and library.
I would like to see the library under LGPL instead of GPL2, too, and I raised this issue when I started SWUpdate, but I was not very active to promote this. Tom, Wolfgang, is there chances to switch license ?
A env library is very welcomed by many customers, because they could integrate it in their application if license allows it.
Best regards, Stefano Babic