Run wolfBoot on the PIC32CZ CA9x host core (Cortex-M7) as a wolfHSM client,
offloading the image digest (SHA-256) and the ECDSA P-256 signature check to
the wolfHSM server.
The top-level Makefile defaults WOLFBOOT_ROOT to $(PWD), which is the
environment value of the invoking step: under the workflow's
working-directory (test-app/emu-test-apps) the keytools paths resolved
under the wrong root and keygen was never found, so src/keystore.c was
missing and the wolfboot build failed. Export the computed absolute
WOLFBOOT_ROOT so the make invocations resolve tool paths correctly
wherever the script is started from.
Add a GitHub Actions workflow covering the DUALBANK_SWAP fallback
scenario fixed by the previous commit, running on the m33mu emulator
(wolfboot-ci-m33mu image, which models the physical-bank BKER/SWAP_BANK
semantics of the STM32U5 flash controller).
The test drives three boots in a single emulator session with the
stm32u5-nonsecure-dualbank config:
1. wolfBoot verifies a valid v2 image in the UPDATE partition,
activates SWAP_BANK and reboots;
2. the v2 app, now running from physical bank 2, stages a fake v3
image with a broken integrity record into the logical UPDATE
partition and reboots;
3. wolfBoot selects the v3 update, fails verification, and must erase
the corrupt update and fall back to v2, which reports success via
breakpoint.
Besides the success breakpoint, the script checks the emulator flash
trace: the UPDATE partition must be erased and the BOOT partition
(holding the healthy image) must never be touched, so a regression
cannot hide behind an accidentally bootable state. Verified to fail
against the pre-fix hal_flash_erase, where boot 3 erases the healthy
image and the device bricks.
* file level rename for ML-DSA
* Add missing source file to build system
* Update some macros
* Other minor fixes
* Update size limitations for some slight increases