[jbenedictocenteno]

Description of Change

A closed C5 never kept an update. Its build has app rollback on, and it confirms a new image at the first KODE request it receives. After install dst=c5 the update ends with the link down for the rest of the boot. The next boot's bring-up reset the C5 before any request reached it, so the bootloader found the image still pending and went back to the old one. The >ok was right, the update was activated, and a reset later it was gone.

This change keeps the C5 running until a link has reached the new image:

• kdrv: a third handover note, KDRV_RADIO_NOTE_UPDATE. After a software reset it keeps the C5 whatever the role and the wish. kdrv_radio_note_update_waits() reads it at boot without erasing it.
• AO_Radio, at the end of an update: arms a one-shot of 3.5 s (KDRV_RADIO_C5_ACTIVATE_MS, esp-hosted's restart delay, plus KDRV_RADIO_C5_BOOT_MS), then asks AO_Boot to restart the board (boot_exit_evt()). The park answer leaves the UPDATE note, and Radio_off does not hold the C5 meanwhile.
• The next boot keeps the C5, and brings the link up even when neither Wi-Fi nor BLE is wanted. The first request confirms the image.

A C5 without rollback (the open build) behaves as before, except that the board now restarts by itself after an update.

Test Scenarios

• tools/host_tests.sh: 5257 cases across 8 suites. New cases cover the note rule, the restart after 3.5 s (asked once), the UPDATE note on the park, no hold after an update, and the link brought up for an update with nothing wanted.
• tools/check_layers.sh clean. tests/target builds on v6.1, full and nowifi, no warnings; RAM and starts checks pass.
• kodeOS built against this branch: no warnings, MISRA check with nothing past the baseline, image and RAM checks pass.
• DVT board with a closed C5 (C5 38:44:be:1c:1d:60), kodeOS from this branch. The two C5 releases are told apart by wifi_frames ch=6 ms=1000: v0.1.0 answers no_service, v0.1.1 has the service and answers wifi_off.
  1. BLE wanted, Wi-Fi not: v0.1.0 to v0.1.1. The board restarts 3.5 s after the >ok (SW_CPU_RESET), the boot says C5 kept: it runs an update its first request confirms, the link is up in 0.85 s. Two port-open resets later, each one resetting the C5 (link up in 2.7 s), it still runs v0.1.1.
  2. Nothing wanted: v0.1.1 back to v0.1.0. The boot brings the link up only to confirm it. Two port-open resets with the C5 held at boot: still v0.1.0.
  3. Nothing wanted: v0.1.0 to v0.1.1, kept after a further reset.
     Identity, vault and BLE keys untouched in every run (id=locked vault=1 btkeys=6).

Related links

• Found testing the OTA of kode_slave_c5 v0.1.1 on a closed C5: the image was accepted and activated, then rolled back at the next reset.
• kodeOS still needs the SDK bump, and the new wording in tools/kcli.py (the board restarts by itself after install --dst c5).