Skip to content
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

hwmv2: Native targets covert to HW model v2 #69034

Merged
merged 6 commits into from
Feb 16, 2024

Conversation

aescolar
Copy link
Member

@aescolar aescolar commented Feb 15, 2024

Convert all native targets (POSIX arch based) in tree, and their SOC to the HW model v2.
With these commits all native_sim/posix[_64] and nrf*_bsim tests should pass again.

Notes:

  • It sits directly on top of hwmv2: Fix unit_testing and another cmake fix #69019 as it needs one of its commits
  • The last 3 commits are not independent/bisectable (I can squash them in one, but this target branch does not seem to be kept bisectable). So I kept them apart to ease reviewing and future understanding (so it is easier for out of tree users to know how to do the same for their posix arch based boards).
  • By now the 64 bit native_posix/sim variants, and the nrf5340bsim cpu app/net variants are kept as separate targets instead of variants of the same target. So after this PR commits everything works just like before this branch. So there is no breakage cause by this commits. Otherwise this PR would need to contain a massive amount of changes. Changing them to variants can be done safely after without a massive hard change in 1 commit or non-bisectable ones (i.e. the variants can be added, all tests and docs changed, and the old boards removed in separate commits).

Note: This PR fixes the current CI failures in the nrf5x_bsim and unit_testing targets (unit testing fixed by #69019 already)

stdout.

config BOARD_NATIVE_POSIX_64
bool
Copy link
Collaborator

Choose a reason for hiding this comment

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

This represents an issue @tejlmand

With hwmv2, the ARCH variable is not yet defined
when this module is loaded (kconfig is parsed after this).
So we cannot rely on it to detect if we are building for a
host target.
For this case, let's instead detect it by the BOARD or
BOARD_DIR which are some of the very few things defined
at this point.
We retain the old check to support hwmv1 boards which
may be in other folders.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Just fix the path, it was not correct.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Add a soc.yml and reorganize the Kconfig options

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
With new board.yml files and reorganizing their
Kconfig options.

Note: native_posix_64 & native_sim_64 remain as their own
targets, instead of being variants of the base ones
to avoid breakage in this commit, while not
having a massive commit.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
With a new board.yml file and reorganizing their
Kconfig options.

Note: the nrf5340 variants remain as their own
targets, instead of being variants of the base ones
to avoid breakage in this commit
(while not having a massime commit)

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
To match the current placement.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

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

first round of comments.

Comment on lines +69 to +70
if((${BOARD_DIR} MATCHES "boards\/native") OR ("${ARCH}" STREQUAL "posix")
OR ("${BOARD}" STREQUAL "unit_testing"))
Copy link
Collaborator

Choose a reason for hiding this comment

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

for host tools we just need a generic compiler for preprocessing.

This mean we should be able to move this check to https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/modules/FindTargetTools.cmake where the arch is known.

This location is probably leftover from former days boilerplate.cmake file.

We can keep it here for now, but then please add a comment in code or create an enhancement issue / comment in #51831 to request looking at this as followup work.

Copy link
Member Author

Choose a reason for hiding this comment

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

Item added to #51831 list of TODOs

@@ -25,7 +25,7 @@ zephyr_library_include_directories(
)

if(CONFIG_HAS_SDL)
add_subdirectory(${ZEPHYR_BASE}/boards/boards_legacy/${ARCH}/common/sdl/ ${CMAKE_CURRENT_BINARY_DIR}/sdl)
add_subdirectory(${ZEPHYR_BASE}/boards/native/common/sdl/ ${CMAKE_CURRENT_BINARY_DIR}/sdl)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why is this using a path from zephyr base, and not relative to current folder ?
Such as:

	 add_subdirectory(${CMAKE_CURRENT_LIST_DIR}/../common/sdl/ ${CMAKE_CURRENT_BINARY_DIR}/sdl)

seems a bit safer.
However, current proposal is also ok, as I don't expect we'll be moving boards around so much more.

vendor: Zephyr
socs:
- name: native
- name: native_posix_64
Copy link
Collaborator

Choose a reason for hiding this comment

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

should it be the board or the soc that is considered 64bit ?

Meaning, should we instead have:

board:
  name: native_posix
  vendor: Zephyr
  socs:
  - name: native
  - name: native_64

Considering the SoC 64bit then that would also remove the need for:

config BOARD_NATIVE_POSIX_64
	 bool
	 select BOARD_NATIVE_POSIX
	 select 64BIT

as the 64bit is then selected by the soc and there is no need to select BOARD_NATIVE_POSIX.
I also think this aligns more with what is done for qemu boards.

@nordicjm thoughts ?

Copy link
Member Author

@aescolar aescolar Feb 16, 2024

Choose a reason for hiding this comment

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

should it be the board or the soc that is considered 64bit ?

I intended to do that as a follow up. In this PR I hoped to bring everything back to working order in the hwmv2 format while keeping the PR reasonably sized. The next steps were to define this and the nrf5340 as having different socs , change all tests and BT test infra accordingly, and then remove this "backwards compatible" board definitions.

@nordicjm 's pointed issue would still apply for the nrf*bsim boards, there the nrf52 will remain separate from the nrf53 anyhow.

Copy link
Collaborator

Choose a reason for hiding this comment

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

true, and it's a side-effect of allowing multiple boards being defined in board.yml.

Something which would needs to be addressed.

vendor: Zephyr
socs:
- name: native
- name: native_sim_64
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess similar comment regarding the board or soc being 64bit applies here.

vendor: Zephyr
socs:
- name: native
- name: nrf5340bsim_nrf5340_cpuapp
Copy link
Collaborator

Choose a reason for hiding this comment

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

this ought to be a soc with a cpucluster if the intention is to have it appear similar to a nRF530 SoC.

Doing so would also remove some other comments which I would otherwise have regarding the Kconfig.

I did notice:

Note: the nrf5340 variants remain as their own
targets, instead of being variants of the base ones
to avoid breakage in this commit

what kind of breakage are you refering to, and are you planning to make more updates to the bsim boards with regards to variants ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Same answer as above
(clarification w "variants" I meant "socs" or "cpu-clusters")

@aescolar aescolar mentioned this pull request Feb 16, 2024
11 tasks
Copy link
Collaborator

@tejlmand tejlmand left a comment

Choose a reason for hiding this comment

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

concerns has been answered and followup plan is in place.

@aescolar aescolar requested a review from nordicjm February 16, 2024 11:23
@henrikbrixandersen henrikbrixandersen changed the title hwmv2: Native targets covert to HW modem v2 hwmv2: Native targets covert to HW model v2 Feb 16, 2024
@tejlmand tejlmand merged commit dc9d6e8 into zephyrproject-rtos:collab-hwm Feb 16, 2024
18 checks passed
@aescolar aescolar deleted the native_hwm branch February 16, 2024 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants