Tweaks

Author: madeline-underwood

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

@@ -84,7 +84,7 @@ RSE acts as the second layer of the chain of trust, maintaining a monitored and
 * Manages DRAM setup and enables power for the AP
 * Coordinates boot readiness with RSE via the Message Handling Unit (MHU)
 
-## TF-A: Trusted Firmware-A (BL1/BL2) (Stage 3)
+### TF-A: Trusted Firmware-A (BL1/BL2) (Stage 3)
 
 * **BL1** executes from ROM, initializes minimal hardware (clocks, UART), and loads BL2  
 * **BL2** validates and loads SCP, RSE, and UEFI images, setting up secure handover to later stages
@@ -112,12 +112,12 @@ LCP support depends on the FVP model and can be omitted in simplified setups.
 
 The RD-V3 boot sequence follows a multi-stage, dependency-driven handshake model, where each firmware module validates, powers, or authorizes the next.
 
-| Stage | Dependency chain     | Description                                                                   |
+| Stage(s) | Dependency chain     | Description                                                                   |
 |------:|----------------------|-------------------------------------------------------------------------------|
 | 1     | RSE ← BL2            | RSE is loaded and triggered by BL2 to begin security validation              |
 | 2     | SCP ← BL2 + RSE      | SCP initialization requires BL2 and authorization from RSE                   |
 | 3     | AP ← SCP + RSE       | The AP starts only after SCP sets power and RSE permits                      |
-| 4     | UEFI → GRUB → Linux  | UEFI launches GRUB, which loads the kernel and enters the OS                 |
+| 4-5     | UEFI → GRUB → Linux  | UEFI launches GRUB, which loads the kernel and enters the OS                 |
 
 This handshake ensures no stage proceeds unless its dependencies have securely initialized and authorized the next step.
 
@@ -134,7 +134,7 @@ This layered approach supports modular testing, independent debugging, and early
 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 about the responsibilities of TF-A, RSE, SCP, MCP, LCP, and UEFI
 * Learned how secure boot is enforced and how each module hands off control
 * Interpreted boot dependencies using FVP simulation and UART logs
 

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

@@ -28,16 +28,18 @@ 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:
+The RD‑V3 platform firmware stack consists of multiple components, most maintained in separate Git respositories, such as:
 
 - TF‑A
-- SCP
-- RSE
-- UEFI
+- SCP/MCP
+- RSE (TF-M)
+- UEFI (EDK II)
 - Linux kernel
-- Buildroot. 
+- Buildroot
+- kvmtool (lkvm)
+- RMM (optional)
 
-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.
+Use the repo tool with the RD-V3 manifest to sync these sources from multiple upstreams consistently (typically to a pinned release tag). 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`:
 
@@ -182,7 +184,7 @@ your-username:hostname:/home/your-username/rdv3$
 You can explore the container environment if you wish, then type `exit` to return to the host.
 
 
-##  Step 4: Build firmware 
+## Step 4: Build firmware 
 
 Building the full firmware stack involves compiling several components and packaging them for simulation. The following command runs build and then package inside the Docker image:
 

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

@@ -10,7 +10,7 @@ layout: learningpathall
 
 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 of RD-V3-R! are:
+Key use cases of RD-V3-R1 are:
 
 - Simulating a chiplet-style boot flow with two APs
 - Observing coordination between SCP and MCP across dies

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

@@ -1,5 +1,5 @@
 ---
-title: CSS-V3 Pre-Silicon Software Development Using Neoverse Servers
+title: Develop and Validate Firmware Pre-Silicon on Arm Neoverse CSS V3
 
 minutes_to_complete: 90