[PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

[Rasmus Villemoes]

On 24/09/2020 13.35, Mike Looijmans wrote:

>>> Automatically writing the environment on every boot is always a
>>> really bad idea. Never ever do that.
>>
>> Well, there's really no other place on this piece of hardware to
>> implement a boot counter/slot selection. Sure, we could use another part
>> of the spi flash and define our own storage format etc., but then we
>> might as well use the u-boot environment, which allows us to use
>> existing tools/APIs both on the U-Boot and linux side.
>>
>> And yes, the number of erase cycles compared to how often this device is
>> booted was taken into account when this was decided.
> 
> If it's SPI NOR flash, you can make use of the fact that you can change
> any 1 into a 0 without erasing the flash sector.
> 
> So if you use a unary counter (the number of consecutive zero bits),
> incrementing the counter doesn't require a sector flash.
> 
> I once used this for a medical device. After an upgade, the flash would
> boot-count and after 3 failed boots fall back to the previous image. The
> software would mark the image as "good" once booted okay by clearing the
> special "image is okay" bit.
> 
> This way there's only one erase cycle for every software upgrade, even
> with the use of a bootcounter.

Yes, I/we considered some scheme like that (though we store a bit more
information, so not exactly what you described), essentially just using
a sector as append-only storage for an array if fixed-size small blobs
(I think we could fit everything into 16 bytes or so, but if its 4 or 16
or ... doesn't really matter). On reading, we'd read the whole sector
and use the last not-all-ones blob, probably with some sanity checking.
On writing, we'd only have to do an erase once every 256 or 1024 or
whatever. But regardless, the complexity of having to write a small
linux tool for that and patching the u-boot side similarly, and
maintaining that code forever (because we really _do_ plan to keep
updating the software on these devices, including u-boot), and that the
spi flash has 100000 expected erase cycles, meant that we went for the
much simpler, and easily extendible, solution.

In the field, these devices are usually turned on and then run for
_months_. But when they are booted, getting up and running quickly is
somewhat important. In our test rack, they are exposed to 1000s of
power-cut tests among others (so one of those might eventually wear out
the spi flash - but actually getting data on when that can be expected
is just a bonus), so there saving half a second of boot time means we
can do more tests in a given time span.

Rasmus