Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the environment before printing this e-mail
On 24-09-2020 13:08, Rasmus Villemoes wrote:
On 24/09/2020 12.54, Wolfgang Denk wrote:
Dear Rasmus,
In message <125344f4-2b69-1c7a-0f5a-6d27ab312...@prevas.dk> you wrote:
On our newer boards with the 4K erase size, saving the environment now
takes 0.080 seconds instead of 0.53 seconds, which directly translates
to that much faster boot time since our logic always causes the
environment to be written during boot.
Is this your way of implementing scheduled obsolescence?
I'll ignore that.
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.
