[nrf fromlist] Support SoC and board extensions #1794
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NordicBuilder
requested review from
carlescufi,
gmarull,
jfischer-no,
nordicjm,
stephanosio and
tejlmand
57300
force-pushed
the
board-extensions
branch
2 times, most recently
from
b63f342 to
27d83a6
Compare
Handling of board changes was broken and did not support v2 boards, fix this to optimize CI execution on localized changes of board files. Signed-off-by: Anas Nashif <[email protected]> (cherry picked from commit 94b9790)
…when !XIP
Many boards/SoCs in-tree do this:
if !XIP
config FLASH_SIZE
default 0
config FLASH_BASE_ADDRESS
default 0
endif
And many other boards are missing this configuration (e.g. stm32 series).
Making this the default helps get non-XIP just working
Signed-off-by: Grant Ramsay <[email protected]>
(cherry picked from commit c5642a7)
Move the GitHub runners currently on macos-11 to macos-14 as the former is no longer supported by GitHub. Signed-off-by: Henrik Brix Andersen <[email protected]> (cherry picked from commit fa4537d)
…ch in modules Fixes #71761 The `west boards` command parses extra BOARD_ROOTs from Zephyr modules, so that the boards defined in those modules are automatically listed. In HWMv2, OOT boards can be described in terms of OOT SoCs, which means that extra SOC_ROOTs must also be provided. Otherwise, an error message will be displayed when attempting to list all boards. Therefore, every Zephyr module SOC_ROOT should be included as well. In HWMv1 (deprecated), OOT boards can be defined in terms of OOT archs, but module ARCH_ROOTs had never been included automatically. The fix for this is long overdue, but it's included for symmetry. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit 7a10c7d)
…runner configs
When validating the flash runner configurations in `soc.yml`, the only
SoCs that were considered had to be defined under this structure:
family:
- series:
- socs:
- name: ...
However, the `family` and `series` keys are optional, so the `soc.yml`
files can also be arranged like this:
family:
- socs:
- name: ...
series:
- socs:
- name: ...
socs:
- name: ...
The solution is to move the validation code further down, so that it can
reuse the SoC data that was already correctly parsed while initializing
a `Systems` instance.
Signed-off-by: Grzegorz Swiderski <[email protected]>
(cherry picked from commit 9b68230)
Upstream PR: zephyrproject-rtos/zephyr#72857 Cleanup the Kconfig generating code in hwm_v2.cmake by moving common logic inside the kconfig_gen() helper function. This prepares the code for board extension feature. Signed-off-by: Torsten Rasmussen <[email protected]> (cherry picked from commit d39cc46b56294b6eb297a67478334c23db8c8ca3)
This automated patch is inserted before a cherry-pick of: ad16407 cmake: scripts: support board extension This allows the above commit to be applied cleanly, even though it appears to conflict with the following commit(s): ec3b301 [nrf fromlist] scripts: support soc/boards in Zephyr modules The conflicts are left to be fixed in a follow-up patch, instead of doing so in the cherry-pick itself. Signed-off-by: Grzegorz Swiderski <[email protected]>
Upstream PR: zephyrproject-rtos/zephyr#72857 Fixes: #69548 Support extending an existing board with new board variants. This commit introduces the following changes to allow a board to be extended out-of-tree. The board yaml schema is extended to support an extend field which will be used to identify the board to be extended. A board 'plank' can be extended like this: > board: > extend: plank > variants: > - name: ext > qualifier: soc1 For the rest of the build system this means that there is no longer a single board directory. The existing CMake variable BOARD_DIR is kept and reference the directory which defines the board. A new CMake variable BOARD_DIRECTORIES provides a list of all directories which defines board targets for the board. This means the directory which defines the board as well as all directories that extends the board. Signed-off-by: Torsten Rasmussen <[email protected]> (cherry picked from commit ad16407aca8ccde1aaa57d4d1dcb15bb4d0bfc25)
This patch finalizes the 3-way merge between: ad16407 cmake: scripts: support board extension and: ec3b301 [nrf fromlist] scripts: support soc/boards in Zephyr modules Signed-off-by: Grzegorz Swiderski <[email protected]>
Upstream PR: zephyrproject-rtos/zephyr#72857 Fixes: #72374 Support extending an existing SoC with new CPU clusters. This commit introduces the following changes to allow an SoC to be extended out-of-tree. The SoC yaml schema is extended to support an extend field which will be used to identify the SoC to be extended with extra CPU clusters. A SoC 'a_soc' can be extended like this: > socs: > extend: a_soc > cpuclusters: > - name: extra_core Signed-off-by: Torsten Rasmussen <[email protected]> (cherry picked from commit c602935faf814c161ea78d19e5a858f7022978c2)
…sion Upstream PR: zephyrproject-rtos/zephyr#72857 This commit adds new tests for verifying the functionality of the board and SoC extension feature. It does so by defining: - A new CPU cluster on an existing SoC - Two new board variants on top of an existing board The new board variants are defined on top of the existing `native_sim` board, so that the following native_sim board targets are available for the test. Existing board targets: - native_sim/native - native_sim/native/64 Extended board targets: - native_sim/native/one - native_sim/native/64/two The new CPU cluster is defined for the existing `an521` SoC. Existing CPU Clusters on an521: - cpu0 - cpu1 New CPU Cluster: - cputest For SoC tests the mps2 board is used. This means that for testing, the following board targets using the an521 SoC are: - mps2/an521/cpu0 - mps2/an521/cpu1 - mps2/an521/cputest Signed-off-by: Torsten Rasmussen <[email protected]> (cherry picked from commit 04dda379d7ea202712c68aba60b473cd4b5774ef)
…config Upstream PR: zephyrproject-rtos/zephyr#72857 Adds an optional priority parameter to the flash runner run once configuration which allows for deciding upon which file should ultimately be used Signed-off-by: Jamie McCrae <[email protected]> (cherry picked from commit 88a4c4ecf6906c7b66e6f42402f1f3e22456ff05)
…n once config Upstream PR: zephyrproject-rtos/zephyr#72857 Removes validating the qualifiers for flash run once configuration as files may be present that contain information for qualifiers that are not present in a single repository but are spaced out in other repositories, or might be optional Signed-off-by: Jamie McCrae <[email protected]> (cherry picked from commit b72acf47e550090878fa87145c9766504c3deb13)
…n dts.cmake Upstream PR: zephyrproject-rtos/zephyr#73903 Instead of hardcoding the name `devicetree_target`, we can update the generated `dts.cmake` to accept `DEVICETREE_TARGET` as input variable. This will become useful in multi-image builds, where we would like to process multiple devicetrees. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit cd187c719ae9162a2ab6bd6aeff511a4cc684bdc)
Upstream PR: zephyrproject-rtos/zephyr#73903 Add new functions to `sysbuild_extensions.cmake`, which will mirror the familiar dt_* API from Zephyr `extensions.cmake`. For example: dt_nodelabel(<var> NODELABEL <label>) gets the following sysbuild counterpart, with one extra argument: sysbuild_dt_nodelabel(<var> IMAGE <image> NODELABEL <label>) This API allows sysbuild to retrieve devicetree information for a given <image>, only after its respective `ExternalZephyrProject_Cmake()` call. This works by importing the generated `dts.cmake` files from each image's build directory, and creating multiple CMake targets to hold the generated properties - much like how the `CMakeCache.txt` and `.config` are also imported to be used by the related `sysbuild_get()` function. The dt_* API itself also has to be updated, in order to read properties from a variable `DEVICETREE_TARGET` set in the parent scope. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit 3bf9a41a20ae52adc3ccadc2ff79425160f8ad73)
Upstream PR: zephyrproject-rtos/zephyr#74316 Taking a cue from `nrfx/templates`, introduce this file so that it can be overridden out-of-tree to add external nRF product definitions. Signed-off-by: Grzegorz Swiderski <[email protected]> (cherry picked from commit 6ee6468dc7f7a1391d1961e696bbc671ae350c2f)
…ets root" This reverts commit 3a41bb5. NCS snippet root should have been set in `zephyr/module.yml`. Signed-off-by: Grzegorz Swiderski <[email protected]>
jonathannilsen
approved these changes
Jul 16, 2024
sigvartmh
approved these changes
Jul 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.