Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions Kconfig.zephyr
Original file line number Diff line number Diff line change
Expand Up @@ -21,12 +21,11 @@ osource "$(KCONFIG_BINARY_DIR)/Kconfig.shield.defconfig"
# This loads Zephyr base shield defconfigs
source "boards/shields/*/Kconfig.defconfig"

source "$(BOARD_DIR)/Kconfig.defconfig"
osource "$(BOARD_DIR)/Kconfig.defconfig"

# This loads Zephyr specific SoC root defconfigs
source "$(KCONFIG_BINARY_DIR)/soc/Kconfig.defconfig"

# This loads custom SoC root defconfigs
osource "$(KCONFIG_BINARY_DIR)/Kconfig.soc.defconfig"
# This loads Zephyr base SoC root defconfigs
osource "soc/$(ARCH)/*/Kconfig.defconfig"
# This loads the toolchain defconfigs
osource "$(TOOLCHAIN_KCONFIG_DIR)/Kconfig.defconfig"
# This loads the testsuite defconfig
Expand Down
2 changes: 1 addition & 1 deletion MAINTAINERS.yml
Original file line number Diff line number Diff line change
Expand Up @@ -418,7 +418,7 @@ Board/SoC configuration:
- nordicjm
- "57300"
files:
- soc/Kconfig
- soc/Kconfig*
- boards/Kconfig
labels:
- "area: Board/SoC configuration"
Expand Down
27 changes: 4 additions & 23 deletions arch/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,10 @@
# Include these first so that any properties (e.g. defaults) below can be
# overridden (by defining symbols in multiple locations)

# Note: $ARCH might be a glob pattern
source "$(ARCH_DIR)/$(ARCH)/Kconfig"
source "$(ARCH_DIR)/Kconfig.$(HWM_SCHEME)"

# ToDo: Generate a Kconfig.arch for loading of additional arch in HWMv2.
osource "$(KCONFIG_BINARY_DIR)/Kconfig.arch"

# Architecture symbols
#
Expand Down Expand Up @@ -979,27 +981,6 @@ config ARCH
help
System architecture string.

config SOC
string
help
SoC name which can be found under soc/<arch>/<soc name>.
This option holds the directory name used by the build system to locate
the correct linker and header files for the SoC.

config SOC_SERIES
string
help
SoC series name which can be found under soc/<arch>/<family>/<series>.
This option holds the directory name used by the build system to locate
the correct linker and header files.

config SOC_FAMILY
string
help
SoC family name which can be found under soc/<arch>/<family>.
This option holds the directory name used by the build system to locate
the correct linker and header files.

config TOOLCHAIN_HAS_BUILTIN_FFS
bool
default y if !(64BIT && RISCV)
Expand Down
5 changes: 5 additions & 0 deletions arch/Kconfig.v1
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"
5 changes: 5 additions & 0 deletions arch/Kconfig.v2
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"
21 changes: 21 additions & 0 deletions arch/archs.yml
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
11 changes: 3 additions & 8 deletions boards/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

config BOARD
string
# When using hw model v2, then the board is inherited from CMake.
default "$(BOARD)" if "$(HWM_SCHEME)" = "v2"
help
This option holds the name of the board and is used to locate the files
related to the board in the source tree (under boards/).
Expand Down Expand Up @@ -38,14 +40,7 @@ config NET_DRIVERS
When building for a qemu target then NET_DRIVERS will be default
enabled to allow for easy use of SLIP or PPP

# Note: $BOARD_DIR might be a glob pattern

choice
prompt "Board Selection"

source "$(BOARD_DIR)/Kconfig.board"

endchoice
rsource "Kconfig.$(HWM_SCHEME)"

# Parse shields references
# Don't do it as a menuconfig, as shield selection is a CMake feature.
Expand Down
10 changes: 10 additions & 0 deletions boards/Kconfig.v1
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
18 changes: 18 additions & 0 deletions boards/Kconfig.v2
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)"
7 changes: 0 additions & 7 deletions boards/arm/mps3_an547/Kconfig.board

This file was deleted.

9 changes: 0 additions & 9 deletions boards/arm/rzt2m_starterkit/Kconfig.defconfig

This file was deleted.

5 changes: 5 additions & 0 deletions boards/v2/arm/mps3/Kconfig
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
Expand Up @@ -3,9 +3,6 @@

if BOARD_MPS3_AN547

config BOARD
default "mps3_an547"

# MPU-based null-pointer dereferencing detection cannot
# be applied as the (0x0 - 0x400) is unmapped but QEMU
# will still permit bus access.
Expand Down
7 changes: 7 additions & 0 deletions boards/v2/arm/mps3/Kconfig.mps3
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
File renamed without changes.
7 changes: 7 additions & 0 deletions boards/v2/arm/mps3/board.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
board:
name: mps3
vendor: arm
Copy link
Member

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.txt

Copy link
Member

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)

Copy link
Contributor Author

@tejlmand tejlmand Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't we re-use vendor-prefixes.txt (from dt-bindings),

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.

and guess the vendor name based on board location?

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.

Copy link
Contributor Author

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

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

socs:
- name: 'an547'
variants:
- name: 'ns'
File renamed without changes.
File renamed without changes.
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
# SPDX-License-Identifier: Apache-2.0
#

identifier: mps3_an547
identifier: mps3/an547
name: Arm MPS3-AN547
type: mcu
arch: arm
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,6 @@
# SPDX-License-Identifier: Apache-2.0
#

CONFIG_SOC_SERIES_MPS3=y
CONFIG_SOC_MPS3_AN547=y
CONFIG_BOARD_MPS3_AN547=y
CONFIG_RUNTIME_NMI=y
CONFIG_ARM_TRUSTZONE_M=y
CONFIG_ARM_MPU=y
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
# SPDX-License-Identifier: Apache-2.0
#

identifier: mps3_an547_ns
identifier: mps3/an547/ns
name: Arm MPS3-AN547_ns
type: mcu
arch: arm
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,6 @@
# SPDX-License-Identifier: Apache-2.0
#

CONFIG_SOC_SERIES_MPS3=y
CONFIG_SOC_MPS3_AN547=y
CONFIG_BOARD_MPS3_AN547=y
CONFIG_ARM_TRUSTZONE_M=y
CONFIG_RUNTIME_NMI=y
CONFIG_TRUSTED_EXECUTION_NONSECURE=y
Expand Down
6 changes: 6 additions & 0 deletions boards/v2/renesas/rzt2m_starterkit/Kconfig.rzt2m_starter_kit
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
3 changes: 3 additions & 0 deletions boards/v2/renesas/rzt2m_starterkit/board.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
board:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file now just duplicates the same information we have in rzt2m_starter_kit.yaml resulting in 2 yaml files used by the board which is not great.

Copy link
Contributor Author

@tejlmand tejlmand Nov 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file now just duplicates the same information we have in rzt2m_starter_kit.yaml resulting in 2 yaml files used by the board which is not great.

No, the current *.yaml files are used by twister and not the board.
Due to that and partly how twister blindly globs for '*.yaml' files to determine boards, then I didn't want to initially merge the content of those files.

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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, and testing 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 and flash, 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...

Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

@tejlmand tejlmand Nov 22, 2023

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:

  1. 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.
  2. 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.

Copy link
Member

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 the twister 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:

  1. 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.
  2. 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.

Copy link
Contributor Author

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 👍

name: rzt2m_starter_kit
vendor: Renesas
Original file line number Diff line number Diff line change
@@ -1,9 +1,6 @@
# Copyright (c) 2023 Antmicro <www.antmicro.com>
# SPDX-License-Identifier: Apache-2.0

CONFIG_SOC_RENESAS_RZT2M=y
CONFIG_BOARD_RZT2M_STARTER_KIT=y

CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
Expand Down
36 changes: 21 additions & 15 deletions cmake/modules/arch.cmake → cmake/modules/arch_v1.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@
#
# Copyright (c) 2022, Nordic Semiconductor ASA

#
# This CMake module is only valid for hw model v1.
# In hw model v1, then arch is determined by the board folder structure.
#
# Configure ARCH settings based on board directory and arch root.
#
# This CMake module will set the following variables in the build system based
Expand All @@ -25,24 +29,26 @@

include_guard(GLOBAL)

# 'ARCH_ROOT' is a prioritized list of directories where archs may be
# found. It always includes ${ZEPHYR_BASE} at the lowest priority (except for unittesting).
if(NOT unittest IN_LIST Zephyr_FIND_COMPONENTS)
list(APPEND ARCH_ROOT ${ZEPHYR_BASE})
endif()
if(HWMv1)
# 'ARCH_ROOT' is a prioritized list of directories where archs may be
# found. It always includes ${ZEPHYR_BASE} at the lowest priority (except for unittesting).
if(NOT unittest IN_LIST Zephyr_FIND_COMPONENTS)
list(APPEND ARCH_ROOT ${ZEPHYR_BASE})
endif()

cmake_path(GET BOARD_DIR PARENT_PATH board_arch_dir)
cmake_path(GET board_arch_dir FILENAME ARCH)
cmake_path(GET BOARD_DIR PARENT_PATH board_arch_dir)
cmake_path(GET board_arch_dir FILENAME ARCH)

foreach(root ${ARCH_ROOT})
if(EXISTS ${root}/arch/${ARCH}/CMakeLists.txt)
set(ARCH_DIR ${root}/arch)
break()
endif()
endforeach()
foreach(root ${ARCH_ROOT})
if(EXISTS ${root}/arch/${ARCH}/CMakeLists.txt)
set(ARCH_DIR ${root}/arch)
break()
endif()
endforeach()

if(NOT ARCH_DIR)
message(FATAL_ERROR "Could not find ARCH=${ARCH} for BOARD=${BOARD}, \
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()
41 changes: 41 additions & 0 deletions cmake/modules/arch_v2.cmake
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()
Loading