NCSDK-32650: Revert incompatible memory changes

[tomchy]

Due to compatibility reasons, we should either revert those or provide a clear and tested way to migrate between the v2.9.0-nRF54H20-1 and v3.0.0.

[hubertmis]

This is a board configuration - it is application-specific. This configuration is used in samples running on the DK. It's not used in the product PCBs. Is there any reason to maintain compatibility between application-specific configurations for development kits?

[tomchy]

This is a board configuration - it is application-specific. This configuration is used in samples running on the DK. It's not used in the product PCBs. Is there any reason to maintain compatibility between application-specific configurations for development kits?

If we make a board-level change, than it is applied to all of the applications, including those who partition only the MRAM part of the memory. After this change any application that wishes to be compatible (or updateable through DFU) must add an overlay, aligning memory regions. If missed, it will end up in a bus fault.

At this point, it might be easier to revert those changes than handle all of the support tickets, complaining about a failed NCS migration attempt.

The issue was raised by @MarekPieta and discussed with @maciejpietras, so if you want to discuss this change further, please schedule a meeting.

[hubertmis]

I'm confused. Is there a requirement to be able to update a sample on nRF54H20-DK from NCS 2.9 to 3.0 with DFU? On the development kit, you can update with JLink to be compatible with the new memory map.

Not to mention that 2.9 -> 3.0 is a major version change, so I'm not sure if we intend to make it DFU-able between them. There are more breaking changes than memory maps for Development Kits.

[maciejpietras]

I'm confused. Is there a requirement to be able to update a sample on nRF54H20-DK from NCS 2.9 to 3.0 with DFU? On the development kit, you can update with JLink to be compatible with the new memory map.

Not to mention that 2.9 -> 3.0 is a major version change, so I'm not sure if we intend to make it DFU-able between them. There are more breaking changes than memory maps for Development Kits.

We don't want to make customer life's even harder therefore I proposed to revert this change. This change was mainly triggered by Matter which is not available on H20. Release NCS 3.0 will be the last one in this configuration and starting with NCS 3.1 I anticipate more significant changes therefore this will be good opportunity to modify memory maps then.

[hubertmis]

This change was mainly triggered by Matter which is not available on H20

This bug was found by Matter, but it applies to all applications. Especially those with bigger memory footprint in the Application CPU

[hubertmis]

Discussed offline. For nRF54H20 there will be broken NCS compatibility between NCS versions 3.0 and 3.1. So it's better to revert this change now and reintroduce between 3.0 and 3.1

[nordicjm]

upstream reverts should go upstream

[tomchy]

upstream reverts should go upstream

Upstream PR: zephyrproject-rtos/zephyr#88121

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud