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 -- 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 paid too much for it, but its worth it. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
