Dear "Robert P. J. Day",

In message alpine.LFD.2.20.1607220912470.30533@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