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

[Stefano Babic]

Hi Simon,

On 21/11/18 11:14, Simon Goldschmidt wrote:
> On Wed, Nov 21, 2018 at 10:33 AM Stefano Babic <sbabic at denx.de> wrote:
>>
>> 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.
> 
> No, I want to prevent recompiling the u-boot-tools package (fw_setenv)
> and Swupdate after changing U-Boot's default environment.
> 

Right, I understand this.

> In fact, we are running a Debian-based system and I would like to run
> upstream Debian u-boot-tools. And of course running an upstream
> swupdate package would be preferred as well.

I am searching / waiting for a mentor:

	https://mentors.debian.net/package/swupdate

Package should be updated as well, but I'll push a new release for the
end of the month.

> 
> One way to fix this would be to let fw_setenv somehow write an
> environment that doesn't need to know the default environment and is
> loaded in a "add" way, not replacing the whole environment as we
> normally do on load.

True, but this has side effect and limitation. You cannot change a
variable in the deafult environment if you need it because you do not
know it. If some changes are needed, even if for very small things like
activating a gpio before ooting, you need to update the bootloader.

I have also thought at this but I dislike the drawbacks.

> 
> And security wise, I think linking in things as static libs in
> Swupdate is not a good decision as you can end up with 2 different
> versions of the same sources in your target.

This is a different topic - but until the library was used in SWUpdate,
there was not another user, and if SWUpdate is the only user of it,
static linking is fine.

Moving to shared library should be done in U-Boot project, then. Some
changes are then required, at least how the environment is locked (it is
not clean as it is done now - locking should be done by the library and
not by the caller).

> I can understand calling
> external binaries is not a good solution as well.

Right, I explain this in the other e-mail.

> Using shared libs
> would be best. That would mean u-boot-tools fw_setenv would use a
> shared library to access the environment and swupdate could use it,
> too.
The approach is fine with me.

> 
>>
>>>
>>>>> * 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?
> 
> In a secure boot environment, you cannot allow to load the environment
> from an untrusted source. We need a default environment in this case.

Or you make that changes are trusted.

> 
> But there are better ways than compiling it in via C headers, of course!

Exactly - another possible way is to use a configuration file, run a
sort of "mkenvimage", bound the result to u-boot and use the
configuration file as input for the libubootenv.[a|so] library.

Best regards,
Stefano

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


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