nRF Boards: unify static partition size for Bootloader

[ioannisg]

We would like to unify the size of the statically-configured flash partition for Bootloader across nRF52, nrf53, and nRF91-based platforms.

Currently, nrf52-based platforms allocate 48kB for Bootloader, while nRF53 and nRF91 allocate 64kB. We should stick to configuring 48kB for all platforms. This will bring uniformity across all nRF board definitions that use bootloader solutions.

Note: nRF51 boards definitions allocate 32kB for bootloader partition, but we won't increase this to 48kB due to limited flash availability in these platform.

[ioannisg]

CC @nvlsianpu @oyvindronningstad @carlescufi @mbolivar-nordic

[de-nordic]

Where should the free 16k go?

[mbolivar-nordic]

Seems reasonable; I assume @hakonfam is aware also

[hakonfam]

Note that this will break backwards compatibility if the previous version of the app was built with the old partition size. Maybe it would be an idea to provide overlay files with the old values to simplify the process of creating update candidates.

IMO it is better to keep it as is, as I don't see any clear motivation (other than cosmetics) for this change. The time could rather be spent on educating the customer on optimizing the size of mcuboot to avoid wasting space. The default values proposed are still too big for production.

[ioannisg]

Where should the free 16k go?

It can be given to the next image in chain. For TrustZone-enabled Boards, this would most likely be the Secure Firmware image.

[de-nordic]

It can be given to the next image in chain. For TrustZone-enabled Boards, this would most likely be the Secure Firmware image.

If there will be two non-secure images I will split it between them, as it would look strange to have asymmetric area for each image (you can correct me in review). In secure firmware I will do as you have written.

[nvlsianpu]

I check that the on of the biggest mcuboot configuration (USB CDC-ACM recovery + logging via serial) consumes 62936 B. This is expected that on more constrained SoC we reserve less memory, but on the bigger one - why not have boot partition at 64 KB szie? Especially we can resign form scratch partition at all and use this lived memory (at lease 10 pages per 4K) somewhere else. (slot has to be equally one page bigger that maximal image size, so we can really reuse 8 pages) What bout that @ioannisg?

[ioannisg]

I check that the on of the biggest mcuboot configuration (USB CDC-ACM recovery + logging via serial) consumes 62936 B. This is expected that on more constrained SoC we reserve less memory, but on the bigger one - why not have boot partition at 64 KB szie? Especially we can resign form scratch partition at all and use this lived memory (at lease 10 pages per 4K) somewhere else. (slot has to be equally one page bigger that maximal image size, so we can really reuse 8 pages) What bout that @ioannisg?

I see, thanks for the input. I suppose there is no ideal static flash partitioning that fits all use-cases, @nvlsianpu, there will always be configurations that demand more space. The question, here, is whether we want to have a uniform vanilla-Zephyr size for boot-loader partition, or not.

It's not so much, IMO, about constrained devices; for example nrf5340 and nrf52840 have the same flash size, but the boot-loader partition sizes are different.

So, I see two options here

• one is to unify the partition sizes, using the size required in most common configuration(s)
• have per-SoC specific sizes, but then we should be arguing why these are different among nRF SoCs (i.e. what use-cases we favor most)

[ioannisg]

Especially we can resign form scratch partition at all and use this lived memory (at lease 10 pages per 4K) somewhere else.

If we want to do this, can we do this for all nRF SoCs, @nvlsianpu ?

[nvlsianpu]

@ioannisg #22228

[de-nordic]

So what is the decision on the subject? What do we do with the boot partition size, are we going to move towards unified 64k or 48k? I do not know whether move in with some changes to the PR or close it.

[ioannisg]

I am afraid we need a little bit more input on this. I am worried, now, about the impact of the SPU granularity, see my comment in #22228. I would still want to unify partition sizes as much as it is possible, so please, keep this PR open for now.