Interpretation of the partition manager report

[rtscts]

Hello,

I built peripheral_hr_coded sample and looking into the partition manager report (I trucated the output):

> west build -t partition_manager_report
  flash_primary (0x100000 - 1024kB): 
+--------------------------------------------------+
+---0x0: b0_container (0x8000 - 32kB)--------------+
| 0x0: b0 (0x8000 - 32kB)                          |
+---0x8000: s0 (0xc200 - 48kB)---------------------+
| 0x8000: s0_pad (0x200 - 512B)                    |
+---0x8200: s0_image (0xc000 - 48kB)---------------+
| 0x8200: mcuboot (0xc000 - 48kB)                  |
+--------------------------------------------------+
| 0x14200: EMPTY_0 (0x3e00 - 15kB)                 |
+---0x18000: s1 (0xc200 - 48kB)--------------------+
| 0x18000: s1_pad (0x200 - 512B)                   |
| 0x18200: EMPTY_1 (0x3e00 - 15kB)                 |
| 0x1c000: s1_image (0xc000 - 48kB)                |
+---0x28000: mcuboot_primary (0x6c000 - 432kB)-----+
| 0x28000: mcuboot_pad (0x200 - 512B)              |
+---0x28200: mcuboot_primary_app (0x6be00 - 431kB)-+
+---0x28200: spm_app (0x6be00 - 431kB)-------------+
| 0x28200: app (0x6be00 - 431kB)                   |
+--------------------------------------------------+
| 0x94000: mcuboot_secondary (0x6c000 - 432kB)     |
+--------------------------------------------------+

What are the s0_pad and s1_pad?

What are the EMPTY_0 and EMPTY_1 areas? I tried changing sizes of B0 and mcuboot partiions and these EMPTY_x areas seem to be moving around. Do they exist to fill in the gaps to make partitions aligned on the flash page boundaries? If so, is it possible to pick sizes such that there are no EMPTY_x areas?

When B0 boots mcuboot from slot 0, it prints

...
Attempting to boot from address 0x8200
...

According to the partition manager report, it is s0_image - mcuboot. It is the address I expect, so all good.

However, when B0 boots mcuboot from slot 1, it prints

...
Attempting to boot slot 1.
Attempting to boot from address 0x18200.
...

But wait, according to the partition manager report 0x18200 is EMPTY_1. One looking at the partition manager report would expect mcuboot in slot 1 us located at 0x1c000 (s1_image, 48 kB).

Nonetheless mcuboot is located at 0x18200: boot is successful.

Is this a bug in the partition manager output? Could you please explain how to interpret the output.

Thanks.

[Simon]

However, when B0 boots mcuboot from slot 1, it prints

...

But wait, according to the partition manager report 0x18200 is EMPTY_1. One looking at the partition manager report would expect mcuboot in slot 1 us located at 0x1c000 (s1_image, 48 kB).

I took a look at the generated .map file for the s1 image (<sample>/build/mcuboot/zephyr/s1_image.map) and I saw that the s1 image indeed started at the empty_1 partition.

I talked to a developer internally and we agree that the placement of the EMPTY_1 partition is not optimal, and I have created an internal task about this. However, practically it should not be an issue. The map file get's its value in a "non-trivial" way as you can see here:

#ifdef LINK_INTO_s1
/* We are linking against S1, create symbol containing the flash ID of S0.
* This is used when writing code operating on the "other" slot.
*/
_image_1_primary_slot_id = PM_S0_ID;

#define ROM_ADDR PM_ADDRESS + PM_S1_ADDRESS - PM_S0_ADDRESS

#else /* ! LINK_INTO_s1 */

(From linker.ld)

Best regards,

Simon