You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This section explains the roles of OpenBMC and UEFI in the Arm server boot flow and why simulating their integration is essential for early-stage development.
10
11
11
-
This section explains the roles of OpenBMC and UEFI in the Arm server boot flow, and highlights why simulating their integration is essential for early-stage development.
12
-
13
-
### OpenBMC
12
+
### What is OpenBMC?
14
13
15
14
[OpenBMC](https://www.openbmc.org/) is a collaborative open-source firmware stack for Baseboard Management Controllers (BMC), hosted by the Linux Foundation.
16
-
BMCs are embedded microcontrollers on server motherboards that enable both in-band and out-of-band system management.
17
-
Out-of-band access allows remote management even when the host system is powered off or unresponsive, while in-band interfaces support communication with the host operating system during normal operation.
15
+
BMCs are embedded controllers on server motherboards that enable both in-band and out-of-band system management. Out-of-band access allows remote management even when the host is powered off or unresponsive, while in-band interfaces support communication with the host operating system during normal operation.
18
16
19
-
The OpenBMC stack is built using the Yocto Project and includes a Linux kernel, system services, D-Bus interfaces, and support for industry-standard APIs such as Redfish and IPMI. It provides features like hardware monitoring, fan control, power sequencing, sensor telemetry, event logging, BIOS configuration, and more.
17
+
The OpenBMC stack is built using the Yocto Project and includes a Linux kernel, system services, D-Bus interfaces, and support for industry-standard APIs such as Redfish and IPMI. It provides features like hardware monitoring, fan control, power sequencing, sensor telemetry, event logging, firmware/BIOS configuration, and more.
20
18
21
-
Its architecture is modular by design—each board or platform can define its own layers and packages through Yocto recipes, enabling custom extensions to firmware functionality without modifying upstream code.
19
+
Its architecture is modular. Each board or platform can define its own layers and packages through Yocto recipes, enabling custom extensions without modifying upstream code.
22
20
23
-
It is widely adopted by hyperscalers and enterprise vendors to manage servers, storage systems, and network appliances.
24
-
OpenBMC is particularly well-suited to Arm-based server platforms like **[Neoverse RD-V3](https://neoverse-reference-design.docs.arm.com/en/latest/platforms/rdv3.html)**, where it provides early-stage platform control and boot orchestration even before silicon is available.
21
+
OpenBMC is widely adopted by hyperscalers and enterprise vendors to manage servers, storage systems, and network appliances. It is particularly well-suited to Arm-based server platforms like **[Neoverse RD-V3](https://neoverse-reference-design.docs.arm.com/en/latest/platforms/rdv3.html)**, where it provides early-stage platform control and boot orchestration even before silicon is available.
25
22
26
23
**Key features of OpenBMC include:**
27
-
-**Remote management:** power control, Serial over LAN (SOL), and virtual media
28
-
-**Hardware health monitoring:** sensors, fans, temperature, voltage, and power rails
24
+
-**Remote management:** power control, Serial over LAN (SOL), virtual media
25
+
-**Hardware health monitoring:** sensors, fans, temperature, voltage, power rails
29
26
-**Firmware update mechanisms:** support for signed image updates and secure boot
30
-
-**Industry-standard APIs:** IPMI, Redfish, PLDM, and MCTP
31
-
-**Modular and extensible design:** device tree-based configuration and layered architecture
-**Modular, extensible design:** device tree-based configuration and layered architecture
32
29
33
30
OpenBMC enables faster development cycles, open innovation, and reduced vendor lock-in across data centers, cloud platforms, and edge environments.
34
31
35
-
In this Learning Path, you’ll simulate how OpenBMC manages the earlystage boot process, power sequencing, and remote access for a virtual Neoverse RD-V3 server. You will interact with the BMC console, inspect boot logs, and verify serial-over-LAN and UART communication with the host.
32
+
In this Learning Path, you’ll simulate how OpenBMC manages the early-stage boot process, power sequencing, and remote access for a virtual Neoverse RD-V3 server. You will interact with the BMC console, inspect boot logs, and verify SOL and UART communication with the host.
36
33
37
-
### UEFI
34
+
##What is UEFI?
38
35
39
-
The [Unified Extensible Firmware Interface (UEFI)](https://uefi.org/) is the modern replacement for legacy BIOS, responsible for initializing hardware and loading the operating system.
40
-
UEFI provides a robust, modular, and extensible interface between platform firmware and OS loaders. It supports:
36
+
The [Unified Extensible Firmware Interface (UEFI)](https://uefi.org/) is the modern replacement for legacy BIOS, responsible for initializing hardware and loading the operating system. UEFI provides a robust, modular, and extensible interface between platform firmware and OS loaders. It supports:
41
37
42
-
- A modular and extensible architecture
43
38
- Faster boot times and reliable system initialization
44
-
- Large storage device support using GPT (GUID Partition Table)
39
+
- Large-capacity device support using GPT (GUID Partition Table)
45
40
- Secure Boot for verifying boot integrity
46
-
- Pre-boot networking and diagnostics via UEFI Shell or applications
41
+
- Pre-boot networking and diagnostics using the UEFI Shell or applications
47
42
48
-
UEFI executes after the platform powers on and before the OS kernel takes over.
49
-
It discovers and initializes system hardware, configures memory and I/O, and launches the bootloader.
50
-
It is governed by the UEFI Forum and is now the standard firmware interface across server-class, desktop, and embedded systems.
43
+
UEFI executes after the platform powers on and before the OS kernel takes over. It discovers and initializes system hardware, configures memory and I/O, and launches the bootloader. It is governed by the UEFI Forum and is the standard firmware interface across server-class, desktop, and embedded systems.
51
44
52
-
In platforms that integrate OpenBMC, the BMC operates independently from the host CPU and manages platform power, telemetry, and recovery.
53
-
During system boot, UEFI and OpenBMC coordinate via mechanisms such as IPMI over KCS, PLDM over MCTP, or shared memory buffers.
45
+
In platforms that integrate OpenBMC, the BMC operates independently from the host CPU and manages platform power, telemetry, and recovery. During system boot, UEFI and OpenBMC coordinate via mechanisms such as IPMI over KCS, PLDM over MCTP, or shared memory buffers.
54
46
55
47
These interactions are especially critical in Arm server-class platforms—like Neoverse RD-V3—for secure boot, remote diagnostics, and system recovery during pre-silicon or bring-up phases.
| Boot power sequencing | BMC → Host| BMC controls host power-on flow, ensuring UEFI starts in the correct sequence |
54
+
| Boot status reporting | UEFI → BMC| UEFI reports boot state and progress via IPMI (KCS) or PLDM |
55
+
| Serial over LAN (SOL) | BMC ↔ Host| BMC bridges the host UART console to remote clients over the network |
56
+
| Pre-boot configuration | BMC ↔ UEFI| BMC may inject or read boot settings via shared memory or commands |
57
+
| System recovery signaling | UEFI → BMC| UEFI can request BMC-initiated reboot, NMI, or recovery actions |
69
58
70
-
You will use OpenBMC to power on the virtual Arm server, access the serial console, and monitor the host boot progress like real hardware platform. By inspecting the full boot log and observing system behavior in simulation, you will gain valuable insights into how BMC and UEFI coordinate during early firmware bring-up.
59
+
In this Learning Path, you will build and run the UEFI firmware on the RD-V3 FVP host platform. You will use OpenBMC to power on the virtual Arm server, access the serial console, and monitor host boot progress like real hardware. By inspecting the full boot log and observing system behavior in simulation, you will see how BMC and UEFI coordinate during early firmware bring-up.
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/2_openbmc_setup.md
+41-48Lines changed: 41 additions & 48 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,72 +1,66 @@
1
1
---
2
-
title: Set Up the Pre-Silicon Development Environment for OpenBMC and UEFI
2
+
title: Set up the development environment for OpenBMC and UEFI
3
3
weight: 3
4
4
5
5
### FIXED, DO NOT MODIFY
6
6
layout: learningpathall
7
7
---
8
8
9
-
## Set Up Development Environment
9
+
## Set up your development environment
10
10
11
-
In this section, you’ll prepare your workspace to build and simulate OpenBMC and UEFI firmware on the Neoverse RD-V3 platform using Arm Fixed Virtual Platforms (FVPs).
12
-
You will install the required tools, configure repositories, and set up a Docker-based build environment for both BMC and host firmware.
11
+
In this section, you prepare your workspace to build and simulate OpenBMC and UEFI firmware on the Neoverse RD-V3 r1 platform using Arm Fixed Virtual Platforms (FVPs). You will install the required tools, configure repositories, and set up a Docker-based build environment for both BMC and host firmware.
13
12
14
-
Before getting started, it’s strongly recommended to review the previous Learning Path: [CSS-V3 Pre-Silicon Software Development Using Neoverse Servers](https://learn.arm.com/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack).
15
-
It walks you through how to use the CSSv3 reference design on FVP to perform early-stage development and validation.
13
+
Before you start, review the related Learning Path [CSS-V3 pre-silicon software development using Neoverse servers](https://learn.arm.com/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack). It walks through using the CSSv3 reference design on FVP to perform early development and validation.
16
14
17
15
You will perform the steps outlined below on your Arm Neoverse-based Linux machine running Ubuntu 22.04 LTS. You will need at least 80 GB of free disk space, 48 GB of RAM.
18
16
19
-
###Install Required Packages
17
+
## Install the required packages
20
18
21
19
Install the base packages for building OpenBMC with the Yocto Project:
The FVP installation may prompt you with a few questions, choosing the default options is sufficient for this learning path. By default, the FVP will be installed in `$HOME/FVP_RD_V3_R1`.
51
-
50
+
Accept the defaults unless you have a reason not to. By default, the FVP installs under `$HOME/FVP_RD_V3_R1`.
To enable platform-specific functionality such as Redfish support and UEFI enhancements, apply a set of pre-defined patches from Arm’s GitLab repository.
63
+
These patches enable platform-specific functionality such as Redfish support and UEFI enhancements and align the build system with the RD-V3 FVP setup.
70
64
71
65
Use sparse checkout to download only the `patch/` folder:
This approach allows you to fetch only the `patch` folder from the remote Git repository—saving time and disk space.
76
+
This approach allows you to fetch only the `patch` folder from the remote Git repository - saving time and disk space.
83
77
84
78
Next, using a file editor of your choice, create an `apply_patch.sh` script inside the `~` directory and paste in the following content.
85
-
This script will automatically apply the necessary patches to each firmware component.
79
+
This script automatically applies the necessary patches to each firmware component:
86
80
87
81
```bash
88
82
FVP_DIR="host"
89
-
SOURCE=${PWD}
83
+
SOURCE="$HOME/host"
84
+
90
85
91
86
GREEN='\033[0;32m'
92
87
NC='\033[0m'
@@ -121,7 +116,7 @@ popd > /dev/null
121
116
popd> /dev/null
122
117
```
123
118
124
-
Run the patch script:
119
+
Run the script:
125
120
126
121
```bash
127
122
cd~
@@ -132,10 +127,10 @@ chmod +x ./apply_patch.sh
132
127
This script automatically applies patches to edk2, edk2-platforms, buildroot, and related components.
133
128
These patches enable additional UEFI features, integrate the Redfish client, and align the build system with the RD-V3 simulation setup.
134
129
135
-
###Build RDv3 R1 Host Docker Image
130
+
## Build RDv3 R1 host Docker image
136
131
137
132
Before building the host image, update the following line in `~/host/grub/bootstrap` to replace the `git://` protocol.
138
-
Some networks may restrict `git://` access due to firewall or security policies. Switching to `https://` ensures reliable and secure access to external Git repositories.
133
+
Some networks might restrict `git://` access due to firewall or security policies. Switching to `https://` ensures reliable and secure access to external Git repositories.
139
134
140
135
```bash
141
136
diff --git a/bootstrap b/bootstrap
@@ -150,7 +145,7 @@ usage() {
150
145
cat <<EOF
151
146
```
152
147
153
-
This command builds the Docker image used forcompiling the host firmware componentsin a controlled environment.
This [Arm Learning Path](/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/3_rdv3_sw_build/) provides a complete introduction to setting up the RDv3 development environment, please refer to it for more details.
214
-
{{% /notice %}}
215
-
208
+
See the Learning Path [Develop and Validate Firmware Pre-Silicon on Arm Neoverse CSS V3](/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/3_rdv3_sw_build/) for an introduction to setting up the RD-V3 development environment. {{% /notice %}}
216
209
217
-
### Build OpenBMC Image
210
+
## Build the OpenBMC image
218
211
219
-
OpenBMC is built on the Yocto Project, which uses `BitBake` as its build tool.
220
-
You don’t need to download BitBake separately, as it is included in the OpenBMC build environment.
221
-
Once you’ve set up the OpenBMC repository and initialized the build environment, BitBake is already available for building images, compiling packages, or running other tasks.
212
+
OpenBMC is built on the Yocto Project, which uses BitBake as its build tool. BitBake is included in the OpenBMC environment, so you do not install it separately.
222
213
223
-
Start by cloning and building the OpenBMC image using the bitbake build system:
214
+
Clone and build:
224
215
225
216
```bash
226
217
cd ~
@@ -230,7 +221,7 @@ source setup fvp
230
221
bitbake obmc-phosphor-image
231
222
```
232
223
233
-
During the OpenBMC build process, you may encounter a native compilation error when building `Node.js` (especially version 22+) due to high memory usage during the V8 engine build phase.
224
+
During the OpenBMC build process, you might encounter a native compilation error when building `Node.js` (especially version 22+) due to high memory usage during the V8 engine build phase.
234
225
235
226
```output
236
227
g++: fatal error: Killed signal terminated program cc1plus
@@ -287,10 +278,12 @@ NOTE: Executing Tasks
287
278
This confirms that the OpenBMC image was built successfully.
288
279
289
280
{{% notice Note %}}
290
-
The first build may take up to an hour depending on your system performance, as it downloads and compiles the entire firmware stack.
281
+
The first build can take up to an hour depending on system performance because it downloads and compiles the full firmware stack.
291
282
{{% /notice %}}
292
283
293
-
Your workspace should now be structured to separate the FVP, host build system, OpenBMC source, and patches—simplifying organization, maintenance, and troubleshooting.
284
+
## Workspace layout
285
+
286
+
Your workspace separates the FVP, host build system, OpenBMC source, and patches for easier maintenance and troubleshooting.
294
287
295
288
```output
296
289
├── FVP_RD_V3_R1
@@ -319,4 +312,4 @@ Your workspace should now be structured to separate the FVP, host build system,
319
312
└── run.sh
320
313
```
321
314
322
-
With both the OpenBMC and host firmware environments built and configured, you’re now fully prepared to launch the fullsystem simulation and observe the boot processin action.
315
+
With both the OpenBMC and host firmware environments built and configured, you are ready to launch full-system simulation and observe the boot process.
0 commit comments