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 -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
