wolfBoot can now run as the First Stage Boot Loader (FSBL) on Xilinx ZynqMP, replacing the stock Xilinx FSBL entirely. On a ZCU102 (xczu9eg) the BootROM hands control straight to wolfBoot in on-chip memory (OCM) at EL3; wolfBoot brings up the processing system, verifies a signed image with its own keys, and boots Linux to a login prompt – validated end-to-end on real hardware. This moves your key-based verification to the earliest software stage the SoC runs, and it is a full-featured replacement: signed, compressed FIT images, direct programmable-logic loading, a silicon-anchored root of trust, and measured boot.
How it boots
The stock Xilinx chain runs the FSBL, PMU firmware, ARM Trusted Firmware (BL31), and U-Boot before Linux. As the FSBL, wolfBoot collapses that to one init-and-verify stage that hands straight to BL31 and on to Linux:
In that single stage wolfBoot runs psu_init() (PLLs, DDR, MIO, clocks, optional PS-GTR serdes), authenticates a wolfBoot-signed FIT carrying the kernel, BL31, and device tree (with optional compression), optionally programs an FPGA bitstream from that same signed FIT into the programmable logic, loads the PMU configuration, then hands off to BL31 – upstream Xilinx ARM Trusted Firmware plus a small device-tree-forwarding patch – which drops the kernel to a lower exception level. Removing the separate FSBL load and the U-Boot stage, and verifying the image once, should also reduce time-to-Linux; formal boot-time metrics are being collected for a follow-up.
Hardware root of trust at EL3
At EL3 with no firmware beneath it, wolfBoot drives the ZynqMP Crypto/Security Unit (CSU) engines directly: a read-only eFuse dump (security bits, PPK hash, PUF fields), PUF-derived device KEK regeneration, and hardware AES-256-GCM with the tag enforced. The same CSU driver tree is dual-mode – direct MMIO as the FSBL, secure-monitor calls as a normal-world image. Enabling Xilinx eFuse PPK RSA authentication anchors wolfBoot’s own image to a key hash burned into the device.
Algorithms and encryption
| Purpose | Options | Config tokens |
|---|---|---|
| Signature – classic | RSA-2048 / 3072 / 4096 (PKCS#1 v1.5 and PSS), ECDSA P-256 / P-384 / P-521, Ed25519, Ed448 | SIGN=RSA4096 / ECC384 / ED25519 … |
| Signature – post-quantum | LMS/HSS, XMSS/XMSS^MT (stateful hash-based), ML-DSA / Dilithium L2/L3/L5 (lattice) | SIGN=LMS / XMSS / ML_DSA |
| Signature – hybrid | Any classic + any PQ (e.g. ML-DSA-65 + ECDSA P-384) – two independent signatures over one image | SIGN=ML_DSA + SIGN_SECONDARY=ECC384 + WOLFBOOT_UNIVERSAL_KEYSTORE=1 |
| Hash | SHA-256, SHA-384, SHA3-384 | HASH=SHA3 on ZynqMP (hardware CSU SHA3) |
| Update-image encryption | AES-128-CTR, AES-256-CTR, ChaCha20; key can live in a TPM/HSM | ENCRYPT=1 (+ENCRYPT_WITH_AES256=1) |
| Hardware AES (CSU) | AES-256-GCM via the ZynqMP CSU engine (KUP / device key), tag enforced | ZYNQMP_SEC=1 |
The ZynqMP FSBL example ships with RSA-4096 + SHA3-384; the same tree builds any of the above, including a quantum-resistant or hybrid configuration for long-lived deployments.
Measured boot with a TPM
wolfBoot uses wolfTPM to extend PCRs with measurements of everything it loads, for an attestable TPM 2.0 record of the boot. Supply the TPM three ways: a firmware TPM in ARM TrustZone, a firmware TPM on a MicroBlaze-V (RISC-V) soft core in the PL, or an external physical TPM 2.0 over SPI. Both firmware-TPM paths are supported, with working reference examples you can build from.
Safety-critical certification
For programs pursuing DO-178C (up to DAL A), IEC 61508, or ISO 26262, collapsing the trusted boot chain to one auditable, open-source stage you build, sign, and certify yourself – portable C, FIPS 140-3-capable crypto, fewer independent binaries in the critical path – means a smaller certification surface.
Try it
cp config/examples/zynqmp_fsbl.config .config make ZYNQMP_FSBL=1 ZYNQMP_PSU_INIT_DIR=/path/to/board
The board-specific psu_init_gpl.c (Xilinx-tool-generated DDR/clock data for your board) is supplied at build time and is not in the tree. QSPI and SD-card boot are both supported; docs/Targets.md has the full walkthrough – building BL31, packaging BOOT.BIN with bootgen, boot-mode switches, and the FIT layout. Full implementation: wolfBoot PR #817.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now