-
Notifications
You must be signed in to change notification settings - Fork 8k
Introduction of board and SoC scheme v2. #50305
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
Changes from all commits
f197e32
8089e59
3d14d31
791486b
65cdf97
75391bf
370502f
1d0f932
392beaf
dbfff1f
e38983f
fcd119d
5b103a3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Copyright (c) 2023 Nordic Semiconductor ASA | ||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
# Note: $ARCH might be a glob pattern | ||
source "$(ARCH_DIR)/$(ARCH)/Kconfig" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Copyright (c) 2023 Nordic Semiconductor ASA | ||
|
||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
source "$(KCONFIG_BINARY_DIR)/arch/Kconfig" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
archs: | ||
- name: arc | ||
path: arc | ||
- name: arm | ||
path: arm | ||
- name: arm64 | ||
path: arm64 | ||
- name: mips | ||
path: mips | ||
- name: nios2 | ||
path: nios2 | ||
- name: posix | ||
path: posix | ||
- name: riscv | ||
path: riscv | ||
- name: sparc | ||
path: sparc | ||
- name: xtensa | ||
path: xtensa | ||
- name: x86 | ||
path: x86 |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Copyright (c) 2022 Nordic Semiconductor ASA | ||
|
||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
choice | ||
prompt "Board Selection" | ||
|
||
source "$(BOARD_DIR)/Kconfig.board" | ||
|
||
endchoice |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,18 @@ | ||
# Copyright (c) 2022 Nordic Semiconductor ASA | ||
|
||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
BOARD_STRING := $(sanitize_upper,$(BOARD)) | ||
BOARD_FULL_STRING := $(sanitize_upper,$(BOARD)$(BOARD_IDENTIFIER)) | ||
|
||
config BOARD_$(BOARD_STRING) | ||
def_bool y | ||
help | ||
Kconfig symbol identifying the board. | ||
|
||
config BOARD_$(BOARD_FULL_STRING) | ||
def_bool y | ||
help | ||
Kconfig symbol identifying the board including full board identifier. | ||
|
||
osource "$(BOARD_DIR)/Kconfig.$(BOARD)" |
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Copyright (c) 2021 Linaro Limited | ||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
config BOARD_MPS3 | ||
select QEMU_TARGET |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
# Copyright (c) 2023 Nordic Semiconductor | ||
# | ||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
config BOARD_MPS3 | ||
select SOC_SERIES_MPS3 | ||
select SOC_MPS3_AN547 |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
board: | ||
name: mps3 | ||
vendor: arm | ||
socs: | ||
- name: 'an547' | ||
variants: | ||
- name: 'ns' |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
# Copyright (c) 2023 Nordic Semiconductor ASA | ||
|
||
# SPDX-License-Identifier: Apache-2.0 | ||
|
||
config BOARD_RZT2M_STARTER_KIT | ||
select SOC_RENESAS_RZT2M |
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
@@ -0,0 +1,3 @@ | ||||
board: | ||||
|
for file in glob.glob(os.path.join(board_root, "*", "*", "*.yaml")): |
I think it would be good to keep the twister platform specifics in its own file (perhaps rename to twister.yaml ?) but clean it up, so that the twister file won't need to contain board specific information as this is now available in a board specific yaml file.
Reason why I dislike having the twister specifics in the board specific file is because rest of build system really shouldn't need to know / parse twister specific content (for example `list_boards.py)
But it's a valid point to address during arch wg.
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.
The fact this is used by twister now does not make it twister specific, this is a board metadata file, used now by twister, but can also be used by the build system if needed. Duplicating the same data does not make sense IMO. We can change twister to depend on and use whatever shared format we come up with and we should stick to one single board metadata file.
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.
The fact this is used by twister now does not make it twister specific, this is a board metadata file,
Looking here: https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/schemas/twister/platform-schema.yaml
I would say that, yes, it does contain some generic information but it also contain some very testing specific pieces, like twister
, and testing
sections.
Not to mention the fact that there are pieces of information duplicated here, like: ram
and flash
, which is not a board specific more a SoC specific information and information we have in dts (and Kconfig).
Notice how the board v2 yml can reference multiple SoCs or variants.
That doesn't fit well with the ram
and flash
information.
So before just merging the information (and i'm very much in favor of reducing duplicated information), then I find it important that we decide if everything should be in one file, or if dedicated files for areas makes things cleaner.
Just like we have some information in dts files, other in Kconfig.
The fact that both files are in yaml doesn't mean there should be one huge yaml file containing everything.
But we should avoid duplicating information, so let's try to discuss our options, and pros / cons.
Duplicating the same data does not make sense IMO.
and there I completely agree.
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.
I would say that, yes, it does contain some generic information but it also contain some very testing specific pieces, like
twister
, andtesting
sections.
and? Still this is data a board can provide to various tooling, including build system or test runners.
Not to mention the fact that there are pieces of information duplicated here, like:
ram
andflash
, which is not a board specific more a SoC specific information and information we have in dts (and Kconfig).
sure, those predate DTS and I would be happy to work on consolidating this and have 1 single source of truth, does not mean we have to leave as is and introduce a new file duplicating the data.
So before just merging the information (and i'm very much in favor of reducing duplicated information), then I find it important that we decide if everything should be in one file, or if dedicated files for areas makes things cleaner.
Just like we have some information in dts files, other in Kconfig.
IMO this should be 1 single file serving all tooling we have in zephyr, including build system and test runners, documentation or whatever...
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.
I propose an intermediate approach, where there would be a single board.yaml
but if the user prefers to split up the non-core info (i.e. twister, testing, etc) into a separate file they can do so by just having an include:
statement in the board.yaml
including the additional file with that non-core info. This means the tooling only ever looks for board.yaml
, but users are free to split it up if they prefer.
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.
@carlescufi dont see much value of splitting and giving user a choice of how to include the data, after all the data need to be defined as part of the overall schema.
This is a metadata file, having a few more keys is not going to have any impact on parsing time or build time. Those keys are not mandatory anyways.
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.
sure, those predate DTS and I would be happy to work on consolidating this and have 1 single source of truth, does not mean we have to leave as is and introduce a new file duplicating the data.
so which information exactly is the new file duplicating ?
It describes the board name, which can be considered somewhat similar to the twister
identifier, but the twister identifier field is already a duplication of today's board name obtained from the _defconfig
file.
Any of the revision, soc, cpucluster, variant information is not existing in today's yaml file. Those are new fields.
So that leave only vendor
to be duplication (arch field should be removed as per arch wg meeting)
sure, those predate DTS and I would be happy to work on consolidating this and have 1 single source of truth, does not mean we have to leave as is and introduce a new file duplicating the data.
So then let's take a look at what information in existing file / twister can be consolidated and how we want to combine that information.
Today, a board like nrf5340dk has 3 twister / test yaml files:
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp.yaml
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_ns.yaml
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/nrf5340dk_nrf5340/nrf5340dk_nrf5340_cpuapp_ns.yaml
where the differences are related to ram, flash, supported fields.
I would prefer that consolidating those files first and see what can be obtained from dts instead of describing it again here. Although my understanding of having this information duplicated was to avoid running dts, and instead being able to do twister filtering before deciding to run dts.
If trying to both consolidating HWMv2 with twister yaml, and on top adjusting twister to obtain more from dts, then that blows the HWMv2 PR and jeopardizes the work.
Instead I propose to work on HWMv2, get that designed and approved. Once we have that in place, then while migrating SoCs and boards, parallel work can be done on consolidating the yaml files and update twister.
Sure that will require some files to be updated after board has been migrated to HWMv2, but as the existing yaml file is mostly a rename, then there is no difference in consolidating those files during or after transitioning to HWMv2.
My proposal is:
- Continue with HWMv2, having a dedicate file with the new fields required, as that already consolidates separate revision files, board soc / cluster / arch files spanning multiple folder, and thus reduces number of files required to describe boards with multiple SoCs / multi-core socs.
- In parallel, start consolidating existing yaml files used by twister, so that three files are not needed to describe a single board. See which information is redundant and can be obtained from dts.
When this work is done, merge board meta data files so only a single file is needed.
IMO this should be 1 single file serving all tooling we have in zephyr, including build system and test runners, documentation or whatever...
I would like to see the outcome first.
Wisely named files with clear content and just 10-20 lines can be easier to read and understand than a single file spanning 100 lines with information that has little in common.
So while I do agree on the principle of a single file being an advantage, I like to see the actual look, cause I have seen to many times that such know-it-all files can become messy.
So could we agree to have such work in parallel to the new hw model ?
Nothing in HWMv2 blocks extending the HWMv2 yaml description at a later time.
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.
so which information exactly is the new file duplicating ?
It describes the board name, which can be considered somewhat similar to thetwister
identifier, but the twister identifier field is already a duplication of today's board name obtained from the_defconfig
file.
you will always need something to get a reference, consider this a foreign key. Right now it does duplicate vendor, arch, but my point is that we are ending up with TWO board meta data files and that does not make sense.
If trying to both consolidating HWMv2 with twister yaml, and on top adjusting twister to obtain more from dts, then that blows the HWMv2 PR and jeopardizes the work.
I do not understand why you think this will be the case, getting data from DTS and other activities have nothing with this PR and completely orthogonal. We can attempt to define a board meta data syntax that serves everyone and you can just ignore the testing related parts in the build system etc.
We can transition step by step to the unified metadata file and I am fine with that, but we need to agree that we want to end up with 1 single board metadata file and consolidate the information in one place and avoid duplication now and in the future.
The new data related to SoCs and other things coming with this proposal are essential and needed for testing, something we desperatly needed for a long time and having all of this in one place would help with optimizing testing and improving test coverage.
My proposal is:
- Continue with HWMv2, having a dedicate file with the new fields required, as that already consolidates separate revision files, board soc / cluster / arch files spanning multiple folder, and thus reduces number of files required to describe boards with multiple SoCs / multi-core socs.
- In parallel, start consolidating existing yaml files used by twister, so that three files are not needed to describe a single board. See which information is redundant and can be obtained from dts.
When this work is done, merge board meta data files so only a single file is needed.IMO this should be 1 single file serving all tooling we have in zephyr, including build system and test runners, documentation or whatever...
I would like to see the outcome first. Wisely named files with clear content and just 10-20 lines can be easier to read and understand than a single file spanning 100 lines with information that has little in common.
So while I do agree on the principle of a single file being an advantage, I like to see the actual look, cause I have seen to many times that such know-it-all files can become messy.
So could we agree to have such work in parallel to the new hw model ? Nothing in HWMv2 blocks extending the HWMv2 yaml description at a later time.
yes, I am fine with that.
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.
sounds like we have a plan 👍
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,41 @@ | ||
# SPDX-License-Identifier: Apache-2.0 | ||
# | ||
# Copyright (c) 2023, Nordic Semiconductor ASA | ||
|
||
# | ||
# Configure ARCH settings based on KConfig settings and arch root. | ||
# | ||
# This CMake module will set the following variables in the build system based | ||
# on board directory and arch root. | ||
# | ||
# If no implementation is available for the current arch an error will be raised. | ||
# | ||
# Outcome: | ||
# The following variables will be defined when this CMake module completes: | ||
# | ||
# - ARCH: Name of the arch in use. | ||
# - ARCH_DIR: Directory containing the arch implementation. | ||
# - ARCH_ROOT: ARCH_ROOT with ZEPHYR_BASE appended | ||
# | ||
# Variable dependencies: | ||
# - ARCH_ROOT: CMake list of arch roots containing arch implementations | ||
# | ||
# Variables set by this module and not mentioned above are considered internal | ||
# use only and may be removed, renamed, or re-purposed without prior notice. | ||
|
||
include_guard(GLOBAL) | ||
|
||
if(HWMv2) | ||
# HWMv2 obtains arch from Kconfig for the given Board / SoC variant because | ||
# the Board / SoC path is no longer sufficient for determine the arch | ||
# (read: multi-core and multi-arch SoC). | ||
set(ARCH ${CONFIG_ARCH}) | ||
string(TOUPPER "${ARCH}" arch_upper) | ||
cmake_path(GET ARCH_V2_${arch_upper}_DIR PARENT_PATH ARCH_DIR) | ||
|
||
if(NOT ARCH_DIR) | ||
message(FATAL_ERROR "Could not find ARCH=${ARCH} for BOARD=${BOARD}, \ | ||
please check your installation. ARCH roots searched: \n\ | ||
${ARCH_ROOT}") | ||
endif() | ||
endif() |
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.
a suggestion here: why don't we re-use
vendor-prefixes.txt
(from dt-bindings), and guess the vendor name based on board location? I feel like this field is a bit redundant. So to summarize, boards/v2/$vendor_prefix/$board_name, if you want to obtain $vendor_name, just query vendor-prefixes.txtThere 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.
(not necessary to re-use vendor-prefixes, as there are many board vendors that do not produce the actual socs, but share the idea, ie, a database of prefixes/names)
Uh oh!
There was an error while loading. Please reload this page.
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.
are all vendors of boards having an entry there ?
if a vendor just creates a hw variant of an upstream board there may not need to be any reason for extra vendor prefixes.
For example:
bbc_microbit
doesn't seem to have an entry in vendor prefixes.no guessing / extraction of info from folder structure, it doesn't scale.
Although we intend to structure under vendor, the model itself has no such requirement and oot users with custom board may not see a reason for a vendor folder, as all boards in their board root is their own.
The idea with model v2 is exactly to not enforce a given structure.
Note, i'm very much in favor of guidelines on board structure for zephyr repo.
There is some discussion on this in beginning of this PR.
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.
seems you noticed the same while I was writing my answer.
With the flexibility of organizing boards in new model, what would be the purpose / benefit of such file / db ?
If for build system / ci / twister, then we could extend
list_board.py
to easily produce such file for re-use between tests and thereby reduce overhead.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.
I'd make
vendor
a vendor prefix, checked against a database file. Reasons include: avoid typos, obtain readable name from a single source, 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.
I think this would make sense as an enhancement followup.