wolfBoot can now boot a Microchip PolarFire SoC (MPFS250T) entirely on its own — no Hart Software Services (HSS) required — and bring up 4-CPU SMP Linux from a signed, verified image.
One bootloader, one root of trust
wolfBoot can now run in M-Mode directly on the E51 hart out of eNVM and handles all required initialization and setup to boot a full Yocto Linux image. It trains LPDDR4, configures the PLLs and clock muxes, releases the application harts, loads the next stage from QSPI/SD/eMMC, and verifies its signature before anything executes. The result is a single, auditable bootloader that owns the chip from the reset vector to the Linux kernel, instead of HSS plus a separate verification step. Including support for FIT images with compressed kernels and device tree fixups
Code Size: The current wolfBoot M-mode DDR+SBI+ECC384/SHA384 image is ~68 KB and easily fits in the 128KB eNVM space.
Boot Time: With wolfBoot’s full HSS replacement (acting as a minimal M-Mode SBI runtime for the kernel) we see Yocto Linux fully boot to login prompt in under 30 seconds on the PolarFire SoC Video Kit (MPFS250T) using SMP with four U54’s.
What wolfBoot took over from HSS
- LPDDR4 memory training: full DDR controller and PHY (TIP) bring-up: mode-register writes, VREF/ADDCMD training, write leveling, and read-gate calibration.
- Clock and PLL initialization: MSS PLL, DDR PLL, and clock-mux setup (40 MHz APB at reset, 150 MHz APB / 600 MHz CPU after lock).
- Peripheral resets: releasing the MMUART1-4 soft resets that HSS used to clear.
- Multi-hart SMP bring-up: releasing U54-1 into S-Mode and servicing SBI HSM hart_start calls so the kernel can online U54-2 through U54-4.
- Verified payload load: reading the next image from SC QSPI, SD, or eMMC and checking its signature.
- FIT Support: Support for device tree and kernel image including compression support.
- Device-tree fixups: enabling the U54 cores and adjusting nodes so the Linux SMP topology is correct.
Configuration options
wolfBoot ships ready-made configs in config/examples/. All targets are ARCH=RISCV64, TARGET=mpfs250,. By default we hash and sign with ECC384 + SHA384, however you can choose your own algorithms including hybrid schemes with PQC (ML-DSA, XMSS or LMS).
| Config file | Role | Mode | Hart | Boot media | Load target | DDR | Signature |
|---|---|---|---|---|---|---|---|
| polarfire_mpfs250_m_qspi.config | Replaces HSS | M-Mode | E51 | SC QSPI | L2 Scratch 0x0A000000 (app 0x0A020200) | No | ECC384 + SHA384 |
| polarfire_mpfs250_m.config | Replaces HSS | M → S | E51 → U54 | SD / eMMC | DDR 0x82000000, DTB 0x8A000000 | Yes | ECC384 + SHA384 |
| polarfire_mpfs250.config | Runs under HSS | S-Mode | U54 | SD / eMMC | DDR 0x8E000000 | Yes | ECC384 + SHA384 (or ML-DSA) |
| polarfire_mpfs250_qspi.config | Runs under HSS | S-Mode | U54 | SC QSPI | DDR 0x8E000000 | Yes | ECC384 + SHA384 |
| polarfire_mpfs250_hss_l2lim.config | Runs under HSS | S-Mode | U54 | SC QSPI | L2-LIM 0x08060000 | No | ECC384 + SHA384 |
The two _m* configs are the full HSS-replacement path: wolfBoot is the first software on the chip. The _m_qspi config boots a bare-metal application from on-chip L2 Scratch with no DDR at all, while the _m config trains DDR and hands off to SMP Linux (enabled with WOLFBOOT_MMODE_SMODE_BOOT). The remaining three configs coexist with HSS, running wolfBoot as the verified S-Mode payload — useful for incremental adoption.
How it works
In the M-Mode flow, the E51 starts from the eNVM reset vector, copies wolfBoot into L2 Scratch (0x0A000000), and runs hal_init to set up the L2 cache, UART, and per-hart state. wolfBoot then verifies the next image — ECC384 + SHA384 by default, with ML-DSA (FIPS 204) available for post-quantum signatures — before it trains DDR and releases U54-1 into S-Mode. From there, the kernel uses wolfBoot’s SBI runtime to online the remaining cores.
The root of trust is simple and static: the public key is built into the wolfBoot image at compile time. There is no runtime key provisioning, no network step, and no writable key store in the boot path. If the signature does not match, the image does not run.
Secure boot flow
The diagram below traces the full HSS-replacement path (polarfire_mpfs250_m.config) from reset to SMP Linux.
+----------------------------------------+
| Power-on reset: E51 (hart 0), M-Mode |
| boots from eNVM vector 0x20220100 |
+----------------------------------------+
|
v
+----------------------------------------+
| eNVM stub copies wolfBoot to |
| L2 Scratch (0x0A000000) and jumps |
+----------------------------------------+
|
v
+----------------------------------------+
| wolfBoot M-Mode bring-up: |
| L2 cache, MMUARTs, PLL/clocks, |
| LPDDR4 training, hal_init |
+----------------------------------------+
|
v
+----------------------------------------+
| Load signed image from SD/eMMC (or |
| QSPI) into DDR at 0x82000000 |
+----------------------------------------+
|
v
+----------------------------------------+
| Verify: SHA384 hash + ECC384 (or |
| ML-DSA) against the public key built |
| into wolfBoot |
+----------------------------------------+
| |
FAIL | | PASS
v v
+--------------------+ +-----------------------------+
| Halt - image is | | Device-tree fixups; install |
| not executed | | per-hart M-Mode SBI trap |
+--------------------+ | vector |
+-----------------------------+
|
v
+-----------------------------+
| Release U54-1 to S-Mode |
| (mret) -> Linux kernel |
+-----------------------------+
|
v
+-----------------------------+
| Kernel SBI HSM hart_start |
| brings U54-2..4 online |
+-----------------------------+
|
v
+-----------------------------+
| E51 stays in M-Mode: |
| resident SBI runtime + |
| watchdog monitor loop |
+-----------------------------+
What keeps running on the E51 monitor core?
After the handoff, the E51 never enters S-Mode and never runs Linux — it stays in M-Mode as the platform monitor, exactly the role HSS used to fill. Two things keep running there:
- The SBI runtime stays resident. wolfBoot installs its M-Mode SBI trap vector on every hart, each with its own M-Mode trap stack. When a U54 running Linux in S-Mode issues an ecall, it traps into M-Mode on that same hart and wolfBoot services it. The implemented SBI services cover BASE (version/probe), TIME (S-Mode timer), IPI, RFENCE (remote fence.i / sfence.vma), HSM (hart_start / hart_get_status), SRST (system reset), and DBCN (debug console), plus the legacy v0.1 calls. This is how the kernel onlines U54-2 through U54-4: E51 stages each hart’s entry point and rings its IPI, and the woken U54 transitions itself into S-Mode.
- The watchdog monitor loop. The MSS watchdogs always count and reset the chip on timeout, so E51 parks in a timer-driven wfi loop and pets all five watchdogs (E51 + U54-1..4) every few seconds — again taking over a job HSS used to own. The OS watchdog driver is left disabled in the device-tree fixup so the two never fight over the same timers.
The E51 is not idle after boot; it is the resident M-Mode firmware that keeps the watchdogs fed and answers every SBI call the Linux harts make for the life of the system.
Why this matters for FIPS 140-3 and DO-178C?
Collapsing the boot chain into one bootloader on certifiable cryptography is what makes PolarFire SoC attractive for regulated programs.
FIPS 140-3: wolfBoot’s crypto comes from wolfCrypt, which holds a FIPS 140-3 validation (certificate #4718). The algorithms available are NIST-standardized ECDSA P384 and ML-DSA (FIPS 204). For customers needing CNSA 2.0 compliance the PQC ML-DSA is available directly or as a hybrid with ECDSA.
DO-178C: wolfBoot’s M-Mode boot path is single-hart at startup, deterministic, and uses a fixed memory map with no dynamic allocation and no address randomization. That smaller, more predictable software surface (combined with wolfBoot being open and fully auditable) reduces the verification burden for teams pursuing DO-178C safety-critical certification.
What’s ahead
Next we are working on integrations with sNVM for keys, eNVM Boot ROM secure boot (to continue the hardware based Root of Trust chain), adding PUF KEK hardware support and TeraFire/Athena crypto hardware support.
We also support running our wolfTPM Firmware TPM 2.0 in an FPGA SoftCore Mi-V RISC-V, on the E51 monitor or on a dedicated U54 to provide full TPM 2.0 v1.85 (PQC) support.
Get started
The PolarFire SoC support is in the wolfBoot repository today, with the configs above and full bring-up notes in docs/. To evaluate wolfBoot for your PolarFire SoC design, or to discuss FIPS 140-3 and DO-178C support packages, contact us at facts@wolfssl.com.
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