[U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Stefano Babic]

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: sbabic at denx.de
=====================================================================