# Simulate OpenBMC and UEFI pre-silicon on Neoverse RD-V3

## In this learning path

- [Introduction](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/)
- [What are OpenBMC and UEFI?](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/1_introduction_openbmc/)
- [Set up the development environment for OpenBMC and UEFI](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/2_openbmc_setup/)
- [Run OpenBMC and host UEFI simulation on RD-V3 FVP](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate/)
- [Monitor and control the host CPU using OpenBMC SOL and web UI](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/4_openbmc_communicate/)
- [Customize IPMI commands in OpenBMC](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/5_openbmc_ipmi/)
- [Next Steps](https://learn.arm.com/learning-paths/servers-and-cloud-computing/openbmc-rdv3/_next-steps/)

## About this Learning Path

| Skill level: | Advanced |
|--------------|----------|
| Reading time: | 2 hrs |
| Last updated: | 02 Oct 2026 |

| Authors: | 
|----------| 
| Odin Shen, Arm [GitHub](https://github.com/odincodeshen) [LinkedIn](https://linkedin.com/in/odin-shen-lmshen) |
| Ken Zhang, Insyde [LinkedIn](https://linkedin.com/in/kai-di-zhang-b1642a266) |

| Arm IP: | [Neoverse](https://support.arm.com/?tab=compute-ip&Product%20Type=Infrastructure%20Processors) |
|---------|---------------|
| Tags: |  [Containers and Virtualization](https://learn.arm.com/tag/containers-and-virtualization), [Linux](https://learn.arm.com/tag/linux), [C](https://learn.arm.com/tag/c), [Docker](https://learn.arm.com/tag/docker), [FVP](https://learn.arm.com/tag/fvp), [OpenBMC](https://learn.arm.com/tag/openbmc), [Yocto/BitBake](https://learn.arm.com/tag/yocto/bitbake), [ipmitool](https://learn.arm.com/tag/ipmitool) |

### Who is this for?
This advanced topic is for firmware developers, platform software engineers, and system integrators working on Arm Neoverse-based platforms. It is especially useful for developers exploring pre-silicon development, testing, and integration of Baseboard Management Controllers (BMC) with UEFI firmware. If you are building or validating server-class reference platforms such as RD-V3, before hardware is available, this Learning Path shows you how to simulate and debug the full boot path using Fixed Virtual Platforms (FVPs).

### What will you learn?
Upon completion of this Learning Path, you will be able to:
- Understand the role of OpenBMC and UEFI in the Arm server boot flow.
- Simulate the firmware using the RD-V3 FVP.
- Build and launch OpenBMC and UEFI images on the RD-V3 FVP.
- Validate host–BMC communication using UART and Serial over LAN (SoL).
- Implement and validate a custom IPMI command in OpenBMC.

### Prerequisites
Before starting, you will need the following:
- An Arm Neoverse-based Linux machine (cloud or local) running Ubuntu 22.04 LTS
- At least 80 GB free disk space and 48 GB RAM
- Working knowledge of Docker, Git, and common Linux terminal tools
- Basic understanding of the server firmware stack (such as UEFI, BMC, and TF-A)

### Summary
You’ll simulate an Arm server boot flow on the Neoverse RD-V3 r1 FVP. First, you’ll build OpenBMC and host UEFI images in a Docker environment. Then, you’ll launch the FVP and follow the firmware logs through multiple UART consoles. You’ll bridge virtual UARTs to validate SoL communication. Finally, you’ll add a C++ Intelligent Platform Management Interface (IPMI) handler to OpenBMC, rebuild the image, and verify its response.

### Frequently asked questions

<details>
<summary>What result should I expect when the RD-V3 FVP starts?</summary>
Multiple UART consoles open in separate terminal windows for different subsystems, such as Neoverse V3, Cortex-M55, Cortex-M7, and the Cortex-A BMC. You should see boot logs for both the BMC and host UEFI across these consoles.
</details>

<details>
<summary>Will the FVP UART consoles appear over SSH?</summary>
The consoles are graphical terminals and require a desktop session. If you’re connected over SSH only, the windows won’t render. To render the windows, launch the simulation from a desktop session.
</details>

<details>
<summary>Which ports should I bridge to enable SoL?</summary>
Use the provided bridge: `socat -x tcp:localhost:5005 tcp:localhost:5067`. Verify that these port mappings match the endpoints exposed by your running simulation.
</details>

<details>
<summary>After creating the UART bridge, what should I see when opening the host console from the BMC web UI?</summary>
The host console should be accessible through SoL and display the host’s console output. You should see ongoing boot messages or a prompt from the host side.
</details>

<details>
<summary>How do I validate that my custom IPMI command works?</summary>
Run `ipmitool raw 0x30 0x20` in the OpenBMC console. You’ll see hexadecimal bytes. Exclude the first byte, which represents the payload length, and decode the remaining bytes using the provided command. The decoded string should be `Hello from OpenBMC IPMI!`.
</details>