[dgarske]

Description

Bare-metal wolfBoot port for the Infineon PSOC Edge E8 family, running on the Secure CM33 as the first image extended boot launches from QSPI, with optional TrustZone and a wolfHSM server in the Secure world.

What it adds

• hal/psoc_e8.{c,h,ld} - SCB console, QSPI program/erase through the generic src/qspi_flash.c driver while executing in place, RRAM writes
• hal/psoc_e8_tz.c, hal/psoc_e8-tz.ld - SAU and memory protection, TRNG entropy, console gateway for the Non-secure app
• config/examples/psoc_e8_ai*.config, arch.mk - KIT_PSE84_AI: plain, TrustZone, and TrustZone with WOLFCRYPT_TZ_WOLFHSM=1; PSOC_E8_BOOT_RRAM=1 for an RRAM-resident wolfBoot
• tools/scripts/psoc_e8/ - adds the boot header extended boot requires and programs the kit over KitProg3/OpenOCD
• test-app support including wolfCrypt test/benchmark, unit tests, CI jobs, docs/Targets.md, docs/wolfHSM.md

Touches shared code

• src/qspi_flash.c - opt-in QSPI_FLASH_RAM_CODE and QSPI_NO_4BYTE_MODE, overridable program/erase opcodes
• test-app/Makefile - the test-app builds its HAL copy as test-app/hal_$(TARGET).o, so a second make no longer relinks it into wolfBoot (undefined hal_init on psoc_c3 and psoc_e8)

Testing

Validated on KIT_PSE84_AI (KitProg3): boot and ECC256 verify, A/B update with and without TrustZone, resume after a mid-swap reset, RRAM write, wolfCrypt test and benchmark, and the wolfHSM client suite against the Secure server.

RRAM boot is build-tested only (needs Edge Protect boot policy provisioning). CM55, crypto acceleration and the Secure Enclave are follow-on.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #949

Scan targets checked: wolfboot-src, wolfboot-bugs
Not reviewed (no scan target covers them): .github/workflows/test-configs.yml, .gitignore, Makefile, arch.mk, config/examples/psoc_e8_ai-tz-wolfhsm.config, config/examples/psoc_e8_ai-tz.config, config/examples/psoc_e8_ai.config, docs/Targets.md, docs/wolfHSM.md, hal/psoc_e8-tz.ld, hal/psoc_e8.h, hal/psoc_e8.ld, test-app/ARM-psoc_e8-ns.ld, test-app/ARM-psoc_e8.ld, test-app/Makefile, tools/scripts/psoc_e8/psoc_e8_boot_header.py, tools/scripts/psoc_e8/psoc_e8_flash.sh, tools/unit-tests/Makefile
Coverage: 5 of 7 in-scope changed file(s) opened by the reviewer; not opened: hal/psoc_e8_tz.c, test-app/app_psoc_e8.c

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

Review tier: Lite

[aidangarske]

Skoll Code Review

Scan type: review

Overall recommendation: REQUEST_CHANGES
Findings: 6 total — 6 posted, 0 skipped
6 finding(s) posted as inline comments (see file-level comments below)

Posted findings

• [High] Apply the PSOC E8 output selection outside the TrustZone guard — Makefile:386-389
• [High] Reserve space for the appended boot-image TLV — arch.mk:768-777
• [High] Keep the private application HAL object forced — test-app/Makefile:1729
• [Medium] Verify application images after programming — tools/scripts/psoc_e8/psoc_e8_flash.sh:52-55
• [Medium] Add coverage for the extended-boot image format — tools/scripts/psoc_e8/psoc_e8_boot_header.py:20-29
• [Low] Scope the documented alias layout correctly — docs/Targets.md:10017

Review generated by Skoll

[aidangarske]

Apply the PSOC E8 output selection outside the TrustZone guard

The new psoc_e8 block is nested inside ifeq ($(TZEN),1), so the plain and RRAM configurations, both of which set TZEN=0, retain MAIN_TARGET=factory.bin. Evaluating the plain configuration confirms this. That artifact is inappropriate for this target because it lacks the required extended-boot header; the RRAM configuration also places wolfBoot and the application in non-contiguous address spaces. The documented wolfboot.bin and signed application outputs are only selected for TrustZone builds.

Fix: Move the psoc_e8 target block below the enclosing TZEN conditional so all PSOC E8 configurations select wolfboot.bin and test-app/image_v1_signed.bin.

[aidangarske]

Reserve space for the appended boot-image TLV

BOOTLOADER_PARTITION_SIZE reserves only the 0x400-byte prefix, but psoc_e8_boot_header.py also appends 40 bytes after wolfboot.bin: a 4-byte TLV-info header, a 4-byte SHA-256 entry header, and a 32-byte digest. An image accepted at the linker limit therefore extends 40 bytes beyond the configured boot slot. In QSPI this overlaps the BOOT partition; in RRAM it exceeds the provisioned slot. The TrustZone linker layout has the analogous problem if .gnu.sgstubs consumes the available NSC region.

Fix: Reserve the 40-byte trailer in every PSOC E8 linker layout and add a linker or packaging-time assertion that the header, image, and TLV remain within the selected boot slot.

[aidangarske]

Keep the private application HAL object forced

The previous shared HAL rule and the existing Agilex private rule both depend on FORCE, because Make does not track changes to compiler flags. The new generalized private rule drops that prerequisite. A second build of the same target with changed board or feature options can consequently reuse a stale hal_$(TARGET).o; for example, changing PSOC_E8_UART_SCB or PSOC_E8_CPU_HZ does not rebuild the HAL.

Fix: Restore the FORCE prerequisite on the private HAL rule.

Suggestion:

Suggested change

	hal_$(TARGET).o: ../hal/$(TARGET).c
	hal_$(TARGET).o: ../hal/$(TARGET).c FORCE

[aidangarske]

Verify application images after programming

The script verifies the generated wolfBoot image but not the BOOT or optional UPDATE images. flash write_image does not perform the explicit byte comparison provided by verify_image, so the script can exit successfully while leaving a corrupted or incomplete signed application that wolfBoot subsequently rejects.

Fix: Add verify_image commands for both application partitions.

Suggestion:

Suggested change

	CMDS="$CMDS; flash write_image erase $BOOT_IMG $BOOT_ADDR bin"
	CMDS="$CMDS; flash write_image erase $BOOT_IMG $BOOT_ADDR bin"
	CMDS="$CMDS; verify_image $BOOT_IMG $BOOT_ADDR bin"
	if [ -n "$UPDATE_IMG" ]; then
	CMDS="$CMDS; flash write_image erase $UPDATE_IMG $UPDATE_ADDR bin"
	CMDS="$CMDS; verify_image $UPDATE_IMG $UPDATE_ADDR bin"
	fi

[aidangarske]

Add coverage for the extended-boot image format

The new boot-critical packaging function has no automated tests. Existing PSOC E8 unit tests cover the target HAL but do not validate the generated header fields, padding, digest, TLV lengths, or final image size. A formatting regression would only be discovered when extended boot rejects the image on hardware.

Fix: Add deterministic tests that parse a generated image, validate every header and TLV field, recompute the digest, cover an empty payload, and check the slot-size boundary.

[aidangarske]

Scope the documented alias layout correctly

The statement that all .config addresses use the Secure code-bus alias conflicts with both TrustZone configurations, where WOLFBOOT_PARTITION_BOOT_ADDRESS is intentionally 0x08140000, the Non-secure code-bus alias. The following table describes only the non-TrustZone layout.

Fix: Qualify the paragraph as the non-TrustZone layout and retain the later TrustZone-specific alias description.

Suggestion:

Suggested change

	Each memory has four aliases, Secure/Non-secure by code/system bus. wolfBoot links at `0x18100400` and all `.config` addresses use the Secure code-bus QSPI alias:
	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: