Further improvements

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/1_introduction_rdv3.md

@@ -64,7 +64,7 @@ Key capabilities of FVPs:
 
 FVPs enable developers to verify boot sequences, debug firmware handoffs, and even simulate RSE (Runtime Security Engine) behaviors, all pre-silicon.
 
-## Comparing RD-V3 FVP variants
+## Compare RD-V3 FVP variants
 
 To support different use cases and levels of platform complexity, Arm offers several virtual models based on the CSS-V3 architecture: RD-V3, RD-V3-R1, RD-V3-Cfg1 (CFG1), and RD-V3-Cfg2 (CFG2). While they share a common foundation, they differ in chip count, system topology, and simulation flexibility.
 

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/2_rdv3_bootseq.md

@@ -10,7 +10,7 @@ layout: learningpathall
 
 To ensure the platform transitions securely and reliably from power-on to operating system launch, this section introduces the roles and interactions of each firmware component within the RD-V3 boot process. You’ll learn how each component contributes to system initialization and how control is systematically handed off across the boot chain.
 
-## How the system boots up
+## Booting the system up
 
 In the RD-V3 platform, each firmware component  such as TF-A, RSE, SCP, MCP, LCP, and UEFI operates independently but participates in a well-defined sequence. Each is delivered as a separate firmware image, yet they coordinate tightly through a structured boot flow and inter-processor signaling.
 
@@ -24,14 +24,14 @@ After BL2, the Runtime Security Engine (RSE, Cortex-M55) authenticates critical
 
 ***RSE acts as the platform’s security gatekeeper.***
 
-## Stage 2: Early hardware initialization (SCP / MCP)
+## Stage 2: Early hardware initialization (SCP/MCP)
 
 Once RSE completes verification, the System Control Processor (SCP, Cortex-M7) and the Management Control Processor (MCP, where present) are released from reset.
 
 They perform essential bring-up:
-* Initialize clocks, reset lines, and power domains
-* Prepare DRAM and interconnect
-* Enable the application processor (AP) cores and signal readiness to TF-A
+* Initializing clocks, reset lines, and power domains
+* Preparing DRAM and interconnect
+* Enabling the application processor (AP) cores and signaling readiness to TF-A
 
 ***SCP/MCP are the ground crew bringing hardware systems online.***
 
@@ -45,21 +45,21 @@ When the AP is released, it begins executing Trusted Firmware-A (TF-A) at EL3 fr
 
 TF-A hands off control to UEFI firmware (EDK II), which performs device discovery and launches GRUB.
 
-Responsibilities:
-* Detect and initialize memory, PCIe, and boot devices
-* Generate ACPI and platform configuration tables
-* Locate and launch GRUB from storage or flash
+Responsibilities here include:
+* Detecting and initializing memory, PCIe, and boot devices
+* Generating ACPI and platform configuration tables
+* Locating and launching GRUB from storage or flash
 
 ***EDK II and GRUB are like the first- and second-stage rockets launching the payload.***
 
 ## Stage 5: Linux kernel boot
 
 GRUB loads the Linux kernel and passes full control to the OS.
 
-Responsibilities:
-* Initialize device drivers and kernel subsystems
-* Mount the root filesystem
-* Start user-space processes (for example, BusyBox)
+Responsibilities include:
+* Initializing device drivers and kernel subsystems
+* Mounting the root filesystem
+* Starting user-space processes (for example, BusyBox)
 
 ***The Linux kernel is the spacecraft - it takes over and begins its mission.***
 
@@ -127,9 +127,12 @@ For example, `RSE ← BL2` means BL2 loads/triggers RSE; `AP ← SCP + RSE` mean
 The right-facing arrows in `UEFI → GRUB → Linux` indicate a **direct execution path**—each stage passes control directly to the next.
 {{% /notice %}}
 
-This layered approach supports modular testing, independent debugging, and early simulation—essential for secure and robust platform bring-up.
+This layered approach supports modular testing, independent debugging, and early simulation, which is essential for secure and robust platform bring-up.
+
+## Summary
+
+In this section, you have:
 
-**In this section, you have:**
 * Explored the full boot sequence of the RD-V3 platform, from power-on to Linux login
 * Understood the responsibilities of TF-A, RSE, SCP, MCP, LCP, and UEFI
 * Learned how secure boot is enforced and how each module hands off control

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/3_rdv3_sw_build.md

@@ -5,27 +5,39 @@ weight: 4
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
+
 ## Building the RD-V3 Reference Platform Software Stack
 
 In this module, you’ll set up your development environment on any Arm-based server and build the firmware stack required to simulate the RD-V3 platform. This Learning Path was tested on an AWS `m7g.4xlarge` Arm-based instance running Ubuntu 22.04.
 
-## Step 1: Prepare the Development Environment
+## Step 1: Set up your development environment
 
-First, ensure your system is up to date and install the required tools and libraries:
+First, check that your system is current and install the required dependencies:
 
 ```bash
 sudo apt update
 sudo apt install -y curl git
 ```
-Configure git as follows:
+
+Configure git:
+
 ```
 git config --global user.name "<your-name>"
 git config --global user.email "<[email protected]>"
 ```
 
 ## Step 2: Fetch the source code
 
-The RD‑V3 platform firmware stack consists of many independent components, such as TF‑A, SCP, RSE, UEFI, Linux kernel, and Buildroot. Each component is maintained in a separate Git repository. To manage and synchronize these repositories efficiently, use the `repo` tool. It simplifies syncing the full platform software stack from multiple upstreams.
+The RD‑V3 platform firmware stack consists of many independent components, such as:
+
+- TF‑A
+- SCP
+- RSE
+- UEFI
+- Linux kernel
+- Buildroot. 
+
+Each component is maintained in a separate Git repository. To manage and synchronize these repositories efficiently, use the `repo` tool. It simplifies syncing the full platform software stack from multiple upstreams.
 
 If `repo` is not installed, you can download it and add it to your `PATH`:
 

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/4_rdv3_on_fvp.md

@@ -8,11 +8,9 @@ layout: learningpathall
 
 ## Simulating RD-V3 with an Arm FVP
 
-In the previous section, you built the complete CSS-V3 firmware stack.  
-Now you’ll use an Arm Fixed Virtual Platform (FVP) to simulate the system, allowing you to verify the boot sequence without any physical silicon.  
-This simulation brings up the full stack from BL1 to a Linux shell using Buildroot.
+In the previous section, you built the complete CSS-V3 firmware stack. Now you’ll use an Arm Fixed Virtual Platform (FVP) to simulate the system, allowing you to verify the boot sequence without any physical silicon. This simulation brings up the full stack from BL1 to a Linux shell using Buildroot.
 
-## Step 1: Download and Install the FVP Model
+## Step 1: Download and install the FVP model
 
 Each reference design release tag corresponds to a specific FVP model version.  
 For example, the **RD-INFRA-2025.07.03** tag is designed to work with **FVP version 11.29.35**.
@@ -29,15 +27,15 @@ tar -xvf FVP_RD_V3_11.29_35_Linux64_armv8l.tgz
 ./FVP_RD_V3.sh
 ```
 
-The FVP installation might prompt you with a few questions,choosing the defaults is sufficient for this Learning Path. By default, the FVP installs under `/home/ubuntu/FVP_RD_V3`.
+The FVP installation might prompt you with a few questions, choose the default settings. By default, the FVP installs under `/home/ubuntu/FVP_RD_V3`.
 
-## Step 2: remote desktop setup
+## Step 2: set up remote desktop 
 
 The RD‑V3 FVP model launches multiple UART consoles. Each console is mapped to a separate terminal window for different subsystems (for example, Neoverse V3, Cortex‑M55, Cortex‑M7, panel).
 
 If you’re accessing the platform over SSH, these UART consoles can still be displayed, but network latency and graphical forwarding can severely degrade performance.
 
-To interact with different UARTs more efficiently, it is recommend to install a remote desktop environment using `XRDP`. This provides a smoother user experience when dealing with multiple terminal windows and system interactions.
+To interact with different UARTs more efficiently, install a remote desktop environment using `XRDP`. This provides a smoother user experience when dealing with multiple terminal windows and system interactions.
 
 Install required packages and enable XRDP:
 
@@ -49,6 +47,7 @@ sudo systemctl enable --now xrdp
 ```
 
 To allow remote desktop connections, you need to open port 3389 (RDP) in your AWS EC2 security group:
+
 - Go to the EC2 Dashboard → Security Groups
 - Select your instance’s group → **Inbound rules** → **Edit inbound rules**
 - Add a rule: Type: RDP, Port: 3389, Source: your public IP (recommended)
@@ -63,9 +62,11 @@ For better security, limit the source to your current public IP instead of 0.0.0
 ## Switch to Xorg (required on Ubuntu 22.04)
 
 Wayland is the default display server on Ubuntu 22.04, but it is not compatible with XRDP.  
-To enable XRDP remote sessions, you must switch to Xorg by modifying the GDM configuration.
+To enable XRDP remote sessions, you must switch to Xorg by modifying the GDM configuration:
+
+Open the `/etc/gdm3/custom.conf` in a text editor. 
 
-Open the `/etc/gdm3/custom.conf` in a text editor. Find the line: 
+Find the line: 
 
 ```output
 #WaylandEnable=false
@@ -78,15 +79,16 @@ WaylandEnable=false
 ```
 
 Restart the GDM display manager:
+
 ```bash
 sudo systemctl restart gdm3
 ```
 
-After restart, XRDP sessions will use Xorg and you can connect to it in the Arm server using Remote Desktop.
+After restart, XRDP sessions will use Xorg and you can connect to it in the Arm server using a remote desktop.
 
 ## Step 3: launch the simulation
 
-Once connected using Remote Desktop, open a terminal and launch the RD‑V3 FVP simulation:
+Once connected using a remote desktop, open a terminal and launch the RD‑V3 FVP simulation:
 
 ```bash
 cd ~/rdv3/model-scripts/rdinfra

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/5_rdv3_modify.md

@@ -6,17 +6,17 @@ weight: 6
 layout: learningpathall
 ---
 
-## Build and run the RD-V3-R1 dual-chip platform
+## The RD-V3-R1 dual-chip platform
 
 The RD-V3-R1 platform is a dual-chip simulation environment built to model multi-die Arm server SoCs. It expands on the single-die RD-V3 design by introducing a second application processor and a Management Control Processor (MCP).
 
-### Key use cases
+Key use cases of RD-V3-R! are:
 
 - Simulating a chiplet-style boot flow with two APs
 - Observing coordination between SCP and MCP across dies
 - Testing secure boot in a distributed firmware environment
 
-### Key differences from RD-V3
+Key differences from RD-V3 are:
 
 - Dual AP boot flow instead of a single AP
 - MCP (Cortex-M7) to support cross-die management
@@ -38,19 +38,21 @@ repo sync -c -j "$(nproc)" --fetch-submodules --force-sync --no-clone-bundle
 
 Refer to the [RD-V3-R1 Release Tags](https://neoverse-reference-design.docs.arm.com/en/latest/platforms/rdv3.html#release-tags) to pick the FVP version that matches your tag, then download and install it: 
 
-
+```bash
 mkdir -p ~/fvp
 cd ~/fvp
 wget https://developer.arm.com/-/cdn-downloads/permalink/FVPs-Neoverse-Infrastructure/RD-V3-r1/FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
 tar -xvf FVP_RD_V3_R1_11.29_35_Linux64_armv8l.tgz
 ./FVP_RD_V3_R1.sh
 ```
 
-## Step 3: Build the Firmware
+## Step 3: Build the firmware
 
-If you built the Docker image earlier, you can reuse it for RD-V3-R1. Run the full build and package flow:
+If you built the Docker image earlier, you can reuse it for RD-V3-R1. 
 
+Run the full build and package flow:
 
+```bash
 cd ~/rdv3r1
 docker run --rm \
   -v "$PWD:$PWD" \
@@ -67,6 +69,7 @@ docker run --rm \
 ## Step 4: Launch the simulation
 
 From a desktop session on the build host, start the RD-V3-R1 FVP:
+
 ```bash
 cd ~/rdv3r1/model-scripts/rdinfra
 export MODEL="$HOME/FVP_RD_V3_R1/models/Linux64_armv8l_GCC-9.3/FVP_RD_V3_R1"  # adjust if your path/toolchain differs

content/learning-paths/servers-and-cloud-computing/neoverse-rdv3-swstack/_index.md

@@ -3,14 +3,16 @@ title: CSS-V3 Pre-Silicon Software Development Using Neoverse Servers
 
 minutes_to_complete: 90
 
-who_is_this_for: This Learning Path is for firmware developers, system architects, and silicon validation engineers building Arm Neoverse CSS platforms. It focuses on pre-silicon development for the CSS-V3 reference design using Fixed Virtual Platforms (FVPs). You’ll build, customize, and validate firmware on the RD-V3 platform before hardware is available.
+who_is_this_for: This advanced topic is for firmware developers, system architects, and silicon validation engineers working on Arm Neoverse CSS platforms who require a pre-silicon workflow for the CSS-V3 reference design using Fixed Virtual Platforms (FVPs).
 
 learning_objectives:
-    - Understand the architecture of Arm Neoverse CSS-V3 as the foundation for scalable server-class platforms
-    - Build and boot the RD-V3 firmware stack using TF-A, SCP, RSE, and UEFI
-    - Simulate multi-core, multi-chip systems with Arm FVP models and interpret boot logs
-    - Modify platform control firmware to test custom logic and validate via pre-silicon simulation
-
+    - Explain the CSS-V3 architecture and the RD-V3 firmware boot sequence (TF-A, RSE, SCP/MCP/LCP, UEFI/GRUB, Linux)
+    - Set up a containerized build environment and sync sources with a pinned manifest using repo
+    - Build and boot the RD-V3 firmware stack on FVP and map UART consoles to components
+    - Interpret boot logs to verify bring-up and diagnose boot-stage issues
+    - Modify platform control firmware (for example, SCP/MCP) and validate changes via pre-silicon simulation
+    - Launch a dual-chip RD-V3-R1 simulation and verify AP/MCP coordination
+   
 prerequisites:
     - Access to an Arm Neoverse-based Linux machine (cloud or local) with at least 80 GB of free storage
     - Familiarity with Linux command-line tools and basic scripting