Hi, On Tue, 17 Nov 2020 at 11:23, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Nov 17, 2020 at 12:31:07PM +0100, Wolfgang Denk wrote: > > Dear Simon, > > > > In message > > <CAPnjgZ3Tdkr-r0D1q-nk48pfGvoMG4ZodUJLh_ZxMQAQb3E=w...@mail.gmail.com> you > > wrote: > > > > > > > Apending data to it is not acceptable. If you need to append data, > > > > then only to the regular environment. > > > > > > > > And please, for the sake of avoiding further confusiion, please do > > > > not name this "default-environment". > > > > > > Apart from what Wolfgang says here, it does seem useful. > > > > On the other hand I wonder in which way "appending to the existing > > environment" is different from what "env import" does? > > > > > I wonder if we should have a way to load the (whole) environment from DT? > > > > You mean adding a DT type specifier to the "env import" command? > > > > Sounds good to me... > > Adding in Marek as well since I believe he's been doing things with > append-only environment, and it would be good to make sure we have > something that fits everyones needs, and doesn't break what people are > already doing as well.
Some years ago I did a series to allow the environment to come from a text file, thus avoiding the \0 stuff. Now binman has a 'u-boot-env' entry type, allowing creating an environment from a text file, with suitable checksumming. There is some advantage to having a default environment compiled into U-Boot that covers everything needed to boot. For one, the environment can be clobbered from userspace, which would otherwise render the device unbootable. For another, it is more secure to avoid loading unsigned data (the environment) from flash. Generally, for a secure boot, one would need to avoid loading the environment, at least without a lot of careful filtering. Regards, Simon
