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

[Stefano Babic]

Hi Wolfgang,

On 21/11/18 09:31, Wolfgang Denk wrote:
> Dear Simon,
> 
> In message <90014ca9-64d8-8e38-a6c0-4c06e991c92c at gmail.com> you wrote:
>>
>>> However, this approach creates several difficulties:
> 
> As usual, "difficulties" are made for solving.
> 
> I mean, none of these are technically challenging in any way.
> 
>>> * 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.
> 
> Thta's fine.
> 
>>>    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).
> 
> One possible way to fix this is not to use a compiled in default
> environment for the fw_env tools (or only use this as a very last
> resort), but instead provide a configuration option to read the
> default settings from a file.  In this case the user could provide
> his own, board specific default environment.

I tried this, but it is very difficult to maintain this in sync,
specially in projects where the number of developers is > 1 (all
projects). If the file does not correspond to the linked environment,
strange behaviors are expected.

Much better will be if u-boot generates in its build process this file.
It becomes just another artifact like SPL or u-boot.img and we are sure
that it is in sync.

> 
>>> * 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.
> 
> - Why does building the U-Boot package not also create these
>   libraries, either directly or as a separate package?

Issue is that there is not a u-boot-dev package

> - What prevents the creation of such a dev package that only builds
>   the needed lib?

I think Simon wants to prevent to rebuild u-boot.

> 
>>> * 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.
> 
> Why don't you add this, then?  Patches are welcome!

+1

> 
>> 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.
> 
> To be honest, I think this is not a clever approach.  This whole
> concept of the compiled in default environment is antediluvian.

Fully agree - I am glad if there will be an improvement.

To be clear: the issue just raises if a board runs with default
environment. User Space cannot know this environment because it is
linked in the bootloader - the current way is to link the same
environment in tools/env (that means, u-boot-fw-tools in OE).

There is no issue at all for boards that are not using default
environment at all, that means they rely to have always a valid
environment in flash.

>  It
> comes from a time where we were booting from parallel NOR flasah (or
> other boot ROM where you directly started executing code) and where
> we wanted to make sure that we can read the console baud rate very,
> very soon.  Today, many boards don't have environment access in the
> SPL, and nobody complains that these run with a fixed baud rate
> only.
> 
> Did anybody ever ask who actually _needs_ this compiled in default
> environment? 

Rather, quite all boards....see CONFIG_EXTRA_ENV in include/configs/*
and the number of patches sent just to fix something in it.

UMHO the default environment should be like an extra image in u-boot,
like an header added by mkimage, because there is no changes in code and
behavior. Not to mention that CONFIG_EXTRA_ENV is really error prone
with the requirement to put each line as a C string with trailing "\0".

> We could provide other, more efficient configurations
> if we drop a few of the old requirements (which are not met by many
> recent boards anyway).

All recent boards, specially the one that switched to distro_, use the
default environment. Thing is that there is no need to add an extra
environment and the board can boot without any intervention by operator
(or by factory) simply after flashing the bootloader.

> 
>> 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...
> 
> IMO this is just a matter of taste.  Both ways should be possible.
> 

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
=====================================================================