STM32H5: wolfIP NS application under wolfBoot (TZEN=1)#115
Open
dgarske wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make
make TZEN=1on 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
stm32tzbranch of the wolfBoot repo: wolfSSL/wolfBoot#775hal/stm32_tz.chal_gtzc_init: cede SRAM2 to NS and clearMPCBB_PRIVCFGR_VCTRfor SRAM2 + SRAM3. Reset default leaves them privileged-only, which silently blocks the NS+unprivileged ETH DMA and parks the channel onDMACSR.TBU/DMADSR.TPS=6. Also widenhal_tz_sau_initregion 2 to0x20040000-0x2009FFFF.hal/stm32h5.cperiph_unsecure: clearGPIOx_SECCFGRfor 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
wolfBoot's
do_bootsetsMSP_NSfromapp_offset[0]andBLXNSes toapp_offset[1]. The NS app'sReset_HandlerwritesVTOR_NS = 0x08060400first thing so NS exceptions vector correctly. AfterBLXNSthe 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
Produces
factory.bin=wolfboot.bin(padded to the boot-partition offset) + ECC256-signed NS app, ready forSTM32_Programmer_CLI -w factory.bin 0x08000000. TheIMAGE_HEADER_SIZE=1024env wrapper is required (sign tool defaults to 256 for ECC256, which would place the vector table at the wrong offset).WOLFBOOT_ROOTdefaults to../wolfbootand is overridable.