No Boot Partition but I still have a 16MiB Gap at the start of the eMMC

General Discussions
1

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.

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

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

2

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 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 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 :slight_smile:

3

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 :slight_smile:

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.

4

You actually should have two, as meta-mender will define this for you magically :slight_smile:

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

5

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?

6

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:

fw_setenv test 1
fw_setenv test 2

and you should have data in both areas.

7

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.