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

[Wolfgang Denk]

Dear Stefano,

In message <151c30b1-d383-d212-a611-519150a80e98 at denx.de> you wrote:
>
> > 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.

I understand the intend.  But instead of chosing an approoriate
method (creating a separate enviornment block to be loaded with "env
import" which has been created for exactly such purposes as user
profiles or factory reset) they decided to to the Wong Thing.

This should be fixed.

> > My question is:  why do we need the default environment today?
>
> The "default" environemnt is the "factory reset" environment.

You avoid a straight and honest answer here.

It is _used_ for this purpoose, or rather _misused_.

My question is: whyu do we _need_ the default environment today?

I think we should get rid of it, and yes, obviously this means that
we should put the current (mis-) users from their heads to their
feet.

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

You said there was no such image.  I don't know which project you
were referring to...

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

Sorry, I don't understand what you want to tell me here.


> > 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).

This is what people made out of it.  But it's not the only possible
way, and definitely not the best way.

You ignore my arguments.

Instead of using a binary blob inserted somewhere by the linker, we
could use a more suitable data structure, probably even separate and
with it's own signature so it could be used (and verified) by
external tools as well.

And get rid of this current implementation.

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

Any other form of implementation is probably better and more secure.
At themoment the binary blob just gets loaded, without any checking,
not even for corruption.

> I see a lot of complains..

I don't.

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

If you split off the initialization, you could even have more than
one copy of the initial / factory settings if you like.

> > 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".

s/means/has been misused/

This is not a feature, it is part of the problem that should be
solved!

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

This has always been like that.  Yes of course it is a convenient
way to create4 customized initial settings.  But the method how it
is implemented does not scale, and we are running in limitations.

So let's replace it with soemthing more powerful and more flexible.

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

If you were using an "embedded environment" it was 3 copies.
But for initialization, only one would be needed.

> 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).

If we don't use a binary blob any more linking few advantages; the
only one I can think of that it is easy to get the start address in
the code - it's just a variable initialized by the linker.  the
disadvantage is that this address is more or less random unless you
play tricks in the linker script, and it;s difficult to access from
outside.

To me it seems more desirable to have a separate image, so we can
still decide what to do with it:  attach (or otherwise combine it)
with the U-Boot or SPL binary - maybe using the linker or "cat" or
"dd" or FIT images or whatever seems useful in the specific context.
I don't think we have to decide for one specific implementation - we
should allow for flexbility here.

Then we can also use other (external) tools like fw_env to access
this area easily.

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

3, or even more.  This is good, as nobody will suffere from an
increase of the memory footprint.

The difference is that an ancient crutch gets replaced by a more
powerful and flexible mnechanism - one where you can potentially
have not only one "default" (or factory) environment, but more
(think of "user profiles"), which can be changed (even securely,
i.  e. with signature checking) without having to recompile and
re-install U-Boot.

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

I don't think these are so different goals.  These are the result of
the current limitations and that people tend to think small - only
for their own poroject and within the current limits.

As is, each and every distribution will have their own U-Boot
binary.  And switching the distro will mean you have to update
U-Boot.

If we splitt off the defualt environment, distros could use the same
binary (at least in theory) - but in any case switching distros
should just mean you have to add the new environment settings - and
when I say "add" here I mean exactly that. Ideally there would be no
need to replace / remove an already existing (known to be working)
environment from another distro.  We could keep it to allow
switching between distros without reinstall. We could use it as a
fall-back if anything goes wrong.  And so on...

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

Right, but my proposal just adds more lexibility, it does not take
away anything you have right now.

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

Right.  Or, if you are satisfied with the status quo for the default
environment (no checking at all) you could just use a plain text
file.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I like your game but we have to change the rules."