boards: nordic: nrf54h20dk: Allocate 64KB more MRAM to cpurad

[olivier-le-sage]

Allocate more MRAM to cpurad by reducing the size of the cpuapp DFU partition.

This is motivated by the amount of NVM needed for important advanced BLE features on this platform, like channel sounding.

[hubertmis]

How many samples (what percentage) use the advanced Bluetooth features that require more memory?

If the number is relatively low, I would suggest adding device tree overlays in these few samples instead of reducing the app's (or DFU) space in the majority of them. Reducing the default app's space gives a bad first impression for nRF54H20 evaluators, as they see they have little room for their application (or updates).

[olivier-le-sage]

How many samples (what percentage) use the advanced Bluetooth features that require more memory?

If the number is relatively low, I would suggest adding device tree overlays in these few samples instead of reducing the app's (or DFU) space in the majority of them. Reducing the default app's space gives a bad first impression for nRF54H20 evaluators, as they see they have little room for their application (or updates).

I may be misunderstanding, but isn't a 900kB DFU partition already very, very large? To a point that reducing it to ~850kB has little impact?

It's difficult for me to comment on what percentage of 54h20 customers would need this extra space when using BLE since we only really know this at link time, and I don't know all their use cases. But considering that, I would have thought it would be better to allocate a bit too much than too little, since it avoids creating possible pitfalls and a need for complicated device tree manipulation on the user side

[hubertmis]

The DFU partition was temporarily expanded to work around missing DFU features like the update of a single CPU at a time. It is intended to be shrunk back, and the Application's CPU code should utilize the remaining size.

I see that you propose utilizing some of this area for Radio. It would result in a smaller area available for the Application.

The default partition sizes we create in the board files for DKs should be fitting well a 'typical application'. So that if someone evaluates the SoC, they don't need to start repartitioning anytime soon. We already have a few samples and applications that don't fit these default partition sizes, and they repartition in the sample-specific .overlay files.

So, if we have only one sample (channel sounding) that requires more memory in the Radio CPU than allocated by default, I would recommend following the pattern and creating an overlay file for this sample. If creating this overlay starts becoming a rule because multiple samples don't fit in the default memory map, then we should consider changing the default memory map.