twister does not understand HWMv2 board qualifiers for platform arguments

[henrikbrixandersen]

Describe the bug The --platform argument to twister does not understand HWMv2 board qualifiers.

To Reproduce Steps to reproduce the behavior:

1. west build -b lpcxpresso55s36/lpc55s36 samples/hello_world/ (this works as expected)
2. west twister -p lpcxpresso55s36/lpc55s36 -T samples/hello_world/ (this does not work)
3. See error

Expected behavior Twister is able to understand board qualifiers.

Impact Confusion, especially since our shell completions scripts completes the board qualifiers for west twister -p ... as well.

Logs and console output

$ west twister -p lpcxpresso55s36/lpc55s36 -T samples/hello_world/
INFO    - Using Ninja..
INFO    - Zephyr version: v3.6.0-5871-g97c3f87c82b4
INFO    - Using 'zephyr' toolchain.
ERROR   - platform_filter - unrecognized platform - lpcxpresso55s36/lpc55s36

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK
• Commit SHA: 2871c87aaec004cf4fe8e61a8d15c35b6d8ab677

[henrikbrixandersen]

This falls back on Twister using the scripts/schemas/twister/platform-schema.yaml based files operating on "platforms" named from the identifier in those files, whereas West uses scripts/schemas/board-schema.yml operating on HWMv2 "board targets".

This is highly confusing and prevents running Twister on a given board variant unless that board variant has a custom platform-schema file (e.g. boards/native/native_sim/native_sim_native_64.yaml).

[nashif]

@henrikbrixandersen i think i have a way to deal with this, but it requires some major changes and already prototyping this. This is one of the issue we identified very early on in hwmv2 and plan to address. Not sure this can make it into 3.7 though, there are many inconsistencies of how boards are configured and that would require lots of harmonization before a general solution is applied.

[henrikbrixandersen]

@henrikbrixandersen i think i have a way to deal with this, but it requires some major changes and already prototyping this. This is one of the issue we identified very early on in hwmv2 and plan to address. Not sure this can make it into 3.7 though, there are many inconsistencies of how boards are configured and that would require lots of harmonization before a general solution is applied.

Yeah, it will require some major changes. I've tried twice to solve it myself, but ran into unforeseen problems in both attempts.

I think it is unfortunate if this will not be fixed before v3.7.0 LTS, as it is confusing to users and makes the HWMv2 transition seem half-finished.

[nashif]

i will spend some time on it sooner and see if I can address it for 3.7, agree this is an issue.

[tobiaskaestner]

We have seen the same inconsistency downstream as well and there is a related issue #71761 that tried to partially solve it. Bottom line is that still we have diverging code bases in how west sees the workspace and how twister sees the same workspace. In the long run there is IMHO some effort needed to consolidate this into a common library that both west and twister can be based on. For now @rexut offered in #71761 some additional workarounds that did not get merged back then but would most likely help here.

[nashif]

note that I am actively looking into this now:

• will get list of boards from the build system (parsing board.yml files, etc.)
• looking into converting board yaml files used by twister (.yaml) into one single file and removing duplicated data (vendor, ...). Instead of having a yaml file per board target/variant, we will have just one file.

Trying to keep things backward compatible as much as possible, but there will be some breaking changes, hopefully minimal.

[tobiaskaestner]

@nashif , I am glad to help if you need some additional pair of hands for testing

[nashif]

We have seen the same inconsistency downstream as well and there is a related issue #71761 that tried to partially solve it. Bottom line is that still we have diverging code bases in how west sees the workspace and how twister sees the same workspace. In the long run there is IMHO some effort needed to consolidate this into a common library that both west and twister can be based on. For now @rexut offered in #71761 some additional workarounds that did not get merged back then but would most likely help here.

@tobiaskaestner that is a different issue, probably need to reopen #71761 and adress this on its own.