Partition size considerations for compatibility with future SDK version

[puz_md]

Hi, I want to create a partition setup (for the nRF5340) which I can use with future versions of the nRF Connect SDK, which means future versions of mcuboot and b0n. If we produce PCB's in the future with a new version of mcuboot and/or b0n, the APP core and NET core binaries of new software releases shall be able to run on new systems as well as old systems with outdated mcuboot and/or b0n. Further, we plan to add OTA update features to future software versions, in a way that we can update our devices in the field later via wire and add OTA functionality to them.

Currently, the build system (SDK & toolchain v2.5.3) creates the following partition manager configuration, which I use as basis for my pm_static.yml:

• Should I increase the sizes for b0n and/or mcuboot? How to optimize b0n partition size vs. hci_rpmsg partition size?
• What is this procision partition next to b0n (within a b0n page?!) Is the size large enough for future extensions?

By the way, the hci_rpmsg section is pretty full aalready (>80%). I hope there is enough space left for future SDK versions and small extensions I plan to implement within the NET core.

One more question concerning the NET core: I read somewhere in the mcuboot documentation that the NET core must be updated when the Bluetooth configuration changes. Does this mean the NET core binary is affected by me characteristic and service definitions in the APP core's implementation?

Best regards,
Michael

[Amanda Hsieh]

Hi, 

Since your app core only has mcuboot without b0, mcuboot cannot be updated. The b0n is on the netcore, and b0n cannot be updated. So in your figures, the mcuboot and b0n are theImmutable first-stage bootloaders that cannot be upgraded through device firmware update (DFU) and run after each reset. Therefore, the partition of mcuboot and b0n will not be changed.  

-Amanda H.

[puz_md]

Hi Amanda,

I think there was a little misunderstanding. I know that mcuboot and b0n cannot be updated on deployed systems. But let us assume that in two years, a new NCS version is available with new mcuboot and new b0n. And we want to produce new hardware with the new mcuboot and/or b0n. In this case, when we want our firmware still to be compatible with old hardware (which have old mcuboot and old b0n). the memory mapping for both new and old hardware must be the same. (same pm_static.yml.)

So, what I am asking is: How much memory should I reserve for mcuboot to be on the safe side for future hardware versions. And - which probably is more critical - how should I distribute the memory between b0n and hci_rpmsg (and provisioning) on the network core, which has less unused space available?

Again: I know that I cannot update existing hardware. But I want to be flexible with new hardware in the future, while keeping application compatibility between all hardware versions.

Best regards,
Michael

[Amanda Hsieh]

Hi, 

It's hard for us to say how much MCUboot will change in the future. Since we are not the owners of MCUboot, we have no idea about their plan. 

You do not have ever to change MCUboot and b0n. A customer who flashed their device with MCUboot from v1.7.0 should still be able to DFU the APP with v2.7.0 with no problem, and this is not expected to change. From our side, I would say: Not much. Maybe you have 10% extra space and it should be good to update to eventual bug fixes. 

-Amanda H.

[puz_md]

Thanks, Amanda!

I'll do it this way. I'm going to increase the b0n partition by 0x800 so that I reach the next 4k boundary (I know that the NET core has 2k pages). Also, I'm thinking about adding 0x80 to the provision partition in case it grows a bit larger in the future. For the APP core, it is a bit easier as there is enough flash available.

Best regards,
Michael