-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Conversation
stdout. | ||
|
||
config BOARD_NATIVE_POSIX_64 | ||
bool |
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 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>
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.
first round of comments.
if((${BOARD_DIR} MATCHES "boards\/native") OR ("${ARCH}" STREQUAL "posix") | ||
OR ("${BOARD}" STREQUAL "unit_testing")) |
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.
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.
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.
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) |
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.
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 |
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.
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 ?
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.
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.
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.
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 |
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 guess similar comment regarding the board or soc being 64bit applies here.
vendor: Zephyr | ||
socs: | ||
- name: native | ||
- name: nrf5340bsim_nrf5340_cpuapp |
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 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 ?
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.
Same answer as above
(clarification w "variants" I meant "socs" or "cpu-clusters")
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.
concerns has been answered and followup plan is in place.
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:
Note: This PR fixes the current CI failures in the nrf5x_bsim
and unit_testing targets(unit testing fixed by #69019 already)