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

[Stefano Babic]

Hi Wolfgang,

On 21/11/18 12:38, Wolfgang Denk wrote:
> Dear Stefano,
> 
> In message <6b07725e-51ba-7309-1506-e7211487b947 at denx.de> you wrote:
>>
>>> 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.
> 
> I tend to disagree.  As mentioned, the original intent of the
> default environment was only (!) to make sure that a working
> baudrate setting for the console is available on boards where the
> environment has never been initialized yet (fresh our of
> production) or, but only as additional benefit, that have lost their
> environment somehow.

Current intent is to provide a "factory reset" environment and the
device must be able to be functional even if with limiutation, at least
it should be possible to be restored.

> 
> Usually it is not good for any practical purposes - it is missing
> any board specific settings like MAC adress, IP addresses, serial
> numbers etc.

This is also another aspect that it is difficult to be factorized. Many
projects do not use the env for serial numbers or MAC, but they add an
additional storage with a custom interface.

Storing MAC changed, at least for some SOC as i.MX6, because it is
stored into the SOC (fuses).

> 
> This was when booting from parallel NOR.
> 
> The whole paradigm was dropped when first implementations of SPL
> became necessary to boot from NAND - they all had harcoded baud
> rates, as they could not access the environment (often due to size
> limitations).
> 
> My question is:  why do we need the default environment today?

The "default" environemnt is the "factory reset" environment.

> 
> It just consumes a couple of kB size,

I guess more on some boards...

> and does not bring any
> measurable benefits.
> 
>>> - 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
> 
> Then why not create one?

Where ? Which project ? You men OE ?

I built and include a sort of u-boot-dev in meta-swupdate, and I have
never heard of someone else who wants to use it up now.

> 
>>> - 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.
> 
> You don't have to rebuild U-Boot - building the lib should be
> sufficient.

If there is a configuration file that can be imported by the lib and it
remains in sync with U-Boot, if U-Boot still sues linked environment.

> 
>> 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).
> 
> And I ask again: what exactly would we lose if we drop the whole
> default environment?

Board is not able to run after flashing the bootloader. This is become
worse in the last time due to secure boot. In fact, if this "factory
environment" is linked to U-Boot, it is signed together with U-Boot and
can be trusted (this is the original topic in the thread).

If we use in U-Boot a sort of env import, we have to be sure that we can
trust it.

>  I mean, what would we lose that we have not
> already given up elsewhere with nobody ever complaining about?

I see a lot of complains..

The feature we give with it is an additional redundancy because board
comes up even if environment in flash is damaged.

> 
>> 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.
> 
> I would be seriously surprised if a single board in real  life uses
> the default environment, and only that, for normale operation.

I guess you are really surprised !

There are plenty of boards - "default environment" means "factory reset
environment".

> 
>>> 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.
> 
> You misunderstand.  

I guess...

>This was not primarily intended for the
> _default_ environment, but to _initialize_ the real environment.

This was maybe the initial goal, but if I look in current code there is
just the symbol "default_environment" in the ELF. It contains the
default as you mind + the "real" initialization environment from
CONFIG_EXTRA_ENV.

> In these olden days this would usually be placed insome smaller
> sectors of the parallel NOR flash, and special (hand-tuned) linker
> scripts would make sure that the respective data would be properly
> placed in the U-Boot image.

It could be, but I am talking about what I see in current code.

> 
> At these times, a U-Boot image would usually contaim 3 copies of the
> same data: two redundant copies of the normal, persistent
> environment, embedded somehwere at "magic offsets" in the image,
> plus the default environment (somehwere in the [read-only] data
> segment, basically at an unknown address).

I do not see the last one in data - there are two copies (with
CONFIG_ENV_REDUND set, of course) in flash + one (called
"default_environment") in .text segment. And yes, it is linked, and
address changes.

> 
> There would be a few boards that did not use embedded environments,
> so other ways wewre selected to initialize it.
> 
> But the default environment was never ever intended to be used for
> this purpose.
Ok - but the fact is how it is used nowadays. Just see the number of
patches sent to ML just to change something in CONFIG_EXTRA_ENV.

> 
>> 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".
> 
> It was 1:1 coding at the time, done by a handful of experts, when
> the number of contributors was still single-digit.

Right

> 
> I fully afree that it would be much nicer if we could just place it
> as plain text (ideally even commented!) on some other file.

+1

> 
> But then: there is no technical reason not to implement this.
> Volunteers welcome!

+1

but we need some concept how to do: do we link the generated environment
as today ? Or do we put somewhere else, for example at the end of U-Boot
(and SPL, too, as some boards can read environment in SPL).

> 
>> 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.
> 
> This is a broken design, and should be fixed.  We don't need three
> copies of the environment.  We should get rid of the "default"
> environment and replace it with a better way to initialize the real
> environment.

We have still3 copies of the environment. Fine if we find a common way
and not board specific to load the initial environment.

> 
> And yes, I really hate all these distro settings, because they are
> inelegant and unflexible and the slightest change requires to rebuild
> and reinstall the whole U-Boot image, when all you want to change is
> just a variable setting.  This is CRAP!

There are different goals. Distros want to have exactly the same
interface for all boards and same set of scripts to boot. If ideally
there is just one u-boot at least for the same set of architecture,
distros could have just one package.

On the other side, products / devices prefer to have a specific
environment to speed up the boot process (distro setting performs
scanning) or to provide custom feature.

> 
> 
> IIUC, it should for example be possible to perform the initialization
> of the normale environment by running the equivalent of "env import"
> from some image (uImage or FIT image or even a plain text file

A signed fit image with the environment should be possible. Anyway, the
same (not signed) we have running mkenvimage on an ASCII file and then
store somewhere.

> [though I'd not recommend the latter as it includes zero consistency
> checking].
> 
> 
> I mean: instead of complaining about the limitations of an
> antediluvian construct and investing precious energy in creating
> more and more ugly workarounds, we should think about ways to
> replace this with a more flexible and more powerful method.

Agree on this, we should find an accepted and community approved method..

Best regards,
Stefano

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