Modifying Region / Partition for Application in NCS

[Akash Patel]

Hi team,

I am working with nRF9160DK on NCS v1.3.2.

I am building the asset_tracker application and from my understanding when running running west build -b nrf9160dk_nrf9160ns, it is building 3 hex files that are subsequently merged: spm, mcuboot, and zephyr (which is the application). 

From the build output, the region size for the application is 441856B (0x6be00). Which file inside the SDK do I need to open to modify this? Let's say I want this to be 524288B (512kB). Where do I set this?

I see that after building a project, inside the build folder, I have partitions_nrf9160dk_nrf9160.yml and pm_nrf9160dk_nrf9160.config which mention 0x6be00 but where is that number being pulled from? Can you help me understand how this partitioning is related to/different from the partitions in zephyr\boards\arm\nrf9160dk_nrf9160\nrf9160dk_nrf9160_partition_conf.dts?

Also, why does the region for the SPM + MCUboot + Application not equal 1MB? What is the rest of the space doing?

Regards,

Akash Patel

[Håkon Alseth]

Hi Akash,

 

 

From the build output, the region size for the application is 441856B (0x6be00). Which file inside the SDK do I need to open to modify this? Let's say I want this to be 524288B (512kB). Where do I set this?

 This is automatically adjusted and partitioned by the component "partition manager", which you can read about here:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html

You can also see in the "build-folder/partitions.yml" how it places each region (flash and RAM wise).

 

What is not shown here is the mcuboot secondary partition. Adjusting the main application would then make the banks un-even, which has a great impact if you want to swap your image in the future.

I see that after building a project, inside the build folder, I have partitions_nrf9160dk_nrf9160.yml and pm_nrf9160dk_nrf9160.config which mention 0x6be00 but where is that number being pulled from? Can you help me understand how this partitioning is related to/different from the partitions in zephyr\boards\arm\nrf9160dk_nrf9160\nrf9160dk_nrf9160_partition_conf.dts?

partitions_$board.yml is the defined partitioning. This will hold all sections, like a "storage" partition if you use a filesystem of sorts, mcuboot slot0 and slot1, any secure/non-secure regions.

You can also map external flash in this area. It will hold each component (or section) that the multibuild has targeted.

 

nrf9160dk_nrf9160_partition_conf.dts gives a default example on flash (with both secure and non-secure slots). On the RAM-side; its a fixed setting if the component(s) are present in the multi-build.

Also, why does the region for the SPM + MCUboot + Application not equal 1MB? What is the rest of the space doing?

 mcuboot has a primary and a secondary slot. The remainder of the flash is used for the secondary slot. If you go into your build folder using a terminal, and write "ninja rom_report", it will show you a simplified layout of the flash. Here's an example from asset_tracker (configured for thingy91):

$ ninja rom_report
[0/18] Performing build step for 'spm_subimage'
ninja: no work to do.
[1/8] Performing build step for 'mcuboot_subimage'
ninja: no work to do.
[4/5] cd /opt/ncs/nrf/applications/asset_tracker/build/modules/nrf && /usr/bin/python3.8...n_manager_report.py --input /opt/ncs/nrf/applications/asset_tracker/build/partitions.yml
 (0x100000 - 1024kB):
+-----------------------------------------+
| 0x0: mcuboot (0xc000)                   |
+---0xc000: mcuboot_primary (0x69000)-----+
| 0xc000: mcuboot_pad (0x200)             |
+---0xc200: mcuboot_primary_app (0x68e00)-+
| 0xc200: spm (0xc000)                    |
| 0x18200: app (0x5ce00)                  |
| 0x75000: mcuboot_secondary (0x69000)    |
| 0xde000: mcuboot_scratch (0x1e000)      |
| 0xfc000: EMPTY_0 (0x2000)               |
| 0xfe000: settings_storage (0x2000)      |
+-----------------------------------------+

MCUboot also uses some sections for handling.

 

Kind regards,

Håkon 

If you remove mcuboot (just build the mqtt_simple sample, and run "ninja rom_report"), you will be left with the secure region (spm) and the non-secure region (mqtt_simple application):

$ ninja rom_report
[0/11] Performing build step for 'spm_subimage'
ninja: no work to do.
[2/3] cd /opt/ncs/nrf/samples/nrf9160/...f9160/mqtt_simple/build/partitions.yml
 (0x100000 - 1024kB):
+-----------------------+
| 0x0: spm (0xc000)     |
| 0xc000: app (0xf4000) |
+-----------------------+

[Akash Patel]

Håkon Alseth said:

You can also see in the "build-folder/partitions.yml" how it places each region (flash and RAM wise).

 

What is not shown here is the mcuboot secondary partition. Adjusting the main application would then make the banks un-even, which has a great impact if you want to swap your image in the future.

partitions.yml is a generated file, i.e. it is not there before I build the project. I am wondering what settings it is using to generate this file. In the Partition Manager documentation, it says "The Partition Manager script reads configuration files named pm.yml, which define flash and RAM partitions." What is the pm.yml file and where is it located?

I want to adjust the main application size to something larger. Where should I modify that parameter? Please provide the exact steps I can take to make the application partition to 512kB (or more) while keeping mcuboot at 0x0 (size 0xc000). If the banks are uneven of if the mcuboot secondary partition is removed as a result, that is acceptable. Essentially, this is the configuration that a customer would need who would like to have the ability to do firmware update even though their application is of size >512 kB. 

Also, what is mcuboot_secondary for? Is that available space to store a second SPM + application after a DFU (dual bank update)?

[Håkon Alseth]

Hi,

  

Akash Patel said:

partitions.yml is a generated file, i.e. it is not there before I build the project. I am wondering what settings it is using to generate this file. In the Partition Manager documentation, it says "The Partition Manager script reads configuration files named pm.yml, which define flash and RAM partitions." What is the pm.yml file and where is it located?

 Based on your board, and configuration, it builds x amount of projects. For the scenario where you have a secure app, non-secure app, and a bootloader; it first splits your regions; then adds each image to a specified offset in RAM and flash.

Since the bootloader is updating a non-secure application, it splits that region into two (close to equal portions).

In addition; any sections that are defined, like "storage", will be placed by the application, so any storing of settings are set to a defined area; in case the overall address delegation scheme does not overlap.

This is all done by the partition manager, based on the initial permissions (ie: if you have secure/non-secure regions etc) in your board; then any empty/unused flash for your device will be allocated towards the application space.

 

 The file itself, partitions.yml / pm.yml is generated when you initially configure your application (ie: cmake .. -DBOARD=$(BOARD) -REST_OF_CONFIG), just like other static configurations, like the overall kconfig file ".config".

By copying this build-folder/partitions.yml file to your application folder, and renaming it to pm_static.yml, you ensure that future upgrades (ncs vX -> ncs vY), follow the exact same flash layout as your initial project. 

Akash Patel said:

I want to adjust the main application size to something larger. Where should I modify that parameter? Please provide the exact steps I can take to make the application partition to 512kB (or more) while keeping mcuboot at 0x0 (size 0xc000). If the banks are uneven of if the mcuboot secondary partition is removed as a result, that is acceptable. Essentially, this is the configuration that a customer would need who would like to have the ability to do firmware update even though their application is of size >512 kB. 

 Unfortunately, the partition manager does not support handling of single slot update, so its not possible at this moment to do this without either omitting mcuboot, or manually building each component by disabling the usage of PM and multi-build, which we do not have any documentation on how to do.

Akash Patel said:

Also, what is mcuboot_secondary for? Is that available space to store a second SPM + application after a DFU (dual bank update)?

 Its the second slot for the application, for dual banking.

 

Kind regards,

Håkon

[Akash Patel]

Hi Håkon,

Thanks for all this information. If there is no application present on the device, only mcuboot, is it possible to use mcuboot to download the application from another MCU that is connected to the device over UART?

Regards,

Akash Patel

[Håkon Alseth]

Hi,

 

Akash Patel said:

Thanks for all this information. If there is no application present on the device, only mcuboot, is it possible to use mcuboot to download the application from another MCU that is connected to the device over UART?

If you have enabled serial in mcuboot, and triggered it; it is theoretically possible that you can update it from any source, as long as the host supports the expected format.

This means that the host controller must implement support for the mcuboot protocol (like "mcumgr" does on the PC-side)

 

I compiled mcuboot (ncs/bootloader/mcuboot/boot/zephyr/), with MCUBOOT_SERIAL=y and UART_CONSOLE=n, for nrf9160dk_nrf9160, and added CONFIG_BOOTLOADER_MCUBOOT=y to at_client, and build this, as a quick test. It updated using "mcumgr":

mcumgr --conntype=serial --connstring='dev=/dev/ttyACM0,baud=115200' image upload -e zephyr/app_update.bin

And ran the at_client + spm, as expected after a reboot.

 

Kind regards,

Håkon