Deprecate Partition Manager in Matter - phase 1#28226
Conversation
|
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
CI InformationTo view the history of this post, click the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 8c1a206f7db5f974b3f79a80ee22a4904cfbb2df more detailssdk-nrf:
matter:
Github labels
List of changed files detected by CI (72)Outputs:ToolchainVersion: Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
|
You can find the documentation preview for this PR here. |
8e7dd5a to
7ea874c
Compare
| / { | ||
| chosen { | ||
| nordic,pm-ext-flash = &mx25r64; | ||
| }; | ||
| }; | ||
|
|
There was a problem hiding this comment.
| / { | |
| chosen { | |
| nordic,pm-ext-flash = &mx25r64; | |
| }; | |
| }; |
remove from all
| /* restore full SRAM space - by default some parts are dedicated to FLRP */ | ||
| &cpuapp_sram { | ||
| reg = <0x20000000 DT_SIZE_K(192)>; | ||
| ranges = <0x0 0x20000000 DT_SIZE_K(192)>; | ||
| }; | ||
|
|
There was a problem hiding this comment.
can be dropped since upmerge has this on boards
| reg = <0x0 DT_SIZE_K(1524)>; | ||
|
|
There was a problem hiding this comment.
likewise here, also filename needs to have nrf54l15_cpuapp
| nordic,pm-ext-flash = &mx25r64; | ||
| }; | ||
| }; | ||
|
|
There was a problem hiding this comment.
nrf54l15_cpuapp_ns in filename missing
| /delete-node/ &sram0_s; | ||
| /delete-node/ &sram0_ns; | ||
|
|
||
| &cpuapp_sram { | ||
| reg = <0x20000000 DT_SIZE_K(256)>; | ||
| ranges = <0x0 0x20000000 DT_SIZE_K(256)>; | ||
|
|
||
| sram0_s: image_s@0 { | ||
| #address-cells = <0x1>; | ||
| #size-cells = <0x1>; | ||
| reg = <0x0 DT_SIZE_K(60)>; | ||
| ranges = <0x0 0x0 DT_SIZE_K(60)>; | ||
| }; | ||
|
|
||
| sram0_ns: image_ns@f000 { | ||
| #address-cells = <0x1>; | ||
| #size-cells = <0x1>; | ||
| reg = <0xf000 DT_SIZE_K(196)>; | ||
| ranges = <0x0 0xf000 DT_SIZE_K(196)>; | ||
| }; | ||
| }; |
There was a problem hiding this comment.
this shouldn't be needed either with upmerge
There was a problem hiding this comment.
Should I wait for the upmerge to be finalized, or merge this PR and remove it later?
There was a problem hiding this comment.
I will remove it in the Phase 2. Zephyr upmerge probably will be done until that, so I will be able to remove all of those things.
| * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause | ||
| */ | ||
|
|
||
| #include <samples/matter/nrf5340_cpunet_partitions.dtsi> |
There was a problem hiding this comment.
optionally use a socs file instead of these 2
| * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause | ||
| */ | ||
|
|
||
| #include <samples/matter/nrf52840_partitions.dtsi> |
There was a problem hiding this comment.
don't like the idea of this, @tejlmand for visibility/comment. And ping @kylebonnici whilst it will work in vscode, it means customers are wholly unable to change partition layouts for these
There was a problem hiding this comment.
Wait, @nordicjm do you mean including the .dtsi partition file from that directory? Why is it a bad idea? Actually it is your idea :) you suggested it some time ago, because we could not use target like 'nrf54l15dk/nrf54l15/cpuapp/matter'. Ok, I used different names, and there are no full target name in the file names, however the whole approach of storing dtsi files in the board/matter is your idea and I've just based on that. So what has been changed? If it is not possible to include partitions like this, we cannot convert matter samples to non-PM build, because it is our main requirement (we must share common partitions within the all samples).
There was a problem hiding this comment.
Hmm, for me it works even better than I expected :) I added the "section" partition between "factory data" and "storage_partition" and in the output .overlay file I can see that the storage partition reg was adjusted, and the new section is placed as I wanted:

Also, in the nrf52840_partitions.dtsi file I can see that the reg attribute of the storage partition is now greyed-out, so it means that the new reg from the .overlay is taken.
So what's the problem? For me it works great. Used the recent VSCode extension = 2026.4.1637
There was a problem hiding this comment.
don't like the idea of this, @tejlmand for visibility/comment. And ping @kylebonnici whilst it will work in vscode, it means customers are wholly unable to change partition layouts for these
given file is in the sample editing this file in the visual editor is possible. We only discourage editing files the are part of the SDK
Kindly node that we are working on the visual editor and we have done a lot of improvements. We sent an email for volunteers to use new beta. We recommend you try it out even if partitioning improvements have not yet been completed in full. Your feedback might be even more pertinent given the above.
There was a problem hiding this comment.
@kylebonnici, thanks for the confirmation. So it seems that we can go with a common .dtsi partition file, but we must have an appropriate .overlay file in each sample which includes it. Yeah, it is good idea to test beta version. I will try to do it and provide my feedback. Matter has a quite complex application with factory data and other extra partitions so it can be a good target for testing new extension versions 🙂
@nordicjm Regarding names of the dtsi files. Hmm... I'm not sure if it is good idea to name them using the whole target name like nrf54l15dk_nrf54l15_cpuapp_partitions.dtsi because in fact these partition files may be used as a base by users. I mean if I write there nrf54l15dk it means that it is dedicated to DK, whereas in fact these partition can be used in the final application and then be adjusted in the overlay file (as I did it using vscode). So I think it should be like nrf45l15_partitions.dtsi or nrf54l15_cpuapp_partitions.dtsi, however specifying DK or SoC is redundant for me.
There was a problem hiding this comment.
Taking this one: nrf54l15tag_partitions.dtsi it gives a different meaning, one is named nrf54l15 like it's for all i.e. SoC-based, then this one is a board name, should be uniform hence <board>_<soc>_...
There was a problem hiding this comment.
Hmm, good point, however, now I see, that I can use nrf54l15_internal_partitions.dtsi for tag as well, so I will remove the board-specific.
There was a problem hiding this comment.
given file is in the sample editing this file in the visual editor is possible. We only discourage editing files the are part of the SDK
** correction **
samples/matter/nrf52840_partitions.dtsi will be in the SDK and will not be copied to of tree hence editing this file be discouraged in the GUI. We are look for best solution to such cases
There was a problem hiding this comment.
That's right it must not be editable via gui. As it works now, so devicetree extension sees all those partitions, however if you want to modify something it is added into the .overlay file which is out of tree. And this case is great for me.
5d9423f to
d69ff6f
Compare
e3b659f to
40674b5
Compare
Defined partition map for all targets supported in Matter samples. Signed-off-by: Arkadiusz Balys <arkadiusz.balys@nordicsemi.no>
Added matter.cmake to use image flasher for generating factory data. Aligned CMakeLists.txt with changes in Matter SDK. Signed-off-by: Arkadiusz Balys <arkadiusz.balys@nordicsemi.no>
Refactored Matter Temple sample to non-Partition Manager build. Aligned all images and board files. Signed-off-by: Arkadiusz Balys <arkadiusz.balys@nordicsemi.no>
40674b5 to
8c1a206
Compare
|
@nrfconnect/ncs-co-drivers Could you please review? |
In the phase 1 of PM deprecation in Matter:
upcoming changes:
phase 2: Testing Template sample & Convert all other Matter samples and applications
phase 3: Prepare release notes, migration guide and documentation about the new partitioning.
test_chip: PR-1112