twister: Allow sharing hardware platform between variants

[gchwier]

Extended hardware map to share a single board between variants. To run tests for different variants on the same board without re-configuring the hardware map file for each variant, one can extend the platform attribute with board names separated by spaces or use platform as a list.

Generate hardware map:
${ZEPHYR_BASE}/scripts/twister --generate-hardware-map hardware_map.yml

Update platform with two variants you want to use:

- connected: true
  id: '001050076605'
  platform: nrf5340dk/nrf5340/cpuapp nrf5340dk/nrf5340/cpuapp/ns
  product: J-Link
  runner: nrfjprog
  serial: /dev/ttyACM1

Run tests:
./scripts/twister -T samples/hello_world --device-testing --hardware-map hardware_map.yml --west-flash=--recover -vv --no-clean -ll debug

DEBUG   - platform filter: ['nrf5340dk/nrf5340/cpuapp', 'nrf5340dk/nrf5340/cpuapp/ns']
...
| Board                       |           ID |   Counter |   Failures |
|-----------------------------|--------------|-----------|------------|
| nrf5340dk/nrf5340/cpuapp    | 001050076605 |         1 |          0 |
| nrf5340dk/nrf5340/cpuapp/ns | 001050076605 |         1 |          0 |

When test is run on a selected board, then all DUTs with same id are locked.

[nashif]

can this instead be a list with type: any in the schema so it does support one single entry and a list if variants if needed?

[gchwier]

I considered using:

type: seq
sequence:
    - type str

but that would break backward compatibility, so I didn't apply it.

Good idea with type: any, I will try to update it.
I was looking into testsuite-schema and there are a few fields that can be either a string or a list. There is also a logic in config_parser.py to properly cast those fields. I need to look into it more closely.
Thanks for the advice.

[gchwier]

Updated with type: any. Now user can use a list of platforms:
in line, separated by spaces:

platform: nrf5340dk/nrf5340/cpuapp nrf5340dk/nrf5340/cpuapp/ns

or as a list:

platform:
- nrf5340dk/nrf5340/cpuapp
- nrf5340dk/nrf5340/cpuapp/ns

[hakehuang]

@gchwier this would be a problem, if we add pre_script/post_scripts, we need know the platform, so we need pass the platform name to the scripts as well?

[gchwier]

@gchwier this would be a problem, if we add pre_script/post_scripts, we need know the platform, so we need pass the platform name to the scripts as well?

It will work with PR #81389
because a separate DUT instance is created for every platform.
If you plan to rework your PR to pass parameters to pre-script directly from hardware map yaml file, you can still use separate entries for every variants (as it works now, this change is backward compatible)

[PerMac]

The title is not clear IMO. Maybe Using Single Board For Multiple Variants? Or Boards Supporting Multiple Variants?

[gchwier]

changed to Using Single Board For Multiple Variants, thanks!

[PerMac]

Suggested change

	The ``platform`` attribute can be a list of names or can be extended
	with names separated by spaces. This allows you to run tests for
	different variants on the same board without re-configuring
	the hardware map file for each variant. For example:
	The ``platform`` attribute can be a list of names or a string
	with names separated by spaces. This allows to run tests for
	different platform variants on the same physical board, without re-configuring
	the hardware map file for each variant. For example:

[golowanow]

would be nice to have some tests added for the changed behavior with several DUTs in the list