I am trying to understand the mender partition layout and the storage of the uboot environment better when using eMMC storage with u-boot on an i.MX8m.
Is it recommended with Mender to put uboot into the boot partition on the eMMC or to include it in the main storage space?
What would need to be changed in our config and programming process to make that change? I am guessing this would require changes to some of these variables:
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET
BOOTENV_SIZE
MENDER_UBOOT_STORAGE_DEVICE
as well as having a separate dd step to copy the uboot into the boot partition.
Does moving where the uboot is stored change where the uboot env is at?
For the i.MX platform I have seen some examples that have multiple ENV_STORAGE_DEVICE_OFFSETs. Is there documentation that describes how that is supposed to be set? Should we always have multiple environments? Are these offsets arbitrary or where do they come from?
I am working with the Dunfell yocto release so are there any specific issues with this approach that I should be aware of when using the libubootenv instead of uboot_fw_utils?
It is recommended to put it in the main storage space. This configuration is standard practice for all Mender enabled images and is being tested repeatedly, both by our test framework and by our users. If you do it in a different way you are not taking advantage of this well tested path.
As far as I know there is no particular advantage to having it in the eMMC. And because of Mender’s special boot code, it is tightly coupled to the rootfs partition configuration in the main storage, so it makes sense that it’s next to it.
I think there is no out-of-the-box support for disabling use of the main storage for the U-Boot environment; these are expected to be next to each other. You will probably have to rewrite some parts inside mender-part-images.bbclass.
Careful how you pose the question: Moving where U-Boot is stored does not change where the environment is at, and U-Boot can be in the eMMC while the environment is in main storage. However, that is not what the variable you mentioned does. Multiple ENV_STORAGE_DEVICE_OFFSET variables are common, and in fact enforced in Mender’s configuration. This is called redundant environment, and helps ensure that the device can not corrupt the environment if a power outage occurs during a critical write.
The offsets are calculated by Mender based on the value of MENDER_PARTITION_ALIGNMENT, and are normally located at the second and third multiple of this value (the first being reserved for the partition table).
Only that you need to use Mender client 2.2.1 or later, as previous versions are not compatible with libubootenv. Otherwise libubootenv is perfectly compatible with uboot-fw-utils as far as I know.
As far as I know there is no particular advantage to having it in the eMMC. And because of Mender’s special boot code, it is tightly coupled to the rootfs partition configuration in the main storage, so it makes sense that it’s next to it.
The advantage to putting it in the boot partitions of the eMMC is that these are typically implemented in pSLC within the flash which is more reliable and they typically have write protection to protect them from corruption. This would be a good option to have but it sounds like we should stick to the tested path for now. To be clear here, this all lives within the eMMC, the boot partition is just a special area in the eMMC that is more reliable and has special protections on it.
Thanks for the rest of the clarifications on the variables. We will take a deeper look into what is required for this later on.
Only that you need to use Mender client 2.2.1 or later, as previous versions are not compatible with libubootenv. Otherwise libubootenv is perfectly compatible with uboot-fw-utils as far as I know.
We will give this a try today. I will update on the other issue I posted for any further issues with this integration.