a few quick questions about this feature before i move on to the more widely-used stuff involving bootcount.
first, it seems that there's not a lot of saving bootcount in the environment ... as i see it, there's the taurus board, and there's the boards that include "siemens-am33x-common.h", of which i see six:
include/configs/rut.h:#include "siemens-am33x-common.h" include/configs/draco.h:#include "siemens-am33x-common.h" include/configs/etamin.h:#include "siemens-am33x-common.h" include/configs/rastaban.h:#include "siemens-am33x-common.h" include/configs/pxm2.h:#include "siemens-am33x-common.h" include/configs/thuban.h:#include "siemens-am33x-common.h"
so this tells me that there's not a whole lot of that feature being used, so i won't spend much time on it.
also, just to confirm, the "upgrade_available" variable is used *exclusively* for the case of bootcount in the environment and nowhere else, correct? so, again, if i'm not using the environment, i don't care about it.
finally, i read this in the README:
CONFIG_BOOTCOUNT_ENV If no softreset save registers are found on the hardware "bootcount" is stored in the environment. To prevent a saveenv on all reboots, the environment variable "upgrade_available" is used. If "upgrade_available" is 0, "bootcount" is always 0, if "upgrade_available" is 1 "bootcount" is incremented in the environment. So the Userspace Applikation must set the "upgrade_available" and "bootcount" variable to 0, if a boot was successfully.
now, i can see where one wants to reset "bootcount" to zero once you boot successfully, but why would you also set "upgrade_available" to zero? don't you want to keep using that feature when you boot in the future?
rday