# No Boot Partition but I still have a 16MiB Gap at the start of the eMMC **URL:** \ **Category:** General Discussions\ **Created:** [October 2, 2019, 12:57pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093 "2019-10-02T12:57:46Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@martin](https://hub.mender.io/u/martin)\ **Post date:** [October 2, 2019, 12:57pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/1 "2019-10-02T12:57:46Z")
Hi, I have set MENDER\_BOOT\_PART\_SIZE\_MB = “0” in the machine configuration file as we put the bootloader in the mmcblk0boot0 partition of the eMMC. After flashing the resulting sdimg but was surprised to see that there is a 16MiB Gap at the start of the eMMC. In the hexdump below you can see the U-Boot environment start at 0x1000000 and a big gap between the MBR and the environment in between. ```auto 00000000 fa b8 00 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |................| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..| 00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 be 20 f4 8f 00 00 00 00 |......... ......| 000001c0 41 80 83 03 e0 ff 00 c0 00 00 00 80 0f 00 00 03 |A...............| 000001d0 e0 ff 83 03 e0 ff 00 40 10 00 00 80 0f 00 00 03 |.......@........| 000001e0 e0 ff 83 03 e0 ff 00 c0 1f 00 00 00 56 00 00 00 |............V...| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 01000000 a0 55 12 1f 01 61 6c 74 62 6f 6f 74 63 6d 64 3d |.U...altbootcmd=| 01000010 72 75 6e 20 6d 65 6e 64 65 72 5f 61 6c 74 62 6f |run mender_altbo| [snip..] ``` The output of fdisk -l ```auto Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk1p1 384,0,1 1023,3,32 49152 1064959 1015808 496M 83 Linux /dev/mmcblk1p2 1023,3,32 1023,3,32 1064960 2080767 1015808 496M 83 Linux /dev/mmcblk1p3 1023,3,32 1023,3,32 2080768 7716863 5636096 2752M 83 Linux ``` It’s not a major problem as the size of the eMMC is way more that we need but I thought I would ask if this is expected as I see the Boot Partition default size is 16MiB. Or maybe I have missed some other configuration variable? Anyway we have it working and performing image and package updates and are really impressed with everything so far. Cheers, Martin. Edit: @mirzak: Formatting ---
**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:** [October 2, 2019, 1:02pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/2 "2019-10-02T13:02:49Z")
> After flashing the resulting sdimg but was surprised to see that there is a 16MiB Gap at the start of the eMMC. This relates to the [MENDER\_PARTITION\_ALIGNMENT](https://docs.mender.io/2.1/artifacts/yocto-project/variables#mender_partition_alignment) variable which be default is set to 8MB. And you actually have two sets of U-Boot environment which are also aligned to [MENDER\_PARTITION\_ALIGNMENT](https://docs.mender.io/2.1/artifacts/yocto-project/variables#mender_partition_alignment) and hence the 16 MB. You can optimize this, but the reasoning for this to try to put the redundant U-Boot environment on different blocks. It is actually hard to know where the eMMC firmware will actually store it, but an effort is made it at least 🙂 ---
**Author:** ![martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@martin](https://hub.mender.io/u/martin)\ **Post date:** [October 2, 2019, 1:29pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/3 "2019-10-02T13:29:24Z")
Thanks for the info and it makes sense to put the environments on different blocks so I think I’ll leave this as it is. We only have one environment currently. Would this still give the 16MiB alignment. I’m just curious now as to how the partition layout is calculated 🙂 This raises another question I had, if I enable the redundant environment in the U-Boot configuration which I really should do, will mender update both of them? I suppose it will as the u-boot-fw-utils handle this? Just wanted to check. Cheers, Martin. ---
**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:** [October 2, 2019, 1:32pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/4 "2019-10-02T13:32:43Z")
> [@martin](#): > > We only have one environment currently. Would this still give the 16MiB alignment. I’m just curious now as to how the partition layout is calculated You actually should have two, as meta-mender will define this for you magically 🙂 > I suppose it will as the u-boot-fw-utils handle this? Just wanted to check. Yes, the u-boot-fw-utils handle this as long it is configured as such in `/etc/fw_env.config` (it should have two entries representing the two locations). The Mender client will call `fw_printenv/fw_getenv` directly ---
**Author:** ![martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@martin](https://hub.mender.io/u/martin)\ **Post date:** [October 2, 2019, 1:46pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/5 "2019-10-02T13:46:03Z")
ah, sounds like I need to find out why I only have one. I take it I should see one at 0x00800000 and one at 0x01000000 The fw\_env.config file seems to support this ``` /data/u-boot# cat fw_env.config /dev/mmcblk1 0x800000 0x20000 /dev/mmcblk1 0x1000000 0x20000 ``` If you look at the hexdump in a previous message I only have one at 0x010000000 and looking at the header bytes `01000000 a0 55 12 1f 01 61` I think the fifth byte is whether the environment is the redundant one so for some strange reason it looks like I have only the redundant environment. Very odd. I don’t seem to get any messages in the console about CRC failing for the primary environment. Have you seen this before? ---
**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:** [October 2, 2019, 1:49pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/6 "2019-10-02T13:49:34Z")
I think this relates to the fact that you have not yet written to the “redundant”. And “redundant” is a actually a bad name as it is a A/B update strategy applied to the U-Boot environment so it just keeps switching as you write e.g if you try running the following: ```auto fw_setenv test 1 fw_setenv test 2 ``` and you should have data in both areas. ---
**Author:** ![martin](https://avatars.discourse-cdn.com/v4/letter/m/73ab20/32.png) [@martin](https://hub.mender.io/u/martin)\ **Post date:** [October 2, 2019, 2:02pm UTC](https://hub.mender.io/t/no-boot-partition-but-i-still-have-a-16mib-gap-at-the-start-of-the-emmc/1093/7 "2019-10-02T14:02:40Z")
I never realised that, I thought it was just a “redundant” copy that was kept in case the block containing the original one gets corrupted. After running fw\_setenv I get the second environment and the fifth byte is 0x02 for redundant (or copy B) so 0x01 must be for the Copy A. Thanks Mirzak.