wolfBoot can now be the first stage boot loader (FSBL) on the AMD Zynq UltraScale+ MPSoC. The BootROM authenticates wolfBoot into the 256 KB OCM and enters it at EL3. wolfBoot brings up the processing system (PLLs, DDR, MIO, clocks) and boots Linux from a wolfBoot-signed FIT. Validated end to end on a ZCU102 to a PetaLinux login prompt.
The ZynqMP pairs quad Cortex-A53 cores with dual Cortex-R5F cores and programmable logic, which puts it in avionics and defense, industrial control, medical imaging, test and measurement, and software-defined radio. Those systems ship signed updates for a decade and have to show a documented root of trust. The silicon already has the parts (eFuse PPK, CSU, PUF); what it lacked was one owner of the keys from reset to the kernel.
- One signed stage. No zynqmp_fsbl.elf and no U-Boot in the boot image. wolfBoot verifies BL31, the kernel and the DTB with its own keys.
- Direct EL3 access to the CSU. With no ARM Trusted Firmware beneath it, wolfBoot reaches the security block over MMIO rather than SMC: read-only eFuse dump, PUF register and regenerate, and AES-256-GCM with a user key. eFuse programming is deliberately not implemented.
- A non-cacheable DMA window (hal_dma_set_noncached()) for bus masters that are not coherent with the CPU D-cache, which otherwise lose descriptor ownership bits to a cache line writeback.
- Optional Ethernet PHY init over GEM MDIO, off by default, replaying a board’s U-Boot PHY register sequence so the OS finds the PHY in the expected state.
- Post-quantum signing. This build signs with RSA-4096 / SHA3-384. wolfBoot also verifies ML-DSA (FIPS 204), LMS/HSS and XMSS (NIST SP 800-208); moving to one is a different SIGN= in the target config and a larger image header, not a change to the boot flow.
Two roots of trust are available and they stack. wolfBoot’s own keystore anchors everything downstream. Beneath it the Xilinx hardware root of trust is optional: burn the PPK hash into eFuses, set RSA_EN and package with zynqmp_wolfboot_fsbl_auth.bif, and the BootROM authenticates wolfBoot itself before it runs. Build with ZYNQMP_SEC=1 and wolfBoot reads SEC_CTRL and the PPK0 hash back out of the eFuse cache at boot, so you can confirm on the bench that a part is really locked.
Building it
Generate psu_init_gpl.c and psu_init_gpl.h for your board with the Xilinx tools and drop them in hal/board/zynqmp/. Then:
make ZYNQMP_FSBL=1 ZYNQMP_PSU_INIT_DIR=/path/to/hw-description cp wolfboot.elf pmufw.elf tools/scripts/zcu102/ cd tools/scripts/zcu102 bootgen -arch zynqmp -image zynqmp_wolfboot_fsbl.bif -w -o BOOT.BIN
Flash BOOT.BIN to QSPI with program_flash, set SW6 to QSPI32 and power-cycle. For SD boot, build with config/examples/zynqmp_fsbl_sd.config and write BOOT.BIN to the FAT partition.
Resources
- ZynqMP target documentation
- Post-quantum signature support
- FSBL, signed FIT boot and EL3 security
- Ethernet PHY init over GEM MDIO
- Non-cacheable DMA window
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