We have added bare-metal wolfIP ports for three AMD/Xilinx PS-GEM SoCs, all brought up and measured on real hardware:
- ZCU102 – Zynq UltraScale+ MPSoC, Cortex-A53 (AArch64, EL3)
- VMK180 – Versal ACAP Gen 1, Cortex-A72 (AArch64, EL3)
- ZC702 – Zynq-7000, Cortex-A9 (ARMv7-A, SVC)
All three share a single source tree (each board’s Makefile build-selects its components, so the differences are real files rather than #ifdef forks), and a clean-room Cadence GEM Ethernet driver – no Xilinx Standalone BSP, no xparameters.h, no FreeRTOS. The whole TCP/IP stack runs on one core with no RTOS, no dynamic allocation, and no floating point, and is designed for safety-critical systems: certifiable to DO-178C up to DAL A.
What wolfIP brings to these SoCs
A complete, small IPv4 stack on bare metal: a DHCP client, ICMP echo, UDP and TCP over a BSD-style sockets API, ARP/neighbor handling, and the clean-room GEM MAC driver (BD rings, MDIO, DP83867 and Marvell 88E1518 PHYs, RGMII at 1 Gbps). The bring-up layer is included too: EL3/SVC startup, static MMU page tables, GICv2/GICv3, the PS-UART console, and a hardware-timer clock + entropy source.
Secure boot and signed updates under wolfBoot
The ZCU102 port ships as a complete, hardware-validated end-to-end demo with wolfBoot. The boot chain runs FSBL → PMUFW → BL31 → wolfBoot → signed wolfIP app, all the way to EL2, and wolfBoot verifies an RSA-4096 / SHA3 signature before every boot – a modified or unsigned image is refused. The DDR-layout image links at wolfBoot’s WOLFBOOT_LOAD_ADDRESS (0x10000000) and carries the header wolfBoot’s image format expects. (An OCM-only layout is also provided for FSBL/JTAG bring-up.)
The running application then performs its own network-delivered firmware update. It fetches a newer signed image over TFTP, writes it to the SD card’s update partition, and resets; wolfBoot verifies the update and boots the higher version, with automatic rollback if it ever fails to verify. The interesting part is how the app reaches the SD card: instead of handing control back to the bootloader, it drives the controller itself by compiling wolfBoot’s own SD-host and disk drivers straight into the application – the very same sdhci.c / disk.c source wolfBoot uses, fed by a small EL2 platform shim (register access, timer, SDMA cache maintenance). One driver, two consumers, no runtime hand-off. The whole secure-boot-plus-OTA loop is proven on ZCU102 hardware.
Performance
Single core, 1 GbE RGMII link, TCP, MTU 1500, measured with the built-in throughput server:
| Board (core) | Layout | RX (Mbps) | TX (Mbps) |
|---|---|---|---|
| VMK180 (Versal, A72) | DDR | ~300 | ~334 |
| ZCU102 (ZynqMP, A53) | DDR | ~126 | ~194 |
| ZC702 (Zynq-7000, A9) | DDR | ~59 | ~53 |
The dominant factor is the memory layout, not the protocol: running code cached from DDR (the wolfBoot path) is several times faster – up to ~13x on the A53 – than running uncached from on-chip RAM.
Code size
The full stack – wolfIP core + GEM driver + bare-metal runtime – is about 44 KB of code (.text) on every board (44 KB on ZCU102 and VMK180, 45 KB on ZC702) with only 8 bytes of .data. RAM use (~190 KB) is almost entirely the per-socket TCP windows and the GEM DMA rings, both tunable in config.h.
Get it
The ports live under src/port/amd/ with a README per board (build, JTAG and SD/BOOT.BIN flows, and the bring-up notes). Continuous integration builds every board x layout variant and boot-smokes the app under QEMU. The complete wolfBoot secure-boot + network-update demo for the ZCU102 – build scripts, signing, BOOT.BIN assembly and SD programming – lives in the wolfBoot examples repository.
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