Hi @tomasvilda,
Few comments after some testing.
U-Boot CONFIG_ENV_RANGE is told to be optional, and when not specified equals CONFIG_ENV_SIZE, which is 0x20000 by default in Toradex U-Boot for colibri_imx6ull. CONFIG_ENV_RANGE by default is set to u-boot-env partition size. CONFIG_ENV_RANGE is how much space is erased starting from current main or redundant environment. So clearly you should reduce this ENV_RANGE so that erase started from redundant Env doesn’t cross the top of u-boot-env partition.
I don’t know how it is actually done in Linux, I hope Linux MTD driver doesn’t allow crossing MTD device size. I wonder how to check it. But since you are using U-Boot bootcounter in Env, I think U-Boot was destroying your UBI when it was updating bootcounter. It does it on start. With wrong CONFIG_ENV_RANGE bottom of UBI partition won’t be overwritten saving to primary Env location. And saving to redundant location UBI is clearly crossed.
Additional issue, you could never notice. Due to ENV_OFFSET + ENV_RANGE overlapping ENV_OFFSET_REDUND, when U-Boot was writing to primary Env, it was destroing redundand Env. After write to redundand Env, primary Env was not affected.
I was assuming that redundant environment is about saving two equal copies every time. In fact, every saveenv in U-Boot writes every time only one copy and alters copy destination every time. So, to be confident about two equal copies, you need to saveenv in U-Boot twice. U-Boot confirms which instance is overwritten every time.
What about Linux side and U-Boot fw_env? It is the same. But in contrast to U-Boot, it doesn’t allow saving two identical Env copies. You need to fw_saveenv with some new setting, perhaps toggling some extra unused variable, else Linux won’t save anything to alternate Env location. You may check it like below using hexdump and grep <your_variable_name>. First and 2nd copy is easily distinguishable by hexdump address.
~# hexdump -C /dev/mtd3 | grep boo
00000040 74 77 72 5f 6d 79 00 62 6f 6f 3d 31 37 00 62 6f |twr_my.boo=17.bo|
000000c0 62 6f 6f 74 5f 65 78 74 6c 69 6e 75 78 3d 73 79 |boot_extlinux=sy|
...
00040040 74 77 72 5f 6d 79 00 62 6f 6f 3d 31 38 00 62 6f |twr_my.boo=18.bo|
000400c0 62 6f 6f 74 5f 65 78 74 6c 69 6e 75 78 3d 73 79 |boot_extlinux=sy|
...
Like I understand SWUpdate by U-Boot Env atomicy means simultaneous write of all used U-Boot variables. But does it handle the case power is cut during that single write? I doubt it, unless they toggle something extra, else 2nd identical Env copy won’t be stored. No big deal though, just update again.
Lack of knowledge of details is why I tried to avoid changing U-Boot environment from Linux. Now, after things are clear, it’s quite safe to use it, especially with redundant Env enabled.
Back to your former question
I think you meant here bootcounter + upgrade_available. Yet another useful U-Boot feature, I wonder why is not enabled in Toradex U-Boot.
So that if for example update file passed all checks and readched end user with kernel for different machine, after bootcounter elapses, how to make U-Boot executing right altbootcmd command. With ubiswap things change a bit, because power may be cut after UBI volumes are swapped, but before upgrade_available variable is set. It could be solved setting upgrade_available=1 just before update process. All Linux versions still should clear it as a result of successfull boot, so no problems with this. And altbootcmd is stright forward, just load kernel, dtb from alternative volumes, as well specify alternative volume on kernel command prompt. Well, both ubiswap and copy-N methods are equally robust, provided U-Boot is compiled with right settings.
Regards,
Edward