# Alternative to U-Boot environment for persisted state information?

**URL:** <https://hub.mender.io/t/alternative-to-u-boot-environment-for-persisted-state-information/5314>\
**Category:** General Discussions\
**Tags:** imx8mm\
**Created:** [October 12, 2022, 9:57pm UTC](https://hub.mender.io/t/alternative-to-u-boot-environment-for-persisted-state-information/5314 "2022-10-12T21:57:23Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![tbenson](https://avatars.discourse-cdn.com/v4/letter/t/a698b9/32.png) [@tbenson](https://hub.mender.io/u/tbenson)\
**Post date:** [October 12, 2022, 9:57pm UTC](https://hub.mender.io/t/alternative-to-u-boot-environment-for-persisted-state-information/5314/1 "2022-10-12T21:57:23Z")

</div>

Hi all,

I have started to work on some software for a Boundary Devices Nitrogen8M Mini SBC (i.MX8M Mini Soc). The early stage project is posted at [GitHub - tbensonatl/oolong](https://github.com/tbensonatl/oolong). I am using buildroot as the build system, but used the patches and scripts from the Yocto layer as a starting point. With that, I have successfully integrated Mender into the bootloader and confirmed that I can update via mender artifacts.

One complication is that the bootloader is stored to the eMMC hardware boot partition (/dev/mmcblk0boot0 in Linux) and the environment is stored in this same partition (and then redundantly in /dev/mmcblk0boot1). This partition is not writable by default, so the client is unable to update the U-Boot environment. I worked around that with the following patch: [oolong/0010-make-boot-partition-writable.patch at main · tbensonatl/oolong · GitHub](https://github.com/tbensonatl/oolong/blob/main/oolong-br-external/board/nitrogen8mm_rev2/patches/mender/0010-make-boot-partition-writable.patch). The patch makes the partition writable when an update is needed and reverts back to read-only after completion.

That works, but I would prefer to not need to update the U-Boot environment at all so that I can embed the environment to be read-only in the bootloader image (i.e. set CONFIG\_ENV\_IS\_NOWHERE=y). I realize that we minimally need to be able to store the active partition, bootcount, and upgrade\_available variables, but has there been any work to store these elsewhere? I currently create 4 partitions and use p2 and p3 as the mender active/inactive partitions. p1 is currently unused, but e.g. I could create a `mender/env` directory in that partition and read the relevant data from files in U-Boot as an alternative to the U-Boot environment. Are there any major downsides to using files in a user partition to maintain state rather than the U-Boot environment? File corruption is one obvious concern, although including a checksum (like the U-Boot environment) would help with integrity.

Thanks,

Thomas Benson

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [October 13, 2022, 7:33pm UTC](https://hub.mender.io/t/alternative-to-u-boot-environment-for-persisted-state-information/5314/2 "2022-10-13T19:33:38Z")

</div>

Hi @tbenson,

thanks for showing your project! That is really a cool thing, let me know if I can help you from the Mender side 🙂

For your question, the first thing that comes to my mind is using some form of non-volatile memory that the board provides. Is there maybe some EEPROM, battery-backed storage, or similar? It certainly needs a little more tuning than “just” using the U-Boot environment, but it should definitively be possible.

Greetz,  
Josef

---

<div class="post-metadata">

**Author:** ![tbenson](https://avatars.discourse-cdn.com/v4/letter/t/a698b9/32.png) [@tbenson](https://hub.mender.io/u/tbenson)\
**Post date:** [October 23, 2022, 7:40pm UTC](https://hub.mender.io/t/alternative-to-u-boot-environment-for-persisted-state-information/5314/3 "2022-10-23T19:40:57Z")

</div>

Hi @TheYoctoJester,

I have made some progress on storing the mender-relevant portions of the U-Boot environment externally on an ext4 filesystem. I made changes to both U-Boot and fw\_printenv/fw\_setenv to accommodate this approach. The change to uboot-tools (fw\_printenv/fw\_setenv) is to support using files and not just block devices.

The bigger change is to U-Boot. There, I added a function to import the external mender environment from an ext4 filesystem (the device and filename are specified in the Kconfig). I also implemented the bootcount interface so that the `bootcount_store` command writes to the external mender environment. The U-Boot load/store functions also support a redundant external environment if it is selected via the Kconfig. The variables in the external mender environment and the environment files are as follows:

```auto
$ ls -l /recovery/mender/
total 16
-rwxr-xr-x 1 root root 8192 Jan 1 00:00 uboot-env-redundant.bin
-rwxr-xr-x 1 root root 8192 Jan 1 00:00 uboot-env.bin
$ fw_printenv 
bootcount=1
mender_boot_part=2
mender_boot_part_hex=2
mender_check_saveenv_canary=1
mender_saveenv_canary=1
upgrade_available=0

```

These are normal U-Boot environments that include the typical CRC and flags fields, but they are treated as overlays of the built-in U-Boot environment rather than the full environment. Similarly, the writes only write out the variables included above.

Thus far I have only tested the normal upgrade path using mender artifacts, so I still need to test the rollback logic. If anyone is interested in taking a look, it is currently under the add-mender-external-environment branch: [GitHub - tbensonatl/oolong at add-mender-external-environment](https://github.com/tbensonatl/oolong/tree/add-mender-external-environment). The relevant patches are [oolong/0020-add-mender-external-env.patch at add-mender-external-environment · tbensonatl/oolong · GitHub](https://github.com/tbensonatl/oolong/blob/add-mender-external-environment/oolong-br-external/board/nitrogen8mm_rev2/patches/uboot/0020-add-mender-external-env.patch) and [oolong/0010-add-file-env-support.patch at add-mender-external-environment · tbensonatl/oolong · GitHub](https://github.com/tbensonatl/oolong/blob/add-mender-external-environment/oolong-br-external/board/nitrogen8mm_rev2/patches/uboot-tools/0010-add-file-env-support.patch).

Regards,  
Thomas