CSS-V3 Pre-Silicon learning path

assets/contributors.csv

@@ -94,4 +94,5 @@ Peter Harris,Arm,,,,
 Chenying Kuo,Adlink,evshary,evshary,,
 William Liang,,,wyliang,,
 Waheed Brown,Arm,https://github.com/armwaheed,https://www.linkedin.com/in/waheedbrown/,,
-Aryan Bhusari,Arm,,https://www.linkedin.com/in/aryanbhusari,,
+Aryan Bhusari,Arm,,https://www.linkedin.com/in/aryanbhusari,,
+Ken Zhang, Insyde,,,,

content/learning-paths/cross-platform/zenoh-multinode-ros2/_index.md

@@ -51,7 +51,7 @@ further_reading:
         type: documentation
     - resource:
         title: Zenoh and ROS 2 Integration Guide
-        link: https://github.com/eclipse-zenoh/zenoh-plugin-ros2
+        link: https://github.com/eclipse-zenoh/zenoh-plugin-ros2dds
         type: documentation
 
 

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

@@ -0,0 +1,82 @@
+---
+title: Introducing the Arm RD‑V3 Platform
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Introduction to the Arm RD‑V3 Platform
+
+This module introduces the Arm [Neoverse CSS‑V3](https://www.arm.com/products/neoverse-compute-subsystems/css-v3) architecture and the RD‑V3 [Reference Design Platform Software](https://neoverse-reference-design.docs.arm.com/en/latest/index.html) that implements it. You'll learn how these components enable scalable, server-class system design, and how to simulate and validate the full firmware stack using Fixed Virtual Platforms (FVP)—well before hardware is available.
+
+Arm Neoverse is designed to meet the demanding requirements of data center and edge computing, delivering high performance and efficiency. Widely adopted in servers, networking, and edge devices, the Neoverse architecture provides a solid foundation for modern infrastructure.
+
+Using Arm Fixed Virtual Platforms (FVPs), you can explore system bring-up, boot flow, and firmware customization well before physical silicon becomes available.
+
+This module also introduces the key components involved, from Neoverse V3 cores to secure subsystem controllers, and shows how these elements work together in a fully virtualized system simulation.
+
+### Neoverse CSS-V3 Platform Overview
+
+[Neoverse CSS-V3](https://www.arm.com/products/neoverse-compute-subsystems/css-v3) (Compute Subsystem Version 3) is the core subsystem architecture underpinning the Arm RD-V3 platform. It is specifically optimized for high-performance server and data center applications, providing a highly integrated solution combining processing cores, memory management, and interconnect technology.
+
+CSS V3 forms the key building block for specialized computing systems. It reduces design and validation costs for the general-purpose compute subsystem, allowing partners to focus on their specialization and acceleration while reducing risk and accelerating time to deployment. 
+
+CSS‑V3 is available in configurable subsystems, supporting up to 64 Neoverse V3 cores per die. It also enables integration of high-bandwidth DDR5/LPDDR5 memory (up to 12 channels), PCIe Gen5 or CXL I/O (up to 64 lanes), and high-speed die-to-die links with support for UCIe 1.1 or custom PHYs. Designs can be scaled down to smaller core-count configurations, such as 32-core SoCs, or expanded through multi-die integration.
+
+Key features of CSS-V3 include:
+
+* High-performance CPU clusters: Optimized for server workloads and data throughput.
+
+* Advanced memory management: Efficient handling of data across multiple processing cores.
+
+* Interconnect technology: Enabling high-speed, low-latency communication within the subsystem.
+
+The CSS‑V3 subsystem is fully supported by Arm's Fixed Virtual Platform, enabling pre-silicon testing of these capabilities.
+
+### RD‑V3 Platform Introduction
+
+The RD‑V3 platform is a comprehensive reference design built around Arm’s [Neoverse V3](https://www.arm.com/products/silicon-ip-cpu/neoverse/neoverse-v3) CPUs, along with [Cortex-M55](https://www.arm.com/products/silicon-ip-cpu/cortex-m/cortex-m55) and [Cortex-M7](https://www.arm.com/products/silicon-ip-cpu/cortex-m/cortex-m7) microcontrollers. This platform enables efficient high-performance computing and robust platform management:
+
+
+| Component     | Description                                                                 |
+|---------------|-----------------------------------------------------------------------------|
+| Neoverse V3   | The primary application processor responsible for executing OS and payloads |
+| Cortex M7     | Implements the System Control Processor (SCP) for power, clocks, and init   |
+| Cortex M55    | Hosts the Runtime Security Engine (RSE), providing secure boot and runtime integrity |
+
+These subsystems work together in a coordinated architecture, communicating through shared memory regions, control buses, and platform protocols. This enables multi-stage boot processes and robust secure boot implementations.
+
+Here is the Neoverse Reference Design Platform [Software Stack](https://neoverse-reference-design.docs.arm.com/en/latest/about/software_stack.html#sw-stack) for your reference.
+
+![img1 alt-text#center](rdinfra_sw_stack.jpg "Neoverse Reference Design Software Stack")
+
+
+### Develop and Validate Without Hardware
+
+In traditional development workflows, system validation cannot begin until silicon is available—often introducing risk and delay. 
+
+To address this, Arm provides the Fixed Virtual Platform ([FVP](https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms)) —a  complete simulations model that emulates full Arm SoC behavior on a host machine. The CSS‑V3 platform is available in multiple FVP configurations, allowing developers to select the model that best fits their specific development and validation needs.
+
+
+Key Capabilities of FVP:
+* Multi-core CPU simulation with SMP boot
+* Multiple UART interfaces for serial debug and monitoring
+* Compatible with TF‑A, UEFI, GRUB, and Linux kernel images
+* Provides boot logs, trace outputs, and interrupt event visibility for debugging
+
+FVP enables developers to verify boot sequences, debug firmware handoffs, and even simulate RSE behaviors—all before first silicon.
+
+### Comparing different version of RD-V3 FVP
+
+To support different use cases and levels of platform complexity, Arm offers three virtual models based on the CSS‑v3 architecture: RD‑V3, RD-V3-Cfg1, and RD‑V3‑R1. While they share a common foundation, they differ in chip count, system topology, and simulation flexibility.
+
+| Model       | Description                                                      | Recommended Use Cases                                              |
+|-------------|------------------------------------------------------------------|--------------------------------------------------------------------|
+| RD‑V3       | Standard single-die platform with full processor and security blocks | Ideal for newcomers, firmware bring-up, and basic validation        |
+| RD‑V3‑R1    | Dual-die platform simulating chiplet-based architecture          | Suitable for multi-node, interconnect, and advanced boot tests     |
+| CFG1        | Lightweight model with reduced control complexity for fast startup | Best for CI pipelines, unit testing, and quick validations         |
+
+
+This Learning Path begins with RD‑V3 as the primary platform for foundational exercises, guiding you through the process of building the software stack and simulating it on FVP to verify the boot sequence.
+In later modules, you’ll transition to RD‑V3‑R1 to more advanced system simulation, multi-node bring-up, and firmware coordination across components like MCP and SCP.

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

@@ -0,0 +1,160 @@
+---
+title: Understanding the CSS V3 Boot Flow and Firmware Stack
+weight: 3
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+## Firmware Stack Overview and Boot Sequence Coordination
+
+To ensure the platform transitions securely and reliably from power-on to operating system launch, this module introduces the roles and interactions of each firmware component within the RD‑V3 boot process.
+You’ll learn how each module contributes to system initialization and how control is systematically handed off across the boot chain.
+
+
+## How the System Wakes Up
+
+In the RD‑V3 platform, each subsystem—such as TF‑A, RSE, SCP, LCP, and UEFI—operates independently but cooperates through a well-defined sequence. 
+Each module is delivered as a separate firmware image, yet they coordinate tightly through a structured boot flow and inter-processor signaling.
+
+The following diagram from the [Neoverse Reference Design Documentation](https://neoverse-reference-design.docs.arm.com/en/latest/shared/boot_flow/rdv3_single_chip.html?highlight=boot) illustrates the progression of component activation from initial reset to OS handoff:
+
+![img1 alt-text#center](rdf_single_chip.png "Boot Flow for RD-V3 Single Chip")
+
+### Stage 1. Security Validation Starts First (RSE)
+
+The first firmware module triggered after BL2 is the Runtime Security Engine (RSE), executing on Cortex‑M55. RSE authenticates all critical firmware components—including SCP, UEFI, and kernel images—using secure boot mechanisms. It performs cryptographic measurements and builds a Root of Trust before allowing any other processors to start.
+
+***RSE acts as the platform’s security gatekeeper.***
+
+### Stage 2. Early Hardware Initialization (SCP / MCP)
+
+Once RSE completes verification, the System Control Processor (SCP) and Management Control Processor (MCP) are released from reset.
+
+These controllers perform essential platform bring-up:
+* Initialize clocks, reset lines, and power domains
+* Prepare DRAM and interconnect
+* Enable the application cores and signal readiness to TF‑A
+
+***SCP/MCP are the ground crew bringing hardware systems online.***
+
+### Stage 3. Secure Execution Setup (TF‑A)
+
+Once the AP is released, it begins executing Trusted Firmware‑A (TF‑A) at EL3, starting from the reset vector address programmed during boot image layout.
+TF‑A configures the secure world, sets up exception levels, and prepares for handoff to UEFI.
+
+***TF‑A is the ignition controller, launching the next stages securely.***
+
+### Stage 4. Firmware and Bootloader (EDK2 / GRUB)
+
+TF‑A hands off control to UEFI firmware (EDK2), 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
+
+***EDK2 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 (e.g., BusyBox)
+
+***The Linux kernel is the spacecraft—it takes over and begins its mission.***
+
+## Firmware Module Responsibilities in Detail
+
+Now that we’ve examined the high-level boot stages, let’s break down each firmware module’s role in more detail.
+
+Each stage of the boot chain is backed by a dedicated component—either a secure bootloader, platform controller, or operating system manager—working together to ensure a reliable system bring-up.
+
+### RSE: Runtime Security Engine (Cortex‑M55) (Stage 1: Security Validation)
+
+RSE firmware runs on the Cortex‑M55 and plays a critical role in platform attestation and integrity enforcement.
+* Authenticates BL2, SCP, and UEFI firmware images (Secure Boot)
+* Records boot-time measurements (e.g., PCRs, ROT)
+* Releases boot authorization only after successful validation
+
+RSE acts as the second layer of the chain of trust, maintaining a monitored and secure environment throughout early boot.
+
+
+### SCP: System Control Processor (Cortex‑M7) (Stage 2: Early Hardware Bring-up)
+
+SCP firmware runs on the Cortex‑M7 core and performs early hardware initialization and power domain control.
+* Initializes clocks, reset controllers, and system interconnect
+* Manages DRAM setup and enables power for the application processor
+* Coordinates boot readiness with RSE via MHU (Message Handling Unit)
+
+SCP is central to bring-up operations and ensures the AP starts in a stable hardware environment.
+
+### TF-A: Trusted Firmware-A (BL1 / BL2) (Stage 3: Secure Execution Setup)
+
+TF‑A is the entry point of the boot chain and is responsible for establishing the system’s root of trust.
+* BL1 (Boot Loader Stage 1): Executes from ROM, initializing minimal hardware such as clocks and serial interfaces, and loads BL2.
+* BL2 (Boot Loader Stage 2): Validates and loads SCP, RSE, and UEFI images, setting up secure handover to later stages.
+
+TF‑A ensures all downstream components are authenticated and loaded from trusted sources, laying the foundation for a secure boot.
+
+
+### UEFI / GRUB / Linux Kernel (Stage 4–5: Bootloader and OS Handoff)
+
+After SCP powers on the application processor, control passes to the main bootloader and operating system:
+* UEFI (EDK2): Provides firmware abstraction, hardware discovery, and ACPI table generation
+* GRUB: Selects and loads the Linux kernel image
+* Linux Kernel: Initializes the OS, drivers, and launches the userland (e.g., BusyBox)
+
+On the FVP, you can observe this process via UART logs, helping validate each stage’s success.
+
+
+### LCP: Low Power Controller (Optional Component)
+
+If present in the configuration, LCP handles platform power management at a finer granularity:
+* Implements sleep/wake transitions
+* Controls per-core power gating
+* Manages transitions to ACPI power states (e.g., S3, S5)
+
+LCP support depends on the FVP model and may be omitted in simplified virtual setups.
+
+
+### Coordination and Handoff Logic
+
+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                                                             |
+|-------|----------------------|-------------------------------------------------------------------------|
+| 1     | RSE ← BL2            | RSE is loaded and triggered by BL2 to begin security validation         |
+| 2     | SCP ← BL2 + RSE      | SCP initialization requires both BL2 and authorization from RSE         |
+| 3     | AP ← SCP + RSE       | The application processor starts only after SCP sets power and RSE permits |
+| 4     | UEFI → GRUB → Linux  | UEFI launches GRUB, which loads the kernel and enters the OS            |
+
+This handshake model ensures that no firmware stage proceeds unless its dependencies have securely initialized and authorized the next step.
+
+{{% notice Note %}}
+In the table above, arrows (←) represent **dependency relationships**—the component on the left **depends on** the component(s) on the right to be triggered or authorized.  
+For example, `RSE ← BL2` means that RSE is loaded and triggered by BL2;  
+`AP ← SCP + RSE` means the application processor can only start after SCP has initialized the hardware and RSE has granted secure boot authorization.  
+These arrows do not represent execution order but indicate **which component must be ready for another to begin**.
+{{% /notice %}}
+
+{{% notice Note %}}
+Once the firmware stack reaches UEFI, it performs hardware discovery and launches GRUB.  
+GRUB then selects and boots the Linux kernel. Unlike the previous dependency arrows (←), this is a **direct execution path**—each stage passes control directly to the next.
+{{% /notice %}}
+
+This layered approach supports modular testing, independent debugging, and early-stage simulation—all essential for secure and robust platform bring-up.
+
+
+In this module, you have:
+
+* Explored the full boot sequence of the RD‑V3 platform, from power-on to Linux login
+* Understood the responsibilities of key firmware components such as TF‑A, RSE, SCP, LCP, and UEFI
+* Learned how secure boot is enforced and how each module hands off control to the next
+* Interpreted boot dependencies using FVP simulation and UART logs
+
+With the full boot flow and firmware responsibilities now clear, you're ready to apply these insights. 
+In the next module, you'll fetch the RD‑V3 codebase, configure your workspace, and begin building your own firmware stack for simulation.