From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Villemoes Date: Thu, 24 Sep 2020 13:58:29 +0200 Subject: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO In-Reply-To: References: <20200506084701.8076-1-rasmus.villemoes@prevas.dk> <20200506084701.8076-3-rasmus.villemoes@prevas.dk> <125344f4-2b69-1c7a-0f5a-6d27ab312487@prevas.dk> <4015025.1600944876@gemini.denx.de> <9ca8a55c-4df4-785a-5eb7-9efaa9d633c2@prevas.dk> <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.f435d534-2cba-4875-b180-3df85765465d@emailsignatures365.codetwo.com> <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.0d2bd5fa-15cc-4b27-b94e-83614f9e5b38.1e7a7c88-825a-48b1-844c-973bce803cb6@emailsignatures365.codetwo.com> Message-ID: <50603bd2-d86c-8fd5-45ca-4f5516b4ce3f@prevas.dk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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