Generating pm_static.yml for MCUBoot

nRF Connect SDK v3.2.3, nRF9160.


Hi,

I'm working on a project which has MCUBoot enabled (dual slot) for firmware updates over cellular connection. I did not have a pm_static.yml file created originally, but I noticed this warning during compilation.

	---------------------------------------------------------------------
	--- WARNING: Using a bootloader without pm_static.yml.            ---
	--- There are cases where a deployed product can consist of       ---
	--- multiple images, and only a subset of these images can be     ---
	--- upgraded through a firmware update mechanism. In such cases,  ---
	--- the upgradable images must have partitions that are static    ---
	--- and are matching the partition map used by the bootloader     ---
	--- programmed onto the device.                                   ---
	---------------------------------------------------------------------

I went to the build folder and found the auto generated pm.yml file, then copy-pasted the sections related to flash into my own pm_static.yml file. This appears to work and resolved the build warning. Is there another way to setup the partitions without taking it from a generated file? I'm using the defaults for dual slot MCUBoot, with the addition of NVS at the end of the primary flash.

I can see from an older thread this was suggested.
"You could build normally, with a dynamic partition allocation for the first release, and for future releases use <build_folder>/partitions.yml as your pm_static. "
devzone.nordicsemi.com/.../partition-manager-documentation-of-pm_static-yml-regions

I haven't copied the generated file completely, only the parts related to primary flash. Could I get confirmation that this is a proper setup to define static partitions in the context of dual slot MCUBoot? Also is there anything here which isn't strictly necessary (i.e. partitions, as well as information like spans)? Is there any risk to omitting the SRAM sections?

Thank you


pm_static.yml

EMPTY_0:
address: 0xc000
end_address: 0x10000
placement:
before:
- mcuboot_pad
region: flash_primary
size: 0x4000


app:
address: 0x18000
end_address: 0x80000
region: flash_primary
size: 0x68000


mcuboot:
address: 0x0
end_address: 0xc000
placement:
align:
end: 0x1000
before:
- mcuboot_primary
region: flash_primary
size: 0xc000

mcuboot_pad:
address: 0x10000
end_address: 0x10200
placement:
align:
start: 0x8000
before:
- mcuboot_primary_app
region: flash_primary
size: 0x200

mcuboot_primary:
address: 0x10000
end_address: 0x80000
orig_span: &id001
- tfm
- app
- mcuboot_pad
region: flash_primary
sharers: 0x1
size: 0x70000
span: *id001

mcuboot_primary_app:
address: 0x10200
end_address: 0x80000
orig_span: &id002
- app
- tfm
region: flash_primary
size: 0x6fe00
span: *id002

mcuboot_secondary:
address: 0x80000
end_address: 0xf0000
placement:
after:
- mcuboot_primary
align:
start: 0x8000
region: flash_primary
share_size:
- mcuboot_primary
size: 0x70000


nonsecure_storage:
address: 0xf0000
end_address: 0x100000
orig_span: &id004
- nvs_storage
region: flash_primary
size: 0x10000
span: *id004

nvs_storage:
address: 0xf0000
end_address: 0x100000
inside:
- nonsecure_storage
placement:
align:
start: 0x8000
before:
- end
region: flash_primary
size: 0x10000


tfm:
address: 0x10200
end_address: 0x18000
inside:
- mcuboot_primary_app
placement:
before:
- app
region: flash_primary
size: 0x7e00

tfm_nonsecure:
address: 0x18000
end_address: 0x80000
orig_span: &id008
- app
region: flash_primary
size: 0x68000
span: *id008

tfm_secure:
address: 0x10000
end_address: 0x18000
orig_span: &id009
- mcuboot_pad
- tfm
region: flash_primary
size: 0x8000
span: *id009

MCUBoot config

# Enable MCUMGR
CONFIG_MCUMGR=y

# Enable MCUMGR management for both OS and Images
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_GRP_IMG=y

# MCUBOOT
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_IMG_MANAGER=y
CONFIG_STREAM_FLASH=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y
CONFIG_SECURE_BOOT=y
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n

# Configure dependencies for MCUBOOT
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y

Parents
  • Hi Adamcs, 

    DFU requires a static partition map to avoid dynamically generated partitions from changing between builds. That will cause the DFU update to fail. 

    I went to the build folder and found the auto generated pm.yml file, then copy-pasted the sections related to flash into my own pm_static.yml file. This appears to work and resolved the build warning. Is there another way to setup the partitions without taking it from a generated file?

    You can create your custom static partition, but using the auto-generated pm.yml file is the easy way. 

    I haven't copied the generated file completely, only the parts related to primary flash. Could I get confirmation that this is a proper setup to define static partitions in the context of dual slot MCUBoot? Also is there anything here which isn't strictly necessary (i.e. partitions, as well as information like spans)? Is there any risk to omitting the SRAM sections?

    Your pm_static.yml looks good to me, but it still needs to be verified by your application. 

    Regards,
    Amanda H.

  • Perfect, I'll stick to to the auto-generated method with SRAM removed.

    Your pm_static.yml looks good to me, but it still needs to be verified by your application. 

    Thanks for reviewing the pm_static.yml. I should mention that I have validated the process is working, i.e. flash nrf9160 physically, then download update from AWS and reboot into bootloader, then verify the new image is confirmed working on successful connection.

    will cause the DFU update to fail

    I have a follow up question in terms of what differences will result in DFU to fail. For example, say I reserve space for an empty partition at the end of primary flash. If in the future I decide to use that partition, will device with the original partition layout (empty) be unable to update to the new layout, despite the primary/secondary image slots remaining unchanged?

    Similarly, if I had an empty partition and then added two custom data partitions in place of the empty block, would that break DFU?

    My interpretation is that the start/end/size of the partitions for MCUBoot is what matters most, and any differences which do not change those should be fine (i.e. empty partition -> 2 data partitions).

  • Adamcs said:
    My interpretation is that the start/end/size of the partitions for MCUBoot is what matters most, and any differences which do not change those should be fine (i.e. empty partition -> 2 data partitions).

    That's correct. MCUboot primary and secondary partition sizes and addresses must remain unchanged between firmware versions. If these change, the new firmware's partition map becomes incompatible with the bootloader already on the device. Also, check out the Partition layout doc. 

    Adamcs said:
    empty partition -> 2 data partitions

    If the MCUboot slot boundaries are untouched, DFU should not be affected.

Reply
  • Adamcs said:
    My interpretation is that the start/end/size of the partitions for MCUBoot is what matters most, and any differences which do not change those should be fine (i.e. empty partition -> 2 data partitions).

    That's correct. MCUboot primary and secondary partition sizes and addresses must remain unchanged between firmware versions. If these change, the new firmware's partition map becomes incompatible with the bootloader already on the device. Also, check out the Partition layout doc. 

    Adamcs said:
    empty partition -> 2 data partitions

    If the MCUboot slot boundaries are untouched, DFU should not be affected.

Children
Related