# Why must u-boot env offset be multiple of alignment? **URL:** \ **Category:** General Discussions\ **Created:** [June 16, 2020, 7:48pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055 "2020-06-16T19:48:41Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![sven](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/sven/32/1554_2.png) [@sven](https://hub.mender.io/u/sven)\ **Post date:** [June 16, 2020, 7:48pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/1 "2020-06-16T19:48:42Z")
Mender requires `MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET` to be a multiple of `MENDER_PARTITION_ALIGNMENT`, why? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [June 16, 2020, 7:58pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/2 "2020-06-16T19:58:53Z")
I would not say it is required. Where did you find this text? At best, it is a recommendation which is applied when you build the `.sdimg/uefiimg` images. This is an optimization, 1. If partitions are aligned to a boundary that matches the HW erase block size, there are certain performance gains (see [flashbench](https://github.com/bradfa/flashbench)) 2. If U-Boot environment is aligned to the same HW boundary, this _ensures_ that the redundant U-Boot environments do not end up in the same HW erase block. Though this is hard to know if it actually will be the case on managed flash devices (eMMC) ---
**Author:** ![sven](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/sven/32/1554_2.png) [@sven](https://hub.mender.io/u/sven)\ **Post date:** [June 16, 2020, 9:17pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/3 "2020-06-16T21:17:23Z")
I’m referring to this error: [https://github.com/mendersoftware/meta-mender/blob/6496fe9864a2c9473194195207beb2cdf665b85b/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender.inc#L8](https://github.com/mendersoftware/meta-mender/blob/6496fe9864a2c9473194195207beb2cdf665b85b/meta-mender-core/recipes-bsp/u-boot/u-boot-fw-utils-mender.inc#L8) Performance is probably not that important for this, but I do see the point of having the 2 environments in two separate erase blocks. Is it possible to find out how eMMCs handle this? ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [June 18, 2020, 7:45am UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/4 "2020-06-18T07:45:22Z")
> Is it possible to find out how eMMCs handle this? I am not aware of a way to inspect this, but the assumption is as long as you are writing to blocks that are aligned to the erase-block size, that is the best one can do with the interface provided to the managed flash. I can recommend this article, which contains some good information on how managed flash works, > **[Optimizing Linux with cheap flash drives \[LWN.net\]](https://lwn.net/Articles/428584/)** > > Flash drives are getting larger and cheaper; as a result, they are showing > up in an increasing number of devices. These drives are not the same as > the rotating-media drives which preceded them, and they have different > performance characteristics. ... ---
**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:** [June 18, 2020, 7:52am UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/5 "2020-06-18T07:52:45Z")
> [@mirzak](#): > > If U-Boot environment is aligned to the same HW boundary, this _ensures_ that the redundant U-Boot environments do not end up in the same HW erase block. Though this is hard to know if it actually will be the case on managed flash devices (eMMC) It is essentially required for the above reason. Meta-mender doesn’t have an explicit erase block size variable, so we use `MENDER_PARTITION_ALIGNMENT` for that purpose. ---
**Author:** ![sven](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/sven/32/1554_2.png) [@sven](https://hub.mender.io/u/sven)\ **Post date:** [June 18, 2020, 8:05am UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/6 "2020-06-18T08:05:38Z")
Doesn’t it? What about `MENDER_STORAGE_PEB_SIZE`? ---
**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:** [June 18, 2020, 9:15am UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/7 "2020-06-18T09:15:38Z")
Alright, since you asked I will answer this a bit more in depth: You are correct that `MENDER_STORAGE_PEB_SIZE` refers to the physical erase block size of the storage medium. And for MMC/SSD/HDD type storage devices, this is indeed the default value for `MENDER_PARTITION_ALIGNMENT`. But here comes the additional complexity: On devices using UBIFS, `MENDER_STORAGE_PEB_SIZE` is no longer the same as `MENDER_PARTITION_ALIGNMENT`, because UBI volumes use additional bytes for internal bookkeeping. Here we have an additional unit, the `MENDER_UBI_LEB_SIZE`, or Logical Erase Block size, which is smaller than the PEB, and usually not a power of two. On UBI devices it is important that `MENDER_PARTITION_ALIGNMENT` is equal that _this_ value, and not the PEB value. > Meta-mender doesn’t have an explicit erase block size variable, so we use `MENDER_PARTITION_ALIGNMENT` for that purpose. So this statement was perhaps not entirely correct. What I meant was that we don’t have _one single_ erase block size variable that can be used for the purpose of aligning the redundant environments, because on UBI devices the Logical Erase Block size is not equal to the Physical Erase Block size, whereas on other devices it is. One could perhaps argue that this should have been organized better, but the UBI support was added long after `MENDER_PARTITION_ALIGNMENT` was added, so the reason that the latter is considered the “master” variable is somewhat historical. ---
**Author:** ![sven](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/sven/32/1554_2.png) [@sven](https://hub.mender.io/u/sven)\ **Post date:** [June 22, 2020, 1:50pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/8 "2020-06-22T13:50:57Z")
Thanks for the detailed writeup! In my application, I would like to have a partition alignment of 4 MiB, but place the u-boot environments at 2048 kiB and 2560 kiB, respectively. This is because my eMMC has an `erase_size` of 512 kiB, but a `preferred_erase_size` of 4 MiB. In this scenario, the error mentioned above is quite limiting. Is there any way to get rid of that error? The reason why I have such obscure requirements is that I’d like to transition existing devices (partition layout exists) to mender. This presents a few challenges as there is little space (4 MiB) before the first partition starts. ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [June 22, 2020, 1:59pm UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/9 "2020-06-22T13:59:58Z")
One possibility might be to bypass this error as you want to add your own custom `/etc/fw_env.config`. Not sure what your setup is and if you are using a U-Boot fork recipe, but you might be able to omit the include of `u-boot-fw-utils-mender.inc` and just use `u-boot-mender-common.inc`. I know something similar was done [here](https://github.com/mendersoftware/meta-mender/blob/rocko/meta-mender-toradex-nxp/recipes-bsp/u-boot/u-boot-toradex-fsl-fw-utils_%25.bbappend), which also provided a custom `/etc/fw_env.config` instead of relying on the logic provided by `u-boot-fw-utils-mender.inc` ---
**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:** [June 23, 2020, 6:50am UTC](https://hub.mender.io/t/why-must-u-boot-env-offset-be-multiple-of-alignment/2055/10 "2020-06-23T06:50:01Z")
I suppose we could accept a PR which introduces a variable to skip that error, obviously with a huge warning in the comments that you better know what you’re doing if you disable the error. Of course I cannot guarantee that there aren’t other ill effects this would have, since we don’t test this configuration.