Am Mi., 21. Nov. 2018, 15:23 hat Wolfgang Denk <w...@denx.de> geschrieben:
> Dear Stefano, > > In message <151c30b1-d383-d212-a611-519150a80...@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: w...@denx.de > "I like your game but we have to change the rules." > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
