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

[Simon Goldschmidt]

Am Mi., 21. Nov. 2018, 15:23 hat Wolfgang Denk <wd at denx.de> geschrieben:

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

That would make sense, yes. Seems like I really did mix things up. I think
going this way would solve things for the distro packages as well as keep
usage scenarios like mine running.

Regards,
Simon


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