Pre-silicon simulation and validation of OpenBMC + UEFI on Neoverse RD-V3

This blog is co-authored by Odin Shen, Arm, Bryant Lee & Ken Zhang, Insyde Software.

If you are a platform firmware engineer, BMC developer, or system integration tester, you may have faced one or more of the following challenges:

• Your silicon has not taped out yet, but boot flow validation is already scheduled.
• You need to validate UEFI and OpenBMC coordination, but lack access to real hardware
• You need to test power-on sequences and IMPIIPMI responses in your CI pipeline

This Learning Path is designed for you.

With Arm’s Fixed Virtual Platform (FVP), you can simulate the full OpenBMC + UEFI boot process and implement your own custom IPMI handler before the silicon ready.

Why the BMC is critical in modern servers

In today’s servers, the Baseboard Management Controller (BMC) is more than a boot-time helper. It is the control hub for the entire platform.

• Cloud service providers use BMCs to manage tens of thousands of servers, enabling firmware updates, automated monitoring, and system recovery.
• OEM/ODM manufacturers use BMCs for power control, fan management, boot settings, and secure firmware updates.

Cloud providers: Centralized and scalable operations

• Use Redfish APIs to perform rolling firmware upgrades across thousands of nodes.
• Integrate OpenBMC sensors, KVM, and reset hooks into monitoring dashboards.
• Remotely trigger resets or recovery actions during hang-boot scenarios

OEM/ODM vendors: Platform manageability and customization

• Define precise power sequencing across voltage domains.
• Configure BIOS boot modes or PXE flows using the BMC.
• Implement secure firmware update mechanisms with rollback support.

OpenBMC: The open, industry-standard BMC stack

OpenBMC is an open-source project led by the Linux Foundation. It provides a modular, Yocto-based BMC firmware platform.

It supports standard management protocols such as IPMI, Redfish, PLDM, and MCTP. It is also highly customizable.

With OpenBMC, you can:

• Define custom machine profiles, for example meta-evb-fvp.
• Add Redfish endpoints or extend system and D-Bus services.
• Embed custom C++ IPMI handlers into firmware builds.

To learn more about the role of OpenBMC in shaping industry-wide server manageability standards, read this article Samer El-Haj-Mahmoud and Insyde Tim Lewis at Arm. It explains how Arm CSS and OpenBMC enable scalable, standardized BMC integration across the ecosystem.

CSS V3: Accelerating SoC and platform delivery

CSS-V3 is Arm’s Reference Compute Subsystem. It provides reusable boot firmware and SoC IP building blocks. For software developers, CSS-V3 offers:

• A clear and simulatable boot sequence, including TF-A, SCP, UEFI, RSE.
• Out-of-the-box FVP support for running host-side firmware without hardware.
• Integrated OpenBMC profiles, for example meta-evb-fvp, that support MCTP and IPMI out of the box.

No hardware? Still validate OpenBMC and UEFI

This learning path solves a common problem:

How do you validate coordination between BMC and UEFI firmware before you even have hardware?

We use a fully virtualized approach. An approach simulating boot flow, serial communication, MCTP/IPMI bridging, and OpenBMC-side control. All of this is executable on a developer workstation.

On a standard Ubuntu 22.04 workstation, you can:

• Build OpenBMC firmware using Yocto, which includes WebUI, SOL, and ipmitool.
  • Uses meta-evb-fvp and BitBake to produce custom images and integrate new IPMI handlers or D-Bus services.
• Build host-side RDV3 firmware, such as TF-A, SCP, and UEFI using Arm’s repo and Docker.
  • Leverages rdinfra-builder container with build-test-busybox.sh to generate fip-uefi.bin and platform binaries.
• Launch simulation via run.sh, starting both BMC and host FVPs with multiple UART consoles for observing boot logs, BMC shell, and UEFI output.
  • Recommended to run in a GUI session or via XRDP to see complete console output, including OpenBMC UART, ns_uart0, Cortex-M55, Cortex-M7.
• Bridge host and BMC UARTs using socat, and access the host via OpenBMC’s Web UI (SOL).
  • Validate custom IPMI commands and boot status reports through ipmitool raw.

The following animation shows a time-lapsed view of the entire simulation process:

• The right window shows OpenBMC firmware booting to a Linux shell.
• The left window shows the host-side SoC booting following the CSS-V3 boot sequence: TF-A → SCP → UEFI.
• When both systems are running, they communicate through UART and IPMI in a bridged simulation.

This simulation path is not just for early development. It is also a foundation for CI/CD automation and long-term platform bring-up workflows.

The virtual BMC runs the full OpenBMC userspace. It allows you to start real BMC services like Redfish or Web UI servers, and interact with them through standard interfaces during simulation. This enables you to prototype, test, and even automate BMC features without using hardware.

What you will learn in this path

• How to build and customize OpenBMC using BitBake.
• How to build and validate host-side UEFI firmware.
• How to bridge BMC and host UART via socat, and interact through the Web UI.
• How to write and register a custom IPMI handler (NetFn, Command ID).

Conclusion: Developer-driven firmware validation

This Learning Path removes hardware wait time and empowers developers to lead platform validation and prototyping. You can:

• Integrate simulation into CI pipelines to test boot success and failure flows.
• Prototype OEM extensions such as new IPMI commands or watchdog logic.
• Use the simulation for onboarding, demonstrations, and platform team training.

View the full tutorial: OpenBMC + UEFI Pre-Silicon Simulation