Skip to content

Commit 38b6b8a

Browse files
committed
Simulate OpenBMC and UEFI Integration on Neoverse V3 Reference Design
1 parent 1cb0a21 commit 38b6b8a

14 files changed

+629
-1
lines changed

assets/contributors.csv

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -94,4 +94,5 @@ Peter Harris,Arm,,,,
9494
Chenying Kuo,Adlink,evshary,evshary,,
9595
William Liang,,,wyliang,,
9696
Waheed Brown,Arm,https://github.com/armwaheed,https://www.linkedin.com/in/waheedbrown/,,
97-
Aryan Bhusari,Arm,,https://www.linkedin.com/in/aryanbhusari,,
97+
Aryan Bhusari,Arm,,https://www.linkedin.com/in/aryanbhusari,,
98+
Ken Zhang, Insyde,,,,
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
title: Introduction to OpenBMC and UEFI
3+
weight: 2
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
OpenBMC and UEFI are foundational components in Arm-based server platforms. In this module, you’ll learn what they are, how they interact, and why simulating their integration on a pre-silicon reference design like RD-V3 is valuable for early-stage development and testing.
10+
11+
## Introduction to OpenBMC
12+
13+
[OpenBMC](https://www.openbmc.org/) is a collaborative open-source firmware stack for Baseboard Management Controllers (BMC), hosted by the Linux Foundation.
14+
BMCs are embedded microcontrollers on server motherboards that enable both in-band and out-of-band system management.
15+
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.
16+
17+
The OpenBMC stack is built using the Yocto Project and includes a Linux kernel, system services, D-Bus interfaces, Redfish/IPMI APIs, and support for hardware monitoring, fan control, power sequencing, and more.
18+
19+
It is widely adopted by hyperscalers and enterprise vendors to manage servers, storage systems, and network appliances.
20+
OpenBMC is particularly well-suited to Arm-based server platforms like **Neoverse RD-V3**, where it provides early-stage platform control and boot orchestration even before silicon is available.
21+
22+
**Key features of OpenBMC include:**
23+
- **Remote management:** power control, Serial over LAN (SOL), and virtual media
24+
- **Hardware health monitoring:** sensors, fans, temperature, voltage, and power rails
25+
- **Firmware update mechanisms:** support for signed image updates and secure boot
26+
- **Industry-standard APIs:** IPMI, Redfish, PLDM, and MCTP
27+
- **Modular and extensible design:** device tree-based configuration and layered architecture
28+
29+
OpenBMC enables faster development cycles, open innovation, and reduced vendor lock-in across data centers, cloud platforms, and edge environments.
30+
31+
**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 serial-over-LAN and UART communication with the host.
32+
33+
## Introduction to UEFI
34+
35+
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.
36+
UEFI provides a robust, modular, and extensible interface between platform firmware and OS loaders. It supports:
37+
38+
- A modular and extensible architecture
39+
- Faster boot times and reliable system initialization
40+
- Large storage device support using GPT (GUID Partition Table)
41+
- Secure Boot for verifying boot integrity
42+
- Pre-boot networking and diagnostics via UEFI Shell or applications
43+
44+
UEFI executes after the platform powers on and before the OS kernel takes over.
45+
It discovers and initializes system hardware, configures memory and I/O, and launches the bootloader.
46+
It is governed by the UEFI Forum and is now the standard firmware interface across server-class, desktop, and embedded systems.
47+
48+
In platforms that integrate OpenBMC, the BMC operates independently from the host CPU and manages platform power, telemetry, and recovery.
49+
During system boot, UEFI and OpenBMC coordinate via mechanisms such as IPMI over KCS, PLDM over MCTP, or shared memory buffers.
50+
51+
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.
52+
53+
**In this Learning Path**, you will build and run UEFI firmware on the RD-V3 FVP host platform, observe boot log output, and simulate how UEFI coordinates with OpenBMC via shared interfaces to complete system initialization.
54+
Lines changed: 322 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,322 @@
1+
---
2+
title: Set Up OpenBMC Development Environment
3+
weight: 3
4+
5+
### FIXED, DO NOT MODIFY
6+
layout: learningpathall
7+
---
8+
9+
## Set Up Development Environment
10+
11+
This module guides you through installing dependencies, configuring repositories, and preparing your workspace to simulate the OpenBMC and UEFI firmware stack on the Arm Neoverse RD-V3 platform using Fixed Virtual Platforms (FVPs).
12+
13+
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).
14+
That guide walks you through how to use the CSSv3 reference design on FVP to perform early-stage development and validation.
15+
16+
Ensure your system meets the following requirements:
17+
- Access to an Arm Neoverse-based Linux machine (either cloud-based or local) is required, with at least 80 GB of free disk space, 48 GB of RAM, and running Ubuntu 22.04 LTS.
18+
- Working knowledge of Docker, Git, and Linux terminal tools
19+
- Basic understanding of server firmware stack (UEFI, BMC, TF-A, etc.)
20+
- Docker installed, or GitHub Codespaces-compatible development environment
21+
22+
### Install Required Packages
23+
24+
Install the base packages for building OpenBMC with the Yocto Project:
25+
26+
```bash
27+
sudo apt update
28+
sudo apt install git gcc g++ make file wget gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2 unzip
29+
```
30+
31+
### Set Up the repo Tool
32+
33+
```bash
34+
mkdir -p ~/.bin
35+
PATH="${HOME}/.bin:${PATH}"
36+
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo
37+
chmod a+rx ~/.bin/repo
38+
```
39+
40+
### Download the Arm FVP Model (RD-V3)
41+
42+
Download and extract the RD-V3 FVP binary from Arm:
43+
```bash
44+
mkdir ~/fvp
45+
cd ~/fvp
46+
wget https://developer.arm.com/-/cdn-downloads/permalink/FVPs-Neoverse-Infrastructure/RD-V3-r1/FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
47+
tar -xvf FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
48+
./FVP_RD_V3_R1.sh
49+
```
50+
51+
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/ubuntu/FVP_RD_V3_R1.
52+
53+
54+
### Initialize the Host Build Environment
55+
56+
Set up a workspace for host firmware builds:
57+
58+
```bash
59+
mkdir ~/host
60+
cd host
61+
62+
~/.bin/repo init -u "https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign-manifests.git" \
63+
-m "pinned-rdv3r1-bmc.xml" \
64+
-b "refs/tags/RD-INFRA-2025.07.03" \
65+
--depth=1
66+
67+
repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle
68+
```
69+
70+
71+
72+
{{% notice Need Review %}}
73+
We need descript how to / where can download the patch file?
74+
{{% /notice %}}
75+
76+
Then, download the `patch.zip` from ... into root directory and unzip the file.
77+
78+
```bash
79+
unzip ~/patch.zip
80+
```
81+
82+
Create a file `~/apply_patch.sh` and copy following content into.
83+
84+
```patch
85+
FVP_DIR="host"
86+
SOURCE=${PWD}
87+
88+
GREEN='\033[0;32m'
89+
NC='\033[0m'
90+
91+
pushd ${FVP_DIR} > /dev/null
92+
echo -e "${GREEN}\n===== Apply patches to edk2 =====\n${NC}"
93+
pushd uefi/edk2
94+
git am --keep-cr ${SOURCE}/patch/edk2/*.patch
95+
popd > /dev/null
96+
97+
echo -e "${GREEN}\n===== Apply patches to edk2-platforms =====\n${NC}"
98+
pushd uefi/edk2/edk2-platforms > /dev/null
99+
git am --keep-cr ${SOURCE}/patch/edk2-platforms/*.patch
100+
popd > /dev/null
101+
102+
echo -e "${GREEN}\n===== Apply patches to edk2-redfish-client =====\n${NC}"
103+
git clone https://github.com/tianocore/edk2-redfish-client.git
104+
pushd edk2-redfish-client > /dev/null
105+
git checkout 4f204b579b1d6b5e57a411f0d4053b0a516839c8
106+
git am --keep-cr ${SOURCE}/patch/edk2-redfish-client/*.patch
107+
popd > /dev/null
108+
109+
echo -e "${GREEN}\n===== Apply patches to buildroot =====\n${NC}"
110+
pushd buildroot > /dev/null
111+
git am ${SOURCE}/patch/buildroot/*.patch
112+
popd > /dev/null
113+
114+
echo -e "${GREEN}\n===== Apply patches to build-scripts =====\n${NC}"
115+
pushd build-scripts > /dev/null
116+
git am ${SOURCE}/patch/build-scripts/*.patch
117+
popd > /dev/null
118+
popd > /dev/null
119+
```
120+
121+
Next, apply patches to the `host`.
122+
123+
```bash
124+
chmod +x ./apply_patch.sh
125+
./apply_patch.sh
126+
```
127+
128+
{{% notice Need Review %}}
129+
We need descript more about what's the patch?
130+
{{% /notice %}}
131+
132+
133+
### Build RDv3 R1 Host Docker Image
134+
135+
Before building the host image, update the following line in `~/host/grub/bootstrap` to replace the `git://` protocol.
136+
Some networks or corporate environments restrict `git://` access due to firewall or security policies. Switching to `https://` ensures reliable and secure access to external Git repositories.
137+
138+
```
139+
diff --git a/bootstrap b/bootstrap
140+
index 5b08e7e2d..031784582 100755
141+
--- a/bootstrap
142+
+++ b/bootstrap
143+
@@ -47,7 +47,7 @@ PERL="${PERL-perl}"
144+
me=$0
145+
-default_gnulib_url=git://git.sv.gnu.org/gnulib
146+
+default_gnulib_url=https://git.savannah.gnu.org/git/gnulib.git
147+
usage() {
148+
cat <<EOF
149+
```
150+
151+
```bash
152+
cd ~/host/container-scripts
153+
./container.sh build
154+
```
155+
156+
Within the `host` directory, run:
157+
158+
```bash
159+
docker run --rm \
160+
-v $HOME/host:$HOME/host \
161+
-w $HOME/host \
162+
--env ARCADE_USER=$(id -un) \
163+
--env ARCADE_UID=$(id -u) \
164+
--env ARCADE_GID=$(id -g) \
165+
-t -i rdinfra-builder \
166+
bash -c "./build-scripts/rdinfra/build-test-busybox.sh -p rdv3r1 all"
167+
```
168+
169+
Once complete, you can observe the build binary in `~/host/output/rdv3r1/rdv3r1/`
170+
171+
```
172+
ls -la host/output/rdv3r1/rdv3r1/
173+
total 4308
174+
drwxr-xr-x 2 ubuntu ubuntu 4096 Aug 18 10:19 .
175+
drwxr-xr-x 4 ubuntu ubuntu 4096 Aug 18 10:20 ..
176+
lrwxrwxrwx 1 ubuntu ubuntu 25 Aug 18 10:19 Image -> ../components/linux/Image
177+
lrwxrwxrwx 1 ubuntu ubuntu 35 Aug 18 10:19 Image.defconfig -> ../components/linux/Image.defconfig
178+
-rw-r--r-- 1 ubuntu ubuntu 4402315 Aug 18 10:19 fip-uefi.bin
179+
lrwxrwxrwx 1 ubuntu ubuntu 34 Aug 18 10:19 lcp_ramfw.bin -> ../components/rdv3r1/lcp_ramfw.bin
180+
lrwxrwxrwx 1 ubuntu ubuntu 33 Aug 18 10:19 lcp_ramfw_ns -> ../components/rdv3r1/lcp_ramfw_ns
181+
lrwxrwxrwx 1 ubuntu ubuntu 26 Aug 18 10:19 lkvm -> ../components/kvmtool/lkvm
182+
lrwxrwxrwx 1 ubuntu ubuntu 34 Aug 18 10:19 mcp_ramfw.bin -> ../components/rdv3r1/mcp_ramfw.bin
183+
lrwxrwxrwx 1 ubuntu ubuntu 33 Aug 18 10:19 mcp_ramfw_ns -> ../components/rdv3r1/mcp_ramfw_ns
184+
lrwxrwxrwx 1 ubuntu ubuntu 28 Aug 18 10:19 rmm.img -> ../components/rdv3r1/rmm.img
185+
lrwxrwxrwx 1 ubuntu ubuntu 34 Aug 18 10:19 scp_ramfw.bin -> ../components/rdv3r1/scp_ramfw.bin
186+
lrwxrwxrwx 1 ubuntu ubuntu 33 Aug 18 10:19 scp_ramfw_ns -> ../components/rdv3r1/scp_ramfw_ns
187+
lrwxrwxrwx 1 ubuntu ubuntu 41 Aug 18 10:19 signed_lcp_ramfw.bin -> ../components/rdv3r1/signed_lcp_ramfw.bin
188+
lrwxrwxrwx 1 ubuntu ubuntu 41 Aug 18 10:19 signed_mcp_ramfw.bin -> ../components/rdv3r1/signed_mcp_ramfw.bin
189+
lrwxrwxrwx 1 ubuntu ubuntu 41 Aug 18 10:19 signed_scp_ramfw.bin -> ../components/rdv3r1/signed_scp_ramfw.bin
190+
lrwxrwxrwx 1 ubuntu ubuntu 31 Aug 18 10:19 tf-bl1.bin -> ../components/rdv3r1/tf-bl1.bin
191+
lrwxrwxrwx 1 ubuntu ubuntu 30 Aug 18 10:19 tf-bl1_ns -> ../components/rdv3r1/tf-bl1_ns
192+
lrwxrwxrwx 1 ubuntu ubuntu 31 Aug 18 10:19 tf-bl2.bin -> ../components/rdv3r1/tf-bl2.bin
193+
lrwxrwxrwx 1 ubuntu ubuntu 32 Aug 18 10:19 tf-bl31.bin -> ../components/rdv3r1/tf-bl31.bin
194+
lrwxrwxrwx 1 ubuntu ubuntu 55 Aug 18 10:19 tf_m_flash.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/tf_m_flash.bin
195+
lrwxrwxrwx 1 ubuntu ubuntu 48 Aug 18 10:19 tf_m_rom.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/rom.bin
196+
lrwxrwxrwx 1 ubuntu ubuntu 50 Aug 18 10:19 tf_m_vm0_0.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/vm0_0.bin
197+
lrwxrwxrwx 1 ubuntu ubuntu 50 Aug 18 10:19 tf_m_vm0_1.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/vm0_1.bin
198+
lrwxrwxrwx 1 ubuntu ubuntu 50 Aug 18 10:19 tf_m_vm1_0.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/vm1_0.bin
199+
lrwxrwxrwx 1 ubuntu ubuntu 50 Aug 18 10:19 tf_m_vm1_1.bin -> ../components/arm/rse/neoverse_rd/rdv3r1/vm1_1.bin
200+
lrwxrwxrwx 1 ubuntu ubuntu 33 Aug 18 10:19 uefi.bin -> ../components/css-common/uefi.bin
201+
```
202+
203+
204+
{{% notice Note %}}
205+
The other [Arm Learning Path](https://learn.arm.com/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/3_rdv3_sw_build/) provides a complete introduction to setting up the RDv3 development environment — feel free to refer to it for more details.
206+
{{% /notice %}}
207+
208+
209+
### Build OpenBMC Image
210+
211+
you need use [BitBake](https://docs.yoctoproject.org/bitbake/) to build OpenBMC.
212+
213+
{{% notice Need Review %}}
214+
215+
216+
Should we need install bitbake?
217+
218+
```bash
219+
git clone https://git.openembedded.org/bitbake
220+
cd bitbake
221+
```
222+
How to install bitbake? Clone https://git.openembedded.org/bitbake or else?
223+
{{% /notice %}}
224+
225+
Start by cloning and building the OpenBMC image using the bitbake build system:
226+
227+
```bash
228+
cd ~
229+
git clone https://github.com/openbmc/openbmc.git
230+
cd openbmc
231+
source setup fvp
232+
bitbake obmc-phosphor-image
233+
```
234+
235+
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 depends on your build machine.
236+
237+
```
238+
g++: fatal error: Killed signal terminated program cc1plus
239+
compilation terminated.
240+
ERROR: oe_runmake failed
241+
```
242+
243+
This is a typical Out-of-Memory (OOM) failure, where the system forcibly terminates the compiler due to insufficient available memory.
244+
245+
To reduce memory pressure, explicitly limit parallel tasks in `conf/local.conf`:
246+
247+
```bash
248+
BB_NUMBER_THREADS = "2"
249+
PARALLEL_MAKE = "-j2"
250+
```
251+
252+
This ensures that BitBake only runs two parallel tasks and that each Makefile invocation limits itself to two threads. It significantly reduces peak memory usage and avoids OOM terminations.
253+
254+
Once success build, you will observe the message like:
255+
256+
```
257+
Loading cache: 100% | | ETA: --:--:--
258+
Loaded 0 entries from dependency cache.
259+
Parsing recipes: 100% |#############################################################################################################| Time: 0:00:09
260+
Parsing of 3054 .bb files complete (0 cached, 3054 parsed). 5148 targets, 770 skipped, 0 masked, 0 errors.
261+
NOTE: Resolving any missing task queue dependencies
262+
263+
Build Configuration:
264+
BB_VERSION = "2.12.0"
265+
BUILD_SYS = "aarch64-linux"
266+
NATIVELSBSTRING = "ubuntu-22.04"
267+
TARGET_SYS = "aarch64-openbmc-linux"
268+
MACHINE = "fvp"
269+
DISTRO = "openbmc-phosphor"
270+
DISTRO_VERSION = "nodistro.0"
271+
TUNE_FEATURES = "aarch64 armv8-4a"
272+
TARGET_FPU = ""
273+
meta
274+
meta-oe
275+
meta-networking
276+
meta-python
277+
meta-phosphor
278+
meta-arm
279+
meta-arm-toolchain
280+
meta-arm-bsp
281+
meta-evb
282+
meta-evb-fvp-base = "master:1b6b75a7d22262ec1bf5ab8e2bfa434ac84d981b"
283+
284+
Sstate summary: Wanted 0 Local 0 Mirrors 0 Missed 0 Current 2890 (0% match, 100% complete)############################### | ETA: 0:00:00
285+
Initialising tasks: 100% |##########################################################################################################| Time: 0:00:03
286+
NOTE: Executing Tasks
287+
288+
```
289+
290+
{{% notice Note %}}
291+
The first build may take up to an hour depending on your system performance, as it downloads and compiles the entire firmware stack.
292+
{{% /notice %}}
293+
294+
295+
```text
296+
├── FVP_RD_V3_R1
297+
├── apply_patch.sh
298+
├── fvp
299+
│   ├── FVP_RD_V3_R1.sh
300+
│   ├── FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
301+
│   └── license_terms
302+
├── host
303+
│   ├── build-scripts
304+
│   ├── buildroot
305+
│   ├── ...
306+
├── openbmc
307+
│   ├── ...
308+
│   ├── build
309+
│   ├── meta-arm
310+
│   ├── ...
311+
│   ├── poky
312+
│   └── setup
313+
├── patch
314+
│   ├── build-scripts
315+
│   ├── buildroot
316+
│   ├── edk2
317+
│   ├── edk2-platforms
318+
│   └── edk2-redfish-client
319+
├── patch.zip
320+
└── run.sh
321+
322+
``

0 commit comments

Comments
 (0)