You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3681ea8
Browse filesBrowse the repository at this point in the historyBrowse files
@@ -10026,6 +10027,99 @@ A TPM that offers both buses latches its choice from a strap while its own reset
10026
10027
10027
10028
Every FIFO and bus wait in both drivers is bounded, so a device that is absent or unpowered makes `wolfBoot_tpm2_init()` report a failure rather than wedging the bootloader in a spin loop.
10028
10029
10030
+
## Infineon PSOC Edge E8
10031
+
10032
+
The Infineon PSOC Edge E8 family (PSE8x, CAT1D) pairs a Cortex-M33 with TrustZone and a Cortex-M55 behind a Secure Enclave, which runs the boot ROM and Infineon's extended boot. wolfBoot runs on the CM33 in the Secure state as the first image extended boot launches. The port is bare metal and needs no Peripheral Driver Library or BSP. Board differences are make options, and `config/examples/psoc_e8_ai.config` describes KIT_PSE84_AI.
10033
+
10034
+
Verified on KIT_PSE84_AI (PSE846GPS2DBZC4A): boot from QSPI under the factory extended boot, ECC256 verification and handoff, A/B update with confirmation, resumption of an update interrupted mid-swap, RRAM write and erase, and the wolfCrypt test and benchmark. With TrustZone, the Non-secure application booting from the Secure wolfBoot, the A/B update through the gateway calls, Secure-memory isolation and the wolfHSM client test suite against the Secure server were verified on the same board. Booting from RRAM (`PSOC_E8_BOOT_RRAM=1`) is build-tested only. The CM55 is not started.
10035
+
10036
+
### Boot chain and memory
10037
+
10038
+
Extended boot runs the first CM33 image in place from QSPI at `0x60100000`. It requires a 0x400-byte header and a trailing SHA-256 of header and image (an unsigned, MCUboot-compatible format), which `tools/scripts/psoc_e8/psoc_e8_boot_header.py` adds to `wolfboot.bin`.
10039
+
10040
+
Each memory has four aliases, Secure/Non-secure by code/system bus. wolfBoot links at `0x18100400`; the layout below is the non-TrustZone configuration and uses the Secure code-bus QSPI alias:
10041
+
10042
+
```
10043
+
RRAM 0x02000000 NS code 0x12000000 S code 0x22000000 NS sys 0x32000000 S sys
10044
+
QSPI 0x08000000 NS code 0x18000000 S code 0x60000000 NS sys 0x70000000 S sys
`IMAGE_HEADER_SIZE=1024` keeps the application vector table on the 1 KB boundary the CM33 requires.
10053
+
10054
+
### QSPI flash
10055
+
10056
+
QSPI is programmed through the generic `src/qspi_flash.c` driver, without `EXT_FLASH`, so the partitions stay in place for execute-in-place. The HAL supplies its `qspi_transfer()` over the SMIF MMIO command interface, using the device extended boot configured, and the driver is built with `QSPI_FLASH_RAM_CODE`, dedicated 4-byte opcodes and `QSPI_NO_4BYTE_MODE` so the part stays in the address mode extended boot expects. Writes run from RAM with interrupts masked, stage each page in RAM (the source is often QSPI itself), and invalidate the SMIF and CM33 caches afterwards. The test application runs from the QSPI it programs, so its flash path is also placed in RAM.
10057
+
10058
+
The NOR keeps ECC over 16-byte units and rejects a second program into a unit, so the config sets `NVM_FLASH_WRITEONCE=1`. With 256 KB sectors this costs a sector-sized RAM buffer. A rejected program leaves the part busy across a warm reset, where extended boot can no longer read it, so the HAL clears the failure flags when it sees them.
10059
+
10060
+
### Build options
10061
+
10062
+
wolfBoot does not change the clocks extended boot sets. The console is SCB2 on P6.5/P6.7, the KitProg3 COM port, at 115200 baud.
| `PSOC_E8_BOOT_RRAM` | 0 | link wolfBoot into RRAM instead of QSPI |
10075
+
| `PSOC_E8_RRAM_SLOT_SIZE` | 0x20000 | RRAM slot with `PSOC_E8_BOOT_RRAM=1` |
10076
+
10077
+
### Building and flashing
10078
+
10079
+
```sh
10080
+
cp config/examples/psoc_e8_ai.config .config
10081
+
make clean && make
10082
+
tools/scripts/psoc_e8/psoc_e8_flash.sh
10083
+
```
10084
+
10085
+
The script adds the boot header to `wolfboot.bin` and programs it and `test-app/image_v1_signed.bin` over the KitProg3, with the ModusToolbox Programming Tools OpenOCD (`MTB_PROGTOOLS`, default `/opt/Tools/ModusToolboxProgtools-1.6`). Set `KITPROG_SERIAL` if several probes are attached. This replaces the factory CM33 image, so read QSPI back first to keep the stock demo.
10086
+
10087
+
To test an update, sign v2 and program it into UPDATE. The v1 application triggers the update, and v2 confirms itself:
`make WOLFCRYPT_TEST=1 WOLFCRYPT_BENCHMARK=1` adds the software wolfCrypt test and benchmark to the test application. Its RNG seed is deterministic and only for testing.
10096
+
10097
+
### TrustZone and wolfHSM
10098
+
10099
+
`config/examples/psoc_e8_ai-tz.config` runs wolfBoot in the Secure state and the application Non-secure. `config/examples/psoc_e8_ai-tz-wolfhsm.config` adds a wolfHSM server in the Secure world (`WOLFCRYPT_TZ_WOLFHSM=1`), which the Non-secure application reaches as a wolfHSM client through one gateway call, as on STM32H5 (see [wolfHSM.md](wolfHSM.md)).
10100
+
10101
+
```
10102
+
0x18100000 - 0x1813BFFF wolfBoot slot (Secure)
10103
+
0x1813C000 - 0x1813FFFF NSC gateway veneers
10104
+
0x08140000 - 0x0823FFFF BOOT partition, Non-secure alias
The CM33 runs both worlds in protection context 2, so `hal_init()` grants that context Non-secure access to the boot partition in the SMIF memory protection controller and to SRAM1 in its controller, and adds SAU regions for those and the gateway. wolfBoot then reads and verifies the boot partition through its Non-secure alias. Peripherals stay Secure: the application updates through the `wolfBoot_nsc_*` calls and prints through a console gateway. The crypto block's TRNG, with both health monitors running, seeds the Secure DRBG.
10112
+
10113
+
Fresh RRAM reads as zero, which the wolfHSM NVM does not accept as empty, so program a board once with `--erase-keyvault`, which fills the key store with 0xFF and destroys anything stored there:
`PSOC_E8_BOOT_RRAM=1` links wolfBoot at `0x12011400` in the RRAM user area, keeping the partitions in QSPI. Extended boot only launches it once the boot policy is reprovisioned with Infineon's Edge Protect Tools, which this port does not automate. RRAM is written in 16-byte blocks through the RRAMC indirect-write action, under the IPC and PC_LOCK locks. It has no erase, so `hal_flash_erase()` fills the range with 0xFF to read like erased NOR.
10122
+
10029
10123
## Infineon AURIX TC3xx
10030
10124
10031
10125
wolfBoot supports the Infineon AURIX TC3xx family and includes a demo application for the TC375 AURIX LiteKit-V2. It can be configured to run on either the TriCore application cores or the HSM core.
- STM32H5 TrustZone (the secure-side wolfBoot hosts a wolfHSM server and exposes it to the non-secure application through a single NSC veneer; see [STM32H5 TrustZone Engine](#stm32h5-trustzone-engine) below)
26
+
- Infineon PSOC Edge E8 TrustZone (the same engine, with the NVM in RRAM; see the PSOC Edge E8 section of [Targets.md](Targets.md))
26
27
27
28
Details on configuring wolfBoot to use wolfHSM on each of these platforms can be found in the wolfBoot (and wolfHSM) documentation specific to that target, with the exception of the simulator, which is documented here. The remainder of this document focuses on the generic wolfHSM-related configuration options.
28
29
@@ -315,4 +316,6 @@ The default build prints a final `WOLFHSM_TZ_TEST_PASS` UART line on success. Th
315
316
316
317
### Notes
317
318
319
+
The same engine runs on Infineon PSOC Edge E8 (`config/examples/psoc_e8_ai-tz-wolfhsm.config`), with the NVM in RRAM through the same flash adapter.
320
+
318
321
The wolfHSM NVM lives in the existing `FLASH_KEYVAULT` region (112 KiB at `0x0C040000`) shared with the other STM32H5 TrustZone engines. The flash adapter (`src/wolfhsm_flash_hal.c`) caches the affected sector, modifies it, and rewrites the whole 8 KiB sector in one erase + program cycle, mirroring `psa_store.c` / `pkcs11_store.c`. This satisfies the H5 quad-word ECC rule that each 16-byte unit may be programmed exactly once between erases, which wolfHSM's 8-byte-unit writes would otherwise violate.
0 commit comments