-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add nrf52840dk/nrf52840/matter board variant and configuration #25646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
CI InformationTo view the history of this post, click the 'edited' button above Inputs:Sources:sdk-nrf: PR head: d0d5d0758e1e2db0e17838e664669291578463e9 more detailssdk-nrf:
matter:
Github labels
List of changed files detected by CI (217)Outputs:ToolchainVersion: f911d4f4e7 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
|
What is the story behind this PR? Do we need a new board target in order to stop using PM in the future? And why is it only for nRF52840? |
|
Suggest to have nrf54l15 or nrf54lm20a if you want to check if the changes affect sample within the Jenkins Integration plan (due to you resource constraints, on-target tests are limited to nrf54lm20dk, nrf54l15dk and nrf7002dk platforms) |
This should have been opened as draft with just @rghaddab added but I opened it as ready for review by mistake. It shows an initial port for the nrf52840 only, it doesn't work because of 2 matter bugs (referenced above) which include non-existent SUIT/PM things |
fdcfe40 to
f4ba2c5
Compare
|
The following west manifest projects have changed revision in this Pull Request:
⛔ DNM label due to: 1 project with PR revision Note: This message is automatically posted and updated by the Manifest GitHub Action. |
f4ba2c5 to
3b780a5
Compare
3b780a5 to
345b027
Compare
345b027 to
627a0ad
Compare
8fb06c1 to
348b2bb
Compare
39e18bc to
9147963
Compare
Memory footprint analysis revealed the following potential issuesapplications.hpf.gpio.icbmsg[nrf54l15dk/nrf54l15/cpuflpr]: High RAM usage: 12744[B] - link (cc: @nrfconnect/ncs-ll-ursus) Note: This message is automatically posted and updated by the CI (latest/sdk-nrf/PR-25646/63) |
sysbuild/Kconfig.matter
Outdated
| Enables merging the generated factory data with the merged.hex output build file. As a | ||
| result, the merged.hex build output file, which is used when flashing the firmware using | ||
| the west tool, includes the factory data as well. | ||
| #config MATTER_FACTORY_DATA_MERGE_WITH_FIRMWARE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We must have this option.
|
|
||
| # Do not apply shield or snippets for the factory data partition and use an empty file for the | ||
| # board defconfig file | ||
| set(BOARD_DEFCONFIG ${CMAKE_CURRENT_SOURCE_DIR}/prj.conf) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach makes no sense. There are only weird hacks and overrides for the process that relies only on CMAKE.
I don't see any advantage in creating a separate image for factory data. This only creates many redundant files in the build directory.
Instead align this PR to this approach: #26394
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach makes no sense. There are only weird hacks and overrides for the process that relies only on CMAKE.
You're not a build system maintainer, these are not hacks.
I don't see any advantage in creating a separate image for factory data. This only creates many redundant files in the build directory.
Instead align this PR to this approach: #26394
This is the approach and this is how it is going to be done, just like it is for other images and other systems e.g. in zephyr, in bare metal, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're not a build system maintainer, these are not hacks.
Similarly, it's not within your scope to decide how Matter factory data should work, as you're not the Matter maintainer. This solution was only mentioned but never consulted with us.
This is the approach and this is how it is going to be done, just like it is for other images and other systems e.g. in zephyr, in bare metal, etc.
Can you point me to where this was decided and by whom? I'm curious why I wasn't consulted on this.
Fixes an invalid path to a source file Signed-off-by: Jamie McCrae <[email protected]>
Includes changes for partition removal Signed-off-by: Jamie McCrae <[email protected]>
This adds an image which sysbuild can add which simply flashes a hex file Signed-off-by: Jamie McCrae <[email protected]>
Adds dtsi files which can be included and set the partition layout up for the matter samples Signed-off-by: Jamie McCrae <[email protected]>
Includes nrf52840dk, nrf54l15dk (secure only) and nrf54lm20dk Signed-off-by: Jamie McCrae <[email protected]>
We need to use the new CONFIG_CHIP_APP_ZAP_DIR to set the proper path to the custom zap-generated directory in Matter stack. Signed-off-by: Arkadiusz Balys <[email protected]>
TF-M is currently not supported without partition manager, do not force disabling PM if a non-secure board target is used in samples that build for these Signed-off-by: Jamie McCrae <[email protected]>
fb701f7 to
761e400
Compare
Allows generating and flashing the nrf70 firmware in applications which do not use partition manager, and will be flashed when west flash is invoked Signed-off-by: Jamie McCrae <[email protected]>
761e400 to
d0d5d07
Compare
|
You can find the documentation preview for this PR here. |
Includes configuration for matter samples also
Blocked by NCSDK-36367 and NCSDK-36368