# Guidelines for using the eMMC boot partitions **URL:** \ **Category:** General Discussions\ **Created:** [July 22, 2020, 5:16pm UTC](https://hub.mender.io/t/guidelines-for-using-the-emmc-boot-partitions/2220 "2020-07-22T17:16:51Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![kevlan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kevlan/32/695_2.png) [@kevlan](https://hub.mender.io/u/kevlan)\ **Post date:** [July 22, 2020, 5:16pm UTC](https://hub.mender.io/t/guidelines-for-using-the-emmc-boot-partitions/2220/1 "2020-07-22T17:16:51Z")
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. Our SOM vendor Compulab as well as Toradex ([https://developer.toradex.com/knowledge-base/emmc-linux#Storage\_and\_Partitioning](https://developer.toradex.com/knowledge-base/emmc-linux#Storage_and_Partitioning)) seem to recommend putting uboot into the boot partitions (/dev/mmcblk0boot0) on the eMMC instead of as a part of the image which our mender config does. This leads to a couple of questions: 1. Is it recommended with Mender to put uboot into the boot partition on the eMMC or to include it in the main storage space? 2. 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. 3. 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? 4. 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? Thanks, Kevin ---
**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\ **Post date:** [July 23, 2020, 7:32am UTC](https://hub.mender.io/t/guidelines-for-using-the-emmc-boot-partitions/2220/2 "2020-07-23T07:32:50Z")
> [@kevlan](#): > > Is it recommended with Mender to put uboot into the boot partition on the eMMC or to include it in the main storage space? 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. > [@kevlan](#): > > 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. 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`. > [@kevlan](#): > > 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? 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). > [@kevlan](#): > > 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? 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. ---
**Author:** ![kevlan](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kevlan/32/695_2.png) [@kevlan](https://hub.mender.io/u/kevlan)\ **Post date:** [July 23, 2020, 4:34pm UTC](https://hub.mender.io/t/guidelines-for-using-the-emmc-boot-partitions/2220/3 "2020-07-23T16:34:16Z")
> 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.