[nrf fromlist] west: runners: Add ncs-provision to west flash command

[gchwier]

Added automatic KMU key provisioning for both NSIB and MCUboot.
A new --ncs-provision command line option added to nrfutil runner.
This enables automated key provisioning during the flashing process, to enable testing nRF54L aplications (with NSIB and/or MCUboot) using Twister.

• required nrfutil device 2.10.2 or higher

For testing:
app with NSIB:
west build -p -b nrf54l15dk/nrf54l15/cpuapp $ZEPHYR_BASE/samples/hello_world -d build-54l-nsib -- -DSB_CONFIG_SECURE_BOOT_APPCORE=y
west flash --skip-rebuild -d build-54l-nsib --erase --ncs-provision

app with NSIB + MCUboot (with enabled KMU keys)
west build -p -b nrf54l15dk/nrf54l15/cpuapp $ZEPHYR_BASE/samples/hello_world -d build-54l-nsib_mcuboot_kmu -- -DSB_CONFIG_SECURE_BOOT_APPCORE=y -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DSB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=y
west flash --skip-rebuild -d build-54l-nsib_mcuboot_kmu --erase --ncs-provision

For testing with Twister, one can revert that commit:
nrfconnect/sdk-nrf@f4c0cc0
and run:
$ZEPHYR_BASE/scripts/twister -c -T tests/subsys/bootloader/boot_chains -p nrf54l15dk/nrf54l15/cpuapp --device-testing --device-serial /dev/ttyACM1 --west-flash="--recover,--ncs-provision" --enable-slow -vv -ll debug
(only boot_chains, bacause b0_lock causing rolling reboot)

[carlescufi]

I really do not want this amount of out-of-tree code in this file. It will be a nightmare to keep in sync.
Our options are:

• Have everything, including provisioning, upstream (we could call it --provision instead). We already did something similar with the H20 SUIT support, where it was upstream although only needed for downstream
• Use an extension command west ncs-provision
• Change the bare minimum in this file, put the logic elsewhere

[gchwier]

I really do not want this amount of out-of-tree code in this file. It will be a nightmare to keep in sync. Our options are:

• Have everything, including provisioning, upstream
• Use an extension command west ncs-provision
• Change the bare minimum in this file, put the logic elsewhere

I fully agree, which is why I added the DNM label (unfortunately, I can't change the PR to draft status).

I created this as a POC to demonstrate how we can test a simple application without manual steps, eliminating the need for pytest harness in Twister.

Where is the issue with west ncs-provision?
west flash executes a reset after flashing, the application is then marked as "permanently invalidated". Calling west ncs-provision doesn't resolve the problem. Users need to flash with nrfutil (without reset), then call west ncs-provision, and finally reset the device.
This process will likely result in a poor user experience when trying to enable NSIB on the nRF54L.

FYI @nvlsianpu

[carlescufi]

west flash executes a reset after flashing,

There is a --no-reset option to west flash. Why can't you have a west ncs-provision that invokes west flash --no-reset and then does whatever you need to do?

[gchwier]

There is a --no-reset option to west flash. Why can't you have a west ncs-provision that invokes west flash --no-reset and then does whatever you need to do?

I forgot about --no-reset, it is an option for customer, then he can use:

1. west flash --erase/--recover --no-reset
2. west ncs-provision
3. nrfutil device reset

or

1. nrfutil device erase/recover
2. west ncs-provision
3. west flash

An option would be to extend west ncs-provision in sdk-nrf to call also west flash ... but it will not work with Twister .

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud