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 ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
