SUPERVISOR IMPLEMENTATION, BOOT CONTROL AND DIAGNOSTICS on OBC-Hyper-Polar
- April 30, 2026
- CAVU Aerospace UK
WHERE THE SUPERVISOR LIVES
The supervisor on the OBC HYPER-2 is not a separate FPGA or ASIC. It runs on the E51 monitor core that is built into the Microchip PolarFire SoC. The SoC contains five RISC-V harts inside a single die:
- 1 × E51 — 64-bit RV64IMAC, single-issue, in-order. This is the monitor / supervisor core.
- 4 × U54 — 64-bit RV64GC, dual-issue, in-order. These run the application (Linux, Zephyr, FreeRTOS, or bare-metal, depending on configuration).
The E51 has its own L1 caches and dedicated access to the DTIM/ITIM scratchpad and to the L2 cache configurable as scratchpad. Because the E51 sits at the same level as the U54 application cores in the MSS, it can monitor them in real time without going through any external bus.
The software that runs on the E51 is the open-source Hart Software Services (HSS). HSS is used unmodified at the architectural level; CAVU adds project-specific state machines and FDIR hooks that link HSS to the rest of the OBC.
WHAT THE HSS / E51 SUPERVISOR DOES
HSS executes a deterministic, layered sequence at every power-up and stays resident afterwards. Concretely it provides:
- First-stage boot from the SoC embedded non-volatile memory (eNVM / µPROM). The MSS comes out of reset directly into HSS code on the E51.
- Secure boot verification. HSS validates the SHA-256 hash and (optionally) the X.509-signed manifest of the next-stage payload before any U54 is released from reset.
- Payload extraction from the chosen QSPI NOR flash bank / eMMC into DDR4 / LPDDR4. The payload is a single signed binary built by the HSS Payload Generator tool from a YAML configuration; it can contain one image per U54.
- Per-hart launch. Each U54 is individually configured (priv-mode, entry point, device-tree blob pointer, S-mode or M-mode) and released from reset. CAVU runs U54₀-U54₃ in S-mode under a Linux kernel.
- Runtime supervisor services. After boot the E51 stays alive and exposes the OpenSBI / RISC-V SBI interface to the U54 cores. Every system call from the application kernel — timer, IPI, TLB, console, power, system reset, vendor extensions — is serviced by HSS on the E51, isolated from the U54 cores.
- Independent watchdog and FDIR. The E51 owns the MSS hardware watchdog and a heartbeat protocol with each U54. If a U54 misses its heartbeat or trips its WDT, the E51 alone reboots the offending hart, logs the event into a non-volatile counter in MRAM, and — if configured — rolls back to a known-good image.
- Power-mode and clock-gating arbitration for the MSS during low-power transitions.
- Console / command CLI on a dedicated MMUART. This is the user-visible side of HSS at integration and during return-to-base diagnostics.
HOW TO CONTROL THE BOOT SEQUENCE
There are three independent control surfaces:
Compile time — via the HSS YAML configuration. The boot policy is defined in the project’s hss-config.yaml (or hss-payload.yaml) and compiled into the HSS binary that lives in eNVM. The YAML lets you set, per U54:
- entry address and execution mode (M-mode bare-metal, S-mode under Linux, F-mode out of L2-as-scratchpad);
- which payload bank (Boot Image A / Boot Image B) is preferred;
- secure-boot policy (mandatory signature check, advisory, or off);
- size and offset of the payload region inside QSPI;
- watchdog window per hart.
The same YAML drives the HSS Payload Generator, which packages the U54 binaries plus optional fabric design into a single signed payload blob written to QSPI or eMMC.
Operational time — via the HSS console. The MMUART exposes an interactive shell with commands such as version, boot, mmc, usbdmsc, ymodem, qspi, payload, crypto, info. Typical flows:
- boot forces an immediate boot using the configured policy.
- payload lets you query the current payload header, hash, and verification result.
- ymodem accepts a fresh payload over the UART and writes it to the chosen QSPI bank or eMMC.
- qspi erase / qspi write give direct flash control under operator authority.
Run time — via SBI vendor calls from the application. CAVU adds a small set of vendor-extension SBI calls that the application running on the U54 cores can invoke to request, for example, “schedule next boot from Bank B”, “mark current image bad”, “request safe-mode reboot”. These calls are processed by HSS on the E51 and persist their result in MRAM, so they survive a power cycle.
HOW TO CONTROL WHICH IMAGE IS LOADED
Two QSPI NOR flash banks (“Boot Image A” and “Boot Image B”) plus a small persistent record in SPI MRAM define the boot order. At every boot HSS performs:
- Read the active-bank pointer in MRAM and select the corresponding QSPI bank.
- Verify the payload header, length and SHA-256 hash. Verify the signature if secure boot is enabled.
- If verification passes, extract the payload, launch the U54 cores, and increment the bank’s “good-boot” counter in MRAM.
- If verification fails or the U54 cores fail to reach the heartbeat in the configured grace period, swap the active-bank pointer to the other bank, reboot, and continue.
- After two successive failures HSS enters safe-mode: it stays resident on the E51, exposes the console, and waits for ground action.
The active bank, the boot counters, and the last-known-good signature are all readable and writable through the HSS console (info, mmc, payload status) and through the SBI vendor calls listed above.
A third path exists for development and rescue: HSS can boot from a payload uploaded over the MMUART (ymodem flow) without writing it to flash. This is locked out by a fuse for flight units.
DIAGNOSTICS
Three independent channels provide diagnostics:
- HSS console (MMUART) — full boot log, secure-boot verdicts, payload metadata, boot counters, last-fault reason. Default 115 200 baud, 8N1. Available at every reset, including before any U54 is alive.
- HK telemetry from the application — once Linux is up, the U54 monitor task exposes the same data over the spacecraft TM bus: BOOT_STATUS register, active bank, hash digest of the running payload, MRAM wear counters, ECC corrected/uncorrected counts, WDT trip count per hart.
- Persistent log in MRAM — every reset reason, every secure-boot verdict, every bank swap, every WDT trip is appended to a circular log in SPI MRAM with a CRC. The log survives complete power loss and is downloadable on demand.
