[U-Boot] "uEnv.txt" versus "fw_setenv" -- a question about style

[Wolfgang Denk]

Dear "Robert P. J. Day",

In message <alpine.LFD.2.20.1607220912470.30533 at localhost.localdomain> you wrote:
> 
>   curious about peoples' preferences when it comes to customizing
> u-boot on a running system -- using a "uEnv.txt" file that can be
> trivially edited from user space, as opposed to using the u-boot
> firmware tools to change the actual environment variables in
> persistent storage.

IMO these are two totally different things, i. e. not oopsed to each
other, but orthogonal - you can use both on the same system, for
different purposes.

>   obviously, i can certainly combine the two approaches above, but
> because of the upcoming issue regarding robustness, i'm leaning
> towards the uEnv.txt approach, and here's why.

I should add that this is of course also a matter of taste...

>   if i support updating the env vars in persistent storage, and a
> system in the field suddenly stops booting properly, then i might be
> completely in the dark as to what's in the u-boot environment. how do
> i know what the user has been doing, or what variables he might have
> changed? however, if i keep all the changes in uEnv.txt, it's easy to
> get a look at that file and, also, simply removing that file
> effectively sets the machine back to "factory defaults."

"uEnv.txt" is a method that was introduced relatively late in U-Boot's
lifetime, and it reflects largely the thinking and the requirements of
distro makers.

To be honest: I do not really like it; I can live with it, I can see
why some people use it, but I rarely see a need to use it myself.

It has some disadvantages:

You need file system support, and for each boot you need to mount and
read from a file system.  This is not good for any kind of boot time
optimization.  You can do similar things completely without external
files - plain areas in flash are sufficient.  You can still use "env
import" to set variables; it is as easy or even easier to switch "user
profiles" by loading different sets of env settings, or fall back to
factory defaults by loading a default set (or no set at all).

Normally, all such copies of the environment are protected by CRC32
checksums, so U-Boot will protect you from loading corrupted _data_.

No such potrection is done when reading from a text file!

>   in addition, if i have filesystem corruption that wipes out
> uEnv.txt (among other things), then, again, i have effectively reduced
> the system back to factory defaults so it can boot to a known good
> state of some kind.

But it is also pretty easy to load a totally corrupted set of
environment settings, without any safety seat belt.  If I was to
design attacks to a "protected" U-Boot, I would definitely look into
crafting a specialized "uEnv.txt" file ;-)

>   i guess i'm more comfortable with the idea of a system having a
> solid and tested u-boot environment that rarely (if ever) changes,

Well, it is not that solid - it lacks any kind of protection agains
intentional or accidential corruption.  Ease of use was preferred over
using checksum protected images.

> rather than regularly changing things in the persistent storage, but
> i'm open to being persuaded otherwise; i'm just curious about what
> others prefer.

As mentioned, it is also a matter of taste.  If you have a double copy
system which switches to a new boot device to activate a software
update, and to fall back to the alternative one in case of boot
errors, I find it MUCH easier to flip just a single environment
variable using fw_setenv than to edit a text file, or to manage a
number of alternative text files through copies, moves and/or links.

Others may tell you different stories...

I think this is one of the cases of "there is more than one way to do
it".

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 paid too much for it, but its worth it.