STM32H5: wolfIP NS application under wolfBoot (TZEN=1)

[dgarske]

Summary

Make make TZEN=1 on the NUCLEO-H563ZI build the wolfIP echo server as a Non-Secure application launched by wolfBoot (BLXNS), instead of running the whole stack in Secure world. The earlier all-secure-app approach deadlocked the ETH DMA; the Non-Secure split matches the H5's product-state defaults (peripherals are NS by default, the ETH DMA master is NS+unprivileged) and lets the same wolfIP feature set that runs under TZEN=0 also run under TZEN=1.

Verified end-to-end on hardware: wolfBoot validates and BLXNSes into the signed wolfIP image, PHY link comes up, DHCP succeeds, ICMP responds in ~0.6 ms, and TCP echo on port 7 round-trips a payload.

Required matching wolfBoot patch

This depends on a corresponding wolfBoot HAL patch on the stm32tz branch of the wolfBoot repo: wolfSSL/wolfBoot#775

• hal/stm32_tz.c hal_gtzc_init: cede SRAM2 to NS and clear MPCBB_PRIVCFGR_VCTR for SRAM2 + SRAM3. Reset default leaves them privileged-only, which silently blocks the NS+unprivileged ETH DMA and parks the channel on DMACSR.TBU / DMADSR.TPS=6. Also widen hal_tz_sau_init region 2 to 0x20040000-0x2009FFFF.
• hal/stm32h5.c periph_unsecure: clear GPIOx_SECCFGR for A/B/C/D/G and enable the GPIOG clock. H5 product-state defaults every GPIO pin to secure-only, so without this the NS RMII pin mux silently no-ops.

Layout

0x0C000000 wolfBoot (Secure, ~376 KB)
0x08060000 wolfBoot 1024-byte image header
0x08060400 wolfIP NS vector table + .text (boot partition, 640 KB)
0x20040000 NS RAM (SRAM2+SRAM3, 384 KB)
0x20000000 wolfBoot RAM (SRAM1 secure alias 0x30000000)

wolfBoot's do_boot sets MSP_NS from app_offset[0] and BLXNSes to app_offset[1]. The NS app's Reset_Handler writes VTOR_NS = 0x08060400 first thing so NS exceptions vector correctly. After BLXNS the chip is left running on wolfBoot's 250 MHz PLL; the NS app reverts SYSCLK to HSI/2 = 32 MHz so the existing USART3 BRR and SysTick math from the TZEN=0 build keep working.

Build

WOLFBOOT_ROOT=$HOME/GitHub/wolfboot \
  make TZEN=1 CC=arm-none-eabi-gcc OBJCOPY=arm-none-eabi-objcopy
WOLFBOOT_ROOT=$HOME/GitHub/wolfboot make signed factory

Produces factory.bin = wolfboot.bin (padded to the boot-partition offset) + ECC256-signed NS app, ready for STM32_Programmer_CLI -w factory.bin 0x08000000. The IMAGE_HEADER_SIZE=1024 env wrapper is required (sign tool defaults to 256 for ECC256, which would place the vector table at the wrong offset). WOLFBOOT_ROOT defaults to ../wolfboot and is overridable.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[danielinux]

Only one (minor) remark about unnecessary large timeouts + related comments in the github actions.

The other two comments re: emulator mismatches are being addressed in m33mu (thank you for spotting those!)

[danielinux]

The limit here seems to be too high. Could it be that the comment refers to when the test was running with debugging (e.g. with --gdb, --dump, --record, etc.) or any option that would disable "fast mode" with branch prediction in the emulator.

The actual test with the current options seems to take 182 seconds so those timeouts seem too high.

[danielinux]

I have checked and the latest m33mu does not have this issue. I've added a non-regression test in m33mu for this. (This comment brings no action and can be resolved)

[danielinux]

This is a real fidelity gap in the emulator. Fixing.(No actions)