Merge pull request #2298 from pareenaverma/content_review

OpenBMC LP tech review

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/1_introduction_openbmc.md

@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## Introduction to OpenBMC and UEFI
 
-In this module, you will learn the roles of OpenBMC and UEFI in the Arm server boot flow, and understand why simulating their integration is key to early-stage development.
+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.
 
 ### OpenBMC
 
@@ -32,7 +32,7 @@ OpenBMC is particularly well-suited to Arm-based server platforms like **[Neover
 
 OpenBMC enables faster development cycles, open innovation, and reduced vendor lock-in across data centers, cloud platforms, and edge environments.
 
-**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.
+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.
 
 ### UEFI
 
@@ -67,4 +67,4 @@ These interactions are especially critical in Arm server-class platforms—like
 
 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 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.
+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.

content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/2_openbmc_setup.md

@@ -1,5 +1,5 @@
 ---
-title: Set Up Pre-Silicon Development Environment for OpenBMC and UEFI
+title: Set Up the Pre-Silicon Development Environment for OpenBMC and UEFI
 weight: 3
 
 ### FIXED, DO NOT MODIFY
@@ -8,27 +8,25 @@ layout: learningpathall
 
 ## Set Up Development Environment
 
-In this module, 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). 
-You’ll install the required tools, configure repositories, and set up a Docker-based build environment for both BMC and host firmware.
+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). 
+You will install the required tools, configure repositories, and set up a Docker-based build environment for both BMC and host firmware.
 
 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).
-That guide walks you through how to use the CSSv3 reference design on FVP to perform early-stage development and validation.
+It walks you through how to use the CSSv3 reference design on FVP to perform early-stage development and validation.
 
-Ensure your system meets the following requirements:
-- 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.
-- Working knowledge of Docker, Git, and Linux terminal tools
-- Basic understanding of server firmware stack (UEFI, BMC, TF-A, etc.)
-- Docker installed, or GitHub Codespaces-compatible development environment
+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.
 
 ### Install Required Packages
 
 Install the base packages for building OpenBMC with the Yocto Project:
 
 ```bash
 sudo apt update
-sudo apt install git gcc g++ make file wget gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2 unzip
+sudo apt install -y git gcc g++ make file wget gawk diffstat bzip2 cpio chrpath zstd lz4 bzip2 unzip
 ```
 
+Install [Docker](/install-guides/docker)
+
 ### Set Up the repo Tool
 
 ```bash
@@ -38,9 +36,9 @@ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo
 chmod a+rx ~/.bin/repo
 ```
 
-### Download the Arm FVP Model (RD-V3)
+### Download and Install the Arm FVP Model (RD-V3)
 
-Download and extract the RD-V3 FVP binary from Arm:
+Download and extract the RD-V3 FVP:
 ```bash
 mkdir ~/fvp
 cd ~/fvp
@@ -49,7 +47,7 @@ tar -xvf FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
 ./FVP_RD_V3_R1.sh
 ```
 
-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.
+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`.
 
 
 ### Initialize the Host Build Environment
@@ -59,12 +57,10 @@ Set up a workspace for host firmware builds:
 ```bash
 mkdir ~/host
 cd host
-
 ~/.bin/repo init -u "https://git.gitlab.arm.com/infra-solutions/reference-design/infra-refdesign-manifests.git" \
  -m "pinned-rdv3r1-bmc.xml" \
  -b "refs/tags/RD-INFRA-2025.07.03" \
  --depth=1
-
 repo sync -c -j $(nproc) --fetch-submodules --force-sync --no-clone-bundle
 ```
 
@@ -85,10 +81,10 @@ git pull origin main
 
 This approach allows you to fetch only the `patch` folder from the remote Git repository—saving time and disk space.
 
-Next, create an `apply_patch.sh` script inside the `~` directory and paste in the following content. 
+Next, using a file editor of your choice, create an `apply_patch.sh` script inside the `~` directory and paste in the following content. 
 This script will automatically apply the necessary patches to each firmware component.
 
-```patch
+```bash
 FVP_DIR="host"
 SOURCE=${PWD}
 
@@ -139,9 +135,9 @@ These patches enable additional UEFI features, integrate the Redfish client, and
 ### Build RDv3 R1 Host Docker Image
 
 Before building the host image, update the following line in `~/host/grub/bootstrap` to replace the `git://` protocol.
-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.
+Some networks may restrict `git://` access due to firewall or security policies. Switching to `https://` ensures reliable and secure access to external Git repositories.
 
-```
+```bash
 diff --git a/bootstrap b/bootstrap
 index 5b08e7e2d..031784582 100755
 --- a/bootstrap
@@ -174,10 +170,14 @@ docker run --rm \
   bash -c "./build-scripts/rdinfra/build-test-busybox.sh -p rdv3r1 all"
 ```
 
-Once complete, you can observe the build binary in `~/host/output/rdv3r1/rdv3r1/`
+Once complete, you can observe the build binary in `~/host/output/rdv3r1/rdv3r1/`:
 
-```
+```bash
 ls -la host/output/rdv3r1/rdv3r1/
+```
+The directory contents should look like:
+
+```output
 total 4308
 drwxr-xr-x 2 ubuntu ubuntu    4096 Aug 18 10:19 .
 drwxr-xr-x 4 ubuntu ubuntu    4096 Aug 18 10:20 ..
@@ -210,13 +210,13 @@ lrwxrwxrwx 1 ubuntu ubuntu      33 Aug 18 10:19 uefi.bin -> ../components/css-co
 
 
 {{% notice Note %}}
-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.
+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.
 {{% /notice %}}
 
 
 ### Build OpenBMC Image
 
-OpenBMC is built on the Yocto Project, which uses BitBake as its build tool.
+OpenBMC is built on the Yocto Project, which uses `BitBake` as its build tool.
 You don’t need to download BitBake separately, as it is included in the OpenBMC build environment. 
 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.
 
@@ -230,9 +230,9 @@ source setup fvp
 bitbake obmc-phosphor-image
 ```
 
-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.
+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.
 
-```log
+```output
 g++: fatal error: Killed signal terminated program cc1plus
 compilation terminated.
 ERROR: oe_runmake failed
@@ -249,9 +249,9 @@ PARALLEL_MAKE = "-j2"
 
 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.
 
-Once success build, you should see a successful build message similar to:
+With a successful build, you should see output similar to:
 
-```
+```output
 Loading cache: 100% |                                                                                                              | ETA:  --:--:--
 Loaded 0 entries from dependency cache.
 Parsing recipes: 100% |#############################################################################################################| Time: 0:00:09
@@ -290,9 +290,9 @@ This confirms that the OpenBMC image was built successfully.
 The first build may take up to an hour depending on your system performance, as it downloads and compiles the entire firmware stack.
 {{% /notice %}}
 
-Your workspace should now follow a structured layout that separates the FVP simulator, host build system, OpenBMC source, and patches—making it easier to organize, maintain, and troubleshoot your simulation environment.
+Your workspace should now be structured to separate the FVP, host build system, OpenBMC source, and patches—simplifying organization, maintenance, and troubleshooting.
 
-```text
+```output
 ├── FVP_RD_V3_R1
 ├── apply_patch.sh
 ├── fvp
@@ -319,4 +319,4 @@ Your workspace should now follow a structured layout that separates the FVP simu
 └── run.sh
 ```
 
-With both the OpenBMC and host firmware environments built and configured, you’re now fully prepared to launch the full system simulation and observe the boot process in action.
+With both the OpenBMC and host firmware environments built and configured, you’re now fully prepared to launch the full system simulation and observe the boot process in action.

content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/3_openbmc_simulate.md

@@ -1,5 +1,5 @@
 ---
-title: Run Pre-Silicon OpenBMC and Host UEFI Simulation
+title: Run OpenBMC and Host UEFI Simulation on RD-V3 FVP
 weight: 4
 
 ### FIXED, DO NOT MODIFY
@@ -11,39 +11,39 @@ layout: learningpathall
 With your environment prepared, you can now simulate the full pre-silicon firmware boot flow using the Arm Neoverse RD-V3 reference design.
 You’ll build the OpenBMC image, launch the Arm Fixed Virtual Platform (FVP), and observe the full boot process of both the BMC and host UEFI firmware in a simulated environment.
 
-This simulation launches multiple UART consoles—each mapped to a separate terminal window for different subsystems (e.g., Neoverse V3, Cortex‑M55, Cortex‑M7, and the Cortex-A BMC).
+This simulation launches multiple UART consoles,each mapped to a separate terminal window for different subsystems (e.g., Neoverse V3, Cortex‑M55, Cortex‑M7, and the Cortex-A BMC).
 
-These graphical terminal windows require a desktop session. If you're accessing the simulation over SSH (e.g., on an AWS instance), they may not display properly.
+These graphical terminal windows require a desktop session. If you're accessing the simulation over SSH (e.g., on a cloud instance), they may not display properly.
 
-To ensure proper display and interactivity, we recommend installing a Remote Desktop environment using XRDP.
+To ensure proper display and interactivity, it is recommended to install a Remote Desktop environment using XRDP.
 
-In AWS Ubuntu 22.04 instance, you need install required packages:
+On an Arm cloud Ubuntu 22.04 instance, you will need to install required packages:
 
 ```bash
 sudo apt update
 sudo apt install -y ubuntu-desktop xrdp xfce4 xfce4-goodies pv xterm sshpass socat retry
 sudo systemctl enable --now xrdp
 ```
 
-You may need to follow the Step 2 on RDv3 [learning path](https://learn.arm.com/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/4_rdv3_on_fvp/) to setup the networking and GDM configuration.
+You may need to follow the Step 2 on the [RD-V3 learning path](/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/4_rdv3_on_fvp/) to setup the networking and GDM configuration.
 
 Once connected via Remote Desktop, open a terminal and launch the RD‑V3 FVP simulation:
 
 ## Execute Pre-Silicon OpenBMC Simulation
 
-To make the simulation process smoother and more intuitive, you’ll need to modify a script from Arm’s GitLab repository.
+To make the simulation process more intuitive, you’ll need to modify a script from Arm’s GitLab repository:
 
 ```bash
 cd ~
 wget https://gitlab.arm.com/server_management/PoCs/fvp-poc/-/raw/2a79ae93560969a3b802dfb3d7d89f9fd9dee5a6/run.sh
 ```
 
-Before running the simulation, open the run.sh script and locate the line that defines FVP_KEYWORD.
+Before running the simulation, open the `run.sh` script and locate the line that defines FVP_KEYWORD.
 This variable determines when the host FVP should be launched by monitoring OpenBMC’s console output.
 If not set correctly, the script may hang or fail to start the host simulation.
 Update the line to:
 
-```
+```output
 FVP_KEYWORD="terminal2: Listening for serial connection on port"
 ```
 
@@ -65,7 +65,7 @@ The `run.sh` script will:
 
 Once the simulation is running, the `OpenBMC FVP console` will stop at the Linux login prompt:
 
-```
+```output
 [  OK  ] Started phosphor systemd target monitor.
 [  OK  ] Started Sensor Monitor.
          Starting Hostname Service...
@@ -81,14 +81,14 @@ Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) nodistro.0 fvp ttyA
 fvp login:
 ```
 
-Type OpenBMC default username `root` and password is `0penBmc`.
+Enter the OpenBMC default username `root` and password, which is `0penBmc`.
 
 
 {{% notice Note %}}
 The first character of the password is the number ***0***, not a capital ***O***.
 {{% /notice %}}
 
-After login, you’ll be dropped into the OpenBMC shell — a minimal Linux environment running inside the simulated BMC.
+After login, you will be dropped into the OpenBMC shell, a minimal Linux environment running inside the simulated BMC.
 
 The host-side UEFI simulation will appear in the `FVP terminal_ns_uart0` console. 
 You may briefly see the UEFI Firmware Setup Menu—select `Continue` to proceed with boot. 
@@ -102,8 +102,7 @@ A successful simulation will show login prompts on both BMC and host consoles. Y
 
 ![img2 alt-text#center](openbmc_cssv3_sim.jpg "Simuation Success")
 
-To avoid excessive network bandwidth usage, the following is a 60×-speed simulation recording.
-It gives you a quick visual overview of how OpenBMC and UEFI boot and interact during pre-silicon execution.
+Shown here is a simulation recording. It gives you a quick visual overview of how OpenBMC and UEFI boot and interact during pre-silicon execution.
 
 ![img1 alt-text#center](openbmc_cssv3_running.gif "Simuation Running")
 
@@ -116,5 +115,5 @@ After simulation completes, logs for both the BMC and host will be stored in `~/
 By reviewing the contents of the logs folder, you can verify the expected system behavior or quickly diagnose
 any anomalies that arise during boot or runtime.
 
-With the simulation running successfully, you’re now ready to perform real-time testing between the host and the BMC.  
-In the next module, you’ll explore how to interact with the BMC using UART and IPMI from the host side—validating communication channels in a pre-silicon context.
+With the simulation running successfully, you are now ready to perform real-time testing between the host and the BMC.  
+In the next section, you will explore how to interact with the BMC using UART and IPMI from the host side, validating communication channels in a pre-silicon context.

content/learning-paths/servers-and-cloud-computing/openbmc-rdv3/4_openbmc_communicate.md

@@ -8,8 +8,8 @@ layout: learningpathall
 
 ## Access the Host Console via OpenBMC SOL
 
-The OpenBMC platform provides `Serial over LAN` (SOL), allowing you to access the host console (RD-V3 FVP) remotely through the BMC—without needing a physical serial cable.
-In this module, you’ll use `socat` to create a virtual UART bridge, verify port mappings, and access the host console via the BMC Web UI.
+The OpenBMC platform provides `Serial over LAN` (SOL), allowing you to access the host console (RD-V3 FVP) remotely through the BMC, without needing a physical serial cable.
+In this section, you will use `socat` to create a virtual UART bridge, verify port mappings, and access the host console via the BMC Web UI.
 
 ### Step 1: Connect the BMC and Host Consoles
 
@@ -19,13 +19,13 @@ Run the following command on your development Linux machine (where the simulatio
 socat -x tcp:localhost:5005 tcp:localhost:5067
 ```
 
-This command connects the host-side UART port (5005) to the BMC-side port (5067), allowing bidirectional serial communication.
+This command connects the host-side UART port (5005) to the BMC-side port (5067), allowing bi-directional serial communication.
 
 {{% notice Note %}}
 If you see a Connection refused error, check the FVP logs to verify the port numbers:
-* In fvp_boot.log, look for a line like:
+* In `fvp_boot.log`, look for a line like:
 terminal_ns_uart0: Listening for serial connection on port 5005
-* In obmc_boot.log, confirm the corresponding line:
+* In `obmc_boot.log`, confirm the corresponding line:
 terminal_3: Listening for serial connection on port 5067
 {{% /notice %}}
 
@@ -56,15 +56,15 @@ This updates the BMC’s internal host state, allowing UEFI to begin execution.
    {{% notice Note %}}
    As a reminder, the first character of the password is the number ***0***, not a capital ***O***.
    {{% /notice %}}
-   After login, you'll see the Web UI dashboard:
+   After login, you should see the Web UI dashboard:
 
 - From the Overview page, click the `SOL Console` button.
    ![img4 alt-text#center](openbmc_webui_overview.jpg "WebUI Overview")
 
 - The SOL terminal in the Web UI will display the host console output (UEFI shell or Linux login). You can type commands directly as if you were connected over a physical serial line.
    ![img5 alt-text#center](openbmc_webui_sol.jpg "WebUI SOL")
 
-Once connected to the SOL terminal, you can monitor the UEFI boot sequence, interact with the host shell, and run diagnostic or recovery workflows—just as if you were connected to a physical serial port.
+Once connected to the SOL terminal, you can monitor the UEFI boot sequence, interact with the host shell, and run diagnostic or recovery workflows, just as if you were connected to a physical serial port.
 
 This confirms that OpenBMC is fully managing host power and console access in your simulated environment.