nRF9160: where does the flash partitions address are been picked?

[kk2mkk]

Hi,

I just enabled the CONFIG_BOOTLOADER_MCUBOOT=y for serial LTE modem application to understand the flash partitions and to perform the serial DFU(not sure if its really supported), but i was confused seeing the rom_report, the build system disregarded the partition addresses defined in the DTS files and overwritten with different start address and sizes, could you help me understand where there partition defined?

i refereed the following documentation but couldn't get the answer.

http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html

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

regards

KK

[Øyvind]

Hello KK, 

What version of NCS are you using? Have you added a pm.yml or pm_static to your project? 

Information about MCUboot can be found here. There are also given DFU images that must be built, see more information here. Several of our samples have CONFIG_BOOTLOADER_MCUBOOT enabled, e.g the HTTP Application Update sample.

Kind regards,
Øyvind

[kk2mkk]

Hi Øyvind,

yesterday i was bust in other activities could not respond.

Øyvind said:

What version of NCS are you using? Have you added a pm.yml or pm_static to your project? 

I am on master branch as serial LTE modem is my main point of interest and its under development.

No i dont have any pm.yml in added to to the SLM project does its required? even the HTTP Application Update sample dint have either. What is the default partition configuration is picked up by the build subsystem?

I  just added few CONFIG entries to prj.conf rest all unchanged from SLM application.

# Image manager
CONFIG_IMG_MANAGER=y
CONFIG_FLASH=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

# DFU Target
CONFIG_DFU_TARGET=y

# Application Upgrade support
CONFIG_BOOTLOADER_MCUBOOT=y

And I also see there is lot of disconnects in documentation i dont find "subsys\bootloader\dts" layout described in the page http://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.3.1/nrf/ug_bootloader.html#upgradable-bootloader

Can you point me to any samples which performs boot loader, application and modem upgraded over serial?

regards

KK

[Øyvind]

Hi KK, 

My sincere apologies for the late reply, I have been working to find an answer. 

kk2mkk said:

No i dont have any pm.yml in added to to the SLM project does its required? even the HTTP Application Update sample dint have either. What is the default partition configuration is picked up by the build subsystem?

No, pm.yml is not required, but if you had one that would configure the partition. By default the partition is configured depending on what you inlude in your project. Adding a pm_static.yml or pm.yml will manually configure the partitions for you, and is more advanced. 

Adding B0 (Immutable bootloader) + MCUboot (upgradeble bootloader) in your project will dynamically configure the partition for you, and ensure that it is working. These are added when setting CONFIG_BOOTLOADER_MCUBOOT and CONFIG_SECURE_BOOT, as according to the Secure Bootloader chain documentation.

Our developer adds:

So when you include the bootloader(b0) https://github.com/nrfconnect/sdk-nrf/blob/master/samples/bootloader/pm.yml this pm.yml is added to the dynamic resolving of partitions and this one https://github.com/nrfconnect/sdk-nrf/blob/master/samples/spm/pm.yml is for spm. Here is a few different configurations which also add ram partitioning depending on what's included https://github.com/nrfconnect/sdk-nrf/tree/master/subsys/partition_manager and in this is for MCUBoot https://github.com/nrfconnect/sdk-mcuboot/blob/master/boot/zephyr/pm.yml

As you can see some of the sizes are possible to configure by Kconfig but I would suggest using the defaults as they are optimised for the size of flash being locked. If they don't use flash locking they are free to change it as they please as long as it is big enough to fit the whole image(firmware being built(b0, mcuboot, spm) etc in each respective partition.

Flash locking is recommended from a security/safety standpoint.

For the HTTP Application update sample, which has only CONFIG_BOOTLOADER_MCUBOOT set, you will not be able to update mcuboot since b0 is not included. Adding CONFIG_SECURE_BOOT will enable b0 and create s0 and s1 for mcuboot. So that you use s0/s1 for switching between mcuboot upgrades and secondary slot vs primary in mcuboot for the application.

See the Immutable Bootloader sample for more information. 

Kind regards,

Øyvind

[kk2mkk]

Hi Øyvind,

Thanks for the detailed information, i have figured out some answers meanwhile, but your explanation gave me full overview of memory partitioning.

One last question, if i dont use CONFIG_SECURE_BOOT, is it the case that i cant have a secure boot mechanism or mcuboot can also provide the immutable boot functionality? Yes i agree that MCUBoot can't be upgraded, but on the other hand i am also wondering what could be the circumstances where i may need the bootloader upgrade in field....

regards

KK

[Øyvind]

Hi KK, 

The CONFIG_SECURE_BOOT enables bootloader stage, and is a bad name as it's not really a security function. MCUboot does also provide the immutable bootloader functionality. 

Lately there are PRs added to MCUboot to fix certain scenarios where devices have bricked. This is also a good reason to have a upgradable bootloader. 

Have a look at Arm's secure boot documentation here.

Kind regards,
Øyvind

[kk2mkk]

Thanks Øyvind

Øyvind said:

Lately there are PRs added to MCUboot to fix certain scenarios where devices have bricked. This is also a good reason to have a upgradable bootloader. 

It would be great if Nordic can add an example which depicts the procedure to perform MCUBoot upgrade.

regards

kk