Merge pull request #839 from ArmDeveloperEcosystem/main

Merge to production

content/install-guides/browsers/_index.md

@@ -41,9 +41,8 @@ Here is a quick summary to get you started:
 | Firefox       | native         | yes               |
 | Chromium      | native         | yes               |
 | Brave         | native         | yes               |
+| Chrome        | native         | no                |
 | Edge          | native         | no                |
-| Chrome Beta   | native         | no                |
-| Chrome Stable | emulation      | no                |
 | Vivaldi       | emulation      | yes               |
 
 Windows on Arm runs native ARM64 applications, but can also emulate 32-bit x86 and 64-bit x64 applications. Emulation is slower than native and shortens battery life, but may provide functionality you need.

content/install-guides/browsers/chrome.md

@@ -25,41 +25,18 @@ layout: installtoolsall         # DO NOT MODIFY. Always true for tool install ar
 
 ## Installing Chrome
 
-The Chrome browser runs on Windows on Arm natively on the Beta release channel, and using emulation on the Stable release channel. Chrome is not available for Arm Linux. 
+The Chrome browser runs on Windows on Arm as a native ARM64 application. Chrome is not available for Arm Linux. 
 
 ### Linux
 
 Chrome is not available for Arm Linux. 
 
 ### Windows 
 
-#### Native 
-
 To install Chrome on Windows on Arm:
 
-1. Go to the [download page](https://www.google.com/chrome/beta/?platform=win_arm64) and click the Download Chrome Beta button.
+1. Go to the [download page](https://www.google.com/chrome/?platform=win_arm64) and click Download here. Click the Accept and Install button to start the download.
 
 2. Run the downloaded `ChromeSetup.exe` file 
 
 3. Find and start Chrome from the applications menu
-
-{{% notice Note %}}
-The native Windows on Arm version of Chrome is currently on the Beta channel. This is a preview version of new features in development and is updated weekly, but is faster than emulation.
-{{% /notice %}}
-
-#### Emulation
-
-If you prefer to use a Stable version, you can run using emulation. 
-
-Emulation is slower than native and shortens battery life.
-
-1. Download the Windows installer from [Google Chrome](https://www.google.com/chrome/)
-
-2. Run the `ChromeSetup.exe` installer 
-
-3. Find and start Chrome from the applications menu 
-
-{{% notice Note %}}
-The Chrome setup program installs the 32-bit x86 version of Chrome.
-{{% /notice %}}
-

content/learning-paths/servers-and-cloud-computing/refinfra-debug/_index.md

@@ -1,6 +1,8 @@
 ---
-title: Reference Design Debugging Guide
+title: Debug the Neoverse Reference Design software stack
+
 draft: true
+
 minutes_to_complete: 20
 
 who_is_this_for: This is an introductory topic for software developers interested in testing the reference firmware stack.
@@ -11,8 +13,8 @@ learning_objectives:
     - Debug TF-A
 
 prerequisites:
-    - A computer running Linux. Any architecture can be used.
-    - Can boot reference design software stack on an FVP.
+    - An Arm Development Studio license
+    - The Neoverse Reference Design software stack should be set up
 
 author_primary: Daniel Nguyen
 

content/learning-paths/servers-and-cloud-computing/refinfra-debug/debugging-bl1-3.md

@@ -7,12 +7,11 @@ layout: learningpathall
 ---
 
 ## Debugging BL1 
-In the **Edit configuration and launch** panel, in the **Connection** tab, select the correct
-target. In this example, we are selecting the **ARM_Neoverse-N2_0**. 
+In the **Edit configuration and launch** panel **Connection** tab, select the **ARM_Neoverse-N2_0**. 
 
 ![select target alt-text#center](images/select_target.png "Figure 1. Select target")
 
-Next, we'll add debug symbols. In the **Debugger** tab, check the **Execute debugger commands**, and add the following commands.
+Add debug symbols. In the **Debugger** tab, check the **Execute debugger commands**, and add the following commands.
 
 {{% notice %}}
 If you wish to add platform specific debug files, the memory locations are in their respective ``platform_h.def`` file.
@@ -28,15 +27,15 @@ add-symbol-file "/<workspace>/rd-infra/tf-a/build/rdn2/debug/bl31/bl31.elf" EL3:
 
 These commands load the symbol files and specify the memory address where the symbols should be loaded.
 Replacing <workspace> with the path to your workspace directory.
-The EL and number at the end of each command (e.g. ``EL3:0``) ensure the symbols are loaded into the correct
-virtual address space and at the correct memory offset; ATF uses absolute addresses for its symbols so we ensure an offset of 0.
+
+The `EL` and number at the end of each command (e.g. ``EL3:0``) ensure the symbols are loaded into the correct virtual address space and at the correct memory offset; ATF uses absolute addresses for its symbols so we use an offset of 0.
 
 After connecting to the running model, see that it has stopped. Set a breakpoint on the next instruction of
 the TF-A and press run. In this debug panel, you will find common debugging functions like stepping, skipping, and others.
 
 ![debug options alt-text#center](images/debug_options.png "Figure 3. Debug options")
 
-Observe the SCP console output. After SCP de-asserts reset for the NeoverseN2 Core 0, it stops on the breakpoint.
+Observe the SCP console output. After SCP de-asserts reset for the Neoverse N2 Core 0, it stops on the breakpoint.
 
 ![scp terminal alt-text#center](images/scp_terminal.png "Figure 4. SCP terminal")
 

content/learning-paths/servers-and-cloud-computing/refinfra-debug/debugging-bl31-4.md

@@ -7,17 +7,20 @@ layout: learningpathall
 ---
 
 ## Debugging BL31 
-Setting a breakpoint for BL1 was simple enough, but how do we set a breakpoint for BL31? In the
-tabs panel at the bottom, click the plus and add other tabs. Here are multiple other tabs
-available such as Register View, Memory View, and others. For this example, we are only interested in the **Functions** tab.
+Setting a breakpoint for BL1 was simple enough, but how do we set a breakpoint for BL31?
+
+In the tabs panel at the bottom, click the plus (`+`) and add other views. Here are multiple other views available such as Register View, Memory View, and others.
+
+For this example, we are only interested in the **Functions** view.
 
 ![add functions alt-text#center](images/add_functions.png "Figure 1. Add functions tab")
 
-From here, search for ``bl31_entrypoint`` using the flashlight icon and set a breakpoint. Press continue. 
+Search for ``bl31_entrypoint`` using the flashlight icon and set a breakpoint. Press continue. 
 
 ![bl31 breakpoint 1 alt-text#center](images/bl31_breakpoint-1.png "Figure 2. BL31 breakpoint 1")
 
 Observe the application processor console output. TF-A will proceed from BL1 to BL2 to BL31.
+
 After reaching BL31, NeoverseN2 Core 0 stops on the breakpoint.
 
 ![bl31 breakpoint 2 alt-text#center](images/bl31_breakpoint-2.png "Figure 3. BL31 breakpoint 2")

content/learning-paths/servers-and-cloud-computing/refinfra-debug/debugging-bl33-uefi-5.md

@@ -7,10 +7,9 @@ layout: learningpathall
 ---
 
 ## Debugging BL33 / UEFI
-Adding symbol files for UEFI requires you to boot the FVP once without debugging to retrieve the symbol file
-locations and memory addresses. After booting the FVP, notice that in the non secure AP console output,
-the UEFI load system helpfully shows where each driver is relocated to. In fact the UEFI load system pre-formats
-the output into add-symbol-file directives that can just be copy-pasted!
+Adding symbol files for UEFI requires you to boot the FVP once without debugging to retrieve the symbol file locations and memory addresses.
+
+After booting the FVP, notice that in the non secure AP console output, the UEFI load system helpfully shows where each driver is relocated to. In fact the UEFI load system pre-formats the output into `add-symbol-file` directives that can just be copy-pasted.
 
 The log files are stored in:
 ```bash
@@ -25,27 +24,30 @@ grep add-symbol-file refinfra-*-uart-0-nsec-*
 ![grep uart logs alt-text#center](images/grep.png "Figure 1. Grep UART logs")
 
 We can then copy these lines and append them to the list of symbol files like before.
-Note that UEFI runs in EL2, so we must modify the end of the line to be ``EL2:<address>``.
+
+UEFI runs in EL2, so modify the end of each line to be ``EL2:<address>``.
 
 ![uefi symbol files alt-text#center](images/uefi_symbol_files.png "Figure 3. Add uefi symbol files")
 
-ArmDS currently has [BETA] support for DWARF 5 formats. EDK2 builds the debug files in DWARF 5
-format. In order to properly load the debug files, follow the
-instructions [here](https://developer.arm.com/documentation/101470/2023-0/Reference/Standards-compliance-in-Arm-Debugger)
+Once the debugger is connected, see the functions tab. Here you can search for functions to
+set breakpoints. For example, let's set a breakpoint at the entry point to PEI. 
 
-These instructions state that you must enable the LLVM DWARF parser to use DWARF 5 format.
-To enable the LLVM DWARF parser, do the following. In the Arm Development Studio IDE, 
+![peicore alt-text#center](images/peicore.png "Figure 4. PeiCore functions")
 
-1. Select **Window**  > **Preferences**. 
-2. Then, in the **Preferences** dialog box, navigate to **Arm DS** > **Debugger** > **DWARF Parser**. 
-3. Select the **Use LLVM DWARF parser** checkbox and click **Apply and Close**.
+You will see that it has stopped at the breakpoint.
 
-![enable llvm alt-text#center](images/enable_llvm.png "Figure 4. Enable LLVM")
+### If using Arm Development Studio version < 2023.1
 
-Once the debugger is connected, see the functions tab. Here you can search for functions to
-set breakpoints. For example, let's set a breakpoint at the entry point to PEI. 
+Older versions of Arm Development Studio have [BETA] support for DWARF 5 formats. EDK2 builds the debug files in DWARF 5
+format.
 
-![peicore alt-text#center](images/peicore.png "Figure 5. PeiCore functions")
+In order to properly load the debug files, follow the instructions [here](https://developer.arm.com/documentation/101470/2023-0/Reference/Standards-compliance-in-Arm-Debugger)
 
-You will see that it has stopped at the breakpoint.
+These instructions state that you must enable the LLVM DWARF parser to use DWARF 5 format. To enable the LLVM DWARF parser, do the following.
+
+In the Arm Development Studio IDE:
+1. Select **Window**  > **Preferences**. 
+2. Then, in the **Preferences** dialog box, navigate to **Arm DS** > **Debugger** > **DWARF Parser**. 
+3. Select the **Use LLVM DWARF parser** checkbox and click **Apply and Close**.
 
+![enable llvm alt-text#center](images/enable_llvm.png "Figure 5. Enable LLVM")

content/learning-paths/servers-and-cloud-computing/refinfra-debug/debugging-scp-2.md

@@ -8,17 +8,18 @@ layout: learningpathall
 
 ## Debugging SCP
 {{% notice %}}
-At the time of writing this guide, SCP firmware debug uses "-Og" argument. This optimizes some variables. That makes debugging difficult. To replace "-Og" with "-O0", do the following:
+At the time of writing this guide, SCP firmware debug uses `-Og` argument. This optimizes some variables that makes debugging difficult. To replace `-Og` with `-O0`, do the following:
 
-* Navigate to ``rd-infra/scp/cmake/Toolchain``
-* See <compiler>_Baremetal.cmake files
-* Modify the one for the compiler you use. For example, for GCC modify GNU-Baremetal.cmake:
+* Navigate to `rd-infra/scp/cmake/Toolchain`
+* Modify the appropriate `<compiler>-Baremetal.cmake` file for your toolchain
 
-``string(APPEND CMAKE_${language}_FLAGS_DEBUG_INIT "-Og")`` 
+For example, modify `GNU-Baremetal.cmake`:
 
-to 
+`string(APPEND CMAKE_${language}_FLAGS_DEBUG_INIT "-Og")`
 
-``string(APPEND CMAKE_${language}_FLAGS_DEBUG_INIT "-O0")``
+to
+
+`string(APPEND CMAKE_${language}_FLAGS_DEBUG_INIT "-O0")`
 {{% /notice %}}
 
 After starting the model, click **Create a new debug connection...** from the **Debug Control** panel.
@@ -33,31 +34,43 @@ Next, click on **Add a new model...**.
 
 ![add new model alt-text#center](images/add_new_model.png "Figure 3. Add new model")
 
-Make sure the Model Interface is selected to be **CADI**. 
+Select the appropriate Model Interface, for example **CADI**.
+
 Click **Browse for model running on local host**.
+
 Select the correct model and click finish.
 
 ![connect model alt-text#center](images/connect_model.png "Figure 4. Connect model")
 
-In the **Edit configuration and launch** panel, in the **Connection** tab, select the correct target. In this example, select **ARM_Cortex-M7_1**. 
+In the **Edit configuration and launch** panel, in the **Connection** tab, select the correct target.
+
+For the `SCP` code, select **ARM_Cortex-M7_1**. 
 
 ![select target alt-text#center](images/select_cortexm7.png "Figure 5. Select target")
 
-In the **Files** panel, select **Load Symbols from file**, **File System**, and select the **SCP RAMFW ELF** file, located at ``rd-infra/scp/output/rdn2/0/scp_ramfw/bin/rdn2-bl2.elf``.
+In the **Files** panel, select **Load Symbols from file**, **File System**, and select the **SCP RAMFW ELF** file, located at:
+
+``rd-infra/scp/output/rdn2/0/scp_ramfw/bin/rdn2-bl2.elf``.
 
 ![scp symbols alt-text#center](images/scp_symbols.png "Figure 6. Load SCP symbols")
 
-Select apply then debug. DS will now connect to the model and start debugging.
+Select **Apply** then **Debug**. The debugger will now connect to the model.
 
-Once connected, we can set breakpoints in the source code. This can be done by searching for the function in the **Functions** tab, or by double clicking next to the line number.
+Once connected, you can set breakpoints in the source code. This can be done by searching for the function in the **Functions** tab, double clicking next to the line number, or in the **Command** view.
 
-Here, you can see that we've set a breakpoint at ``cmn700_discovery()``. You'll see that it has stopped at that breakpoint upon continuing the code.
+Set a breakpoint at ``cmn700_discovery()``. Continue execution and the code will stop at that breakpoint.
+```command
+break cmn700_discovery
+continue
+```
 
 ![scp breakpoint 1 alt-text#center](images/scp_breakpoint1.png "Figure 7. cmn700_discovery() breakpoint")
 
-We'll set another breakpoint at a debug print statement. 
+Set another breakpoint at a debug print statement. 
 
 ![scp breakpoint 2 alt-text#center](images/scp_breakpoint2.png "Figure 8. SCP breakpoint 2")
 
-You can see the output in the SCP UART window.
+Observe the output in the SCP UART window.
+
+Disconnect from the FVP.
 

content/learning-paths/servers-and-cloud-computing/refinfra-debug/setup-1.md

@@ -0,0 +1,37 @@
+---
+title: Set up environment
+weight: 2
+
+### FIXED, DO NOT MODIFY
+layout: learningpathall
+---
+
+This learning path assumes you have a Arm Development Studio installed and an appropriate license set up. See the [install guide](//install-guides/armds) for instructions. Screenshots shown are from the 2023.0 version.
+
+The learning path also assumes you have set up the Neoverse Reference Design software stack and associated FVP. See this [learning path](//learning-paths/servers-and-cloud-computing/refinfra-quick-start/) for instructions. The Neoverse N2 (`RD-N2`) stack is used.
+
+## Modify the run script
+
+Modify the provided script at:
+
+```bash
+rdinfra/model-scripts/rdinfra/platforms/rdn2/run_model.sh
+```
+Remove `–R` parameter from `PARAMS=` section. This option was used in the original script to allow the FVP to continue to execute and not wait for the debug connection.
+
+![modify parameters alt-text#center](images/modify_params.png "Figure 1. Modify run_model.sh")
+
+{{% notice Debug server %}}
+The `-S` option is used to start a `CADI` debug server. Changing this to `-I` would start an `Iris` debug server instead.
+{{% /notice %}}
+
+Run the script to launch the model.
+```bash
+./run_model.sh
+```
+
+{{% notice FVP Accuracy %}}
+FVPS do not completely model the `IMP DEF` behavior that RTL does.
+
+FVPs also do not model cycles/performance nor `AXI/ACE/AHB/CHI` bus level transactions.
+{{% /notice %}}

content/learning-paths/servers-and-cloud-computing/refinfra-quick-start/_index.md

@@ -1,6 +1,8 @@
 ---
-title: Reference Design Quick Start
+title: Get started with the Neoverse Reference Design software stack
+
 draft: true
+
 minutes_to_complete: 30
 
 who_is_this_for: This is an introductory topic for software developers interested in testing the reference firmware stack.
@@ -11,9 +13,9 @@ learning_objectives:
     - Test the reference firmware stack
 
 prerequisites:
-    - A computer running Linux. Any architecture can be used.
+    - Some understanding of the software stack architecture
 
-author_primary: Tom Pilar
+author_primary: Tomas Pilar
 
 ### Tags
 skilllevels: Introductory
@@ -22,7 +24,7 @@ armips:
     - Neoverse
 tools_software_languages:
     - Docker
-    - Arm Development Studio
+    - FVP
 operatingsystems:
     - Linux