Merge pull request #1637 from danielnguyen-arm/main

refinfra: update debug guide for new fvp

Author: jasonrandrews

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

@@ -6,7 +6,33 @@ weight: 4
 layout: learningpathall
 ---
 
-## Debugging BL1 
+## Debugging BL1
+Due to RSE CPU wait hold and the APs will be powered off. You will not be able to start the debugger until RSE has powered the AP cores.
+
+A workaround is to modify BL1 to spin on entry.
+
+Navigate to ``<workspace>/rd-infra/tf-a/bl1/aarch64/bl1_entrypoint.S``, find the ``bl1_entrypoint`` function, and add a ``b .`` instruction:
+
+```asm
+func bl1_entrypoint
+
+    b   .   // <-- Branch-to-self added here
+
+    /* ---------------------------------------------------------------------
+    * If the reset address is programmable then bl1_entrypoint() is
+    * executed only on the cold boot path. Therefore, we can skip the warm
+    * boot mailbox mechanism.
+    * ---------------------------------------------------------------------
+    */
+    el3_entrypoint_common                               \
+        _init_sctlr=1                                   \
+        _warm_boot_mailbox=!PROGRAMMABLE_RESET_ADDRESS  \
+        _secondary_cold_boot=!COLD_BOOT_SINGLE_CPU      \
+        _init_memory=1                                  \
+        _init_c_runtime=1                               \
+        _exception_vectors=bl1_exceptions   
+```
+
 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")
@@ -29,16 +55,29 @@ These commands load the symbol files and specify the memory address location, up
 
 The `EL` (Exception Level) and number at the end of each command, for example, `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, check that it has stopped. Set a breakpoint on the next instruction of
-the TF-A and press **run**. In this debug panel, you can find common debugging functions like stepping and skipping.
+When you connect the debugger, the primary CPU will be "spinning" on a ``b .`` instruction from the one you manually added to the ``bl1_entrypoint`` function.
 
-![debug options alt-text#center](images/debug_options.png "Figure 3. Debug options")
+In this debug panel, you can find common debugging functions like stepping and skipping.
 
-Observe the SCP console output. After the SCP deasserts, reset for the Neoverse N2 Core 0, it stops on the breakpoint.
+Set a breakpoint in the function you would like to debug. In this example, we set a breakpoint at ``bl1_main()``.
 
+Simply interrupt the CPU and enter debug command `set $pc += 4'; you can now step through and debug the TF-A boot flow.
 
-![scp terminal alt-text#center](images/scp_terminal.png "Figure 4. SCP terminal")
+![bl1 breakpoint alt-text#center](images/bl1_breakpoint.png "Figure 5. BL1 breakpoint")
 
-Finally, set a breakpoint in the function you would like to debug. In this example, we set a breakpoint at ``bl1_main()``and continue. 
+## Alternate break method
+Another method of setting a breakpoint without modifying TF-A is by launching the model with ``--break``.
+The general syntax for defining a breakpoint is:
+```bash
+--break <INST>=<MEMSPACE>@<ADDRESS>
+```
 
-![bl1 breakpoint alt-text#center](images/bl1_breakpoint.png "Figure 5. BL1 breakpoint")
+- ``<INST>``: Processor identifier (e.g., AP0 in cluster 0).
+- ``<MEMSPACE>``: Memory space identifier (e.g., id=1 for EL2 VA space).
+
+To determine valid instance and memory space names, run: ``--list-instances`` or ``--list-memory``.
+
+Example command:
+```bash
+./boot.sh -p rdv3r1cfg1 -a "--break RD_V3_R1_Cfg1.socket0.css0.lcp_app_group00.app0.cluster.cpu0=0@0x0"
+```

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

@@ -10,33 +10,52 @@ layout: learningpathall
 
 Adding symbol files for UEFI requires you to boot the FVP once without debugging, so that you can 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. The UEFI load system pre-formats the output into `add-symbol-file` directives that can be copy-and-pasted.
+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.
+
+**Do the same actions in the same order you will when you are debugging as this affects the locations of the modules. For example, open UEFI interface -> Enter UEFI Shell -> Load EFI driver in the same order each time.**
 
 The log files are stored in:
 ```bash
-/<workspace>/rd-infra/model-scripts/rdinfra/platforms/rdn2/rdn2
+<workspace>/rd-infra/model-scripts/rdinfra/platforms/rdn2/rdn2
 ```
 
-As we focus on the ``uart-0-nsec`` console, we can use ``grep`` to find all the symbol files. 
-```bash
-grep add-symbol-file refinfra-*-uart-0-nsec-*
-```
+Following the previous chapter, we should still be in TF-A. In the Commands window, execute the following command to break at the start of UEFI: ``break EL2N:0xE0000000``. Execute until we are in EL2N address space. This is because the script depends on the current address space when loading in symbols.
+
+In Arm DS, go to the scripts tab and hit "Import a script or directory" then "Import a DS or Jython script"
+
+![ArmDS scripts alt-text#center](images/armds-script.png "Figure 4. Add ArmDS scripts")
+
+Select the script ``~/rd-infra/uefi/edk2/ArmPlatformPkg/Scripts/Ds5/cmd_load_symbols.py``.
 
-![grep uart logs alt-text#center](images/grep.png "Figure 1. Grep UART logs")
+Enter the following parameters
 
-We can then copy these lines and append them to the list of symbol files, as before.
+``-f (<UEFI entry point>, 0x20000)`` The UEFI entry point was found earlier (0xE0000000). 0x20000 is the size which can be found in the UEFI build log.
 
-UEFI runs in EL2, so modify the end of each line to be ``EL2:<address>``.
+![FV Size alt-text#center](images/armds-script.png "Figure 5. FV Size")
 
-![uefi symbol files alt-text#center](images/uefi_symbol_files.png "Figure 3. Add uefi symbol files")
+```command
+-a -v
+
+-i <path to UART log file> This is the path to the UART log which was produced by a running the whole UEFI process
+
+-o <path to objdump executable> This is the path to aarch64-none-linux-gnu-objdump. 
+```
+
+The script has now been setup.
+All the debug symbols have loaded, you can now start debugging!
+
+### Debugging Boot Process
 
 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. 
+set breakpoints.
+For example, let's set a breakpoint at the entry point to DxeCore.
 
-![peicore alt-text#center](images/peicore.png "Figure 4. PeiCore functions")
+![dxecore alt-text#center](images/dxecore.png "Figure 6. DxeCore functions")
 
 You can see that it has stopped at the breakpoint.
 
+![dxecore breakpoint alt-text#center](images/dxecorebreakpoint.png "Figure 6. DxeCore breakpoint")
+
 ### If using Arm Development Studio version <2023.1
 
 Older versions of Arm Development Studio have Beta support for DWARF 5 formats. EDK2 builds the debug files in DWARF 5
@@ -50,5 +69,5 @@ These instructions state that you must enable the LLVM DWARF parser to use DWARF
 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")
+![enable llvm alt-text#center](images/enable_llvm.png "Figure 7. Enable LLVM")
 

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

@@ -1,12 +1,12 @@
 ---
-title: Debugging SCP
+title: Debugging SCP/LCP/RSE
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Debugging SCP
+## Setting up a connection
 {{% notice %}}
 SCP firmware debug uses the `-Og` argument. This optimizes some variables that make debugging difficult. To replace `-Og` with `-O0`, do the following:
 
@@ -46,16 +46,38 @@ In the **Edit configuration and launch** panel, in the **Connection** tab, selec
 
 For the `SCP` code, select **ARM_Cortex-M7_1**.
 
+{{% notice Selecting the correct core %}}
+For different platforms (e.g., RD-N2, RD-V3, etc.), you will see a list of numbered M7 and M55 cores. Typically, even-numbered M7 cores correspond to the MCP, while odd-numbered cores are assigned to the SCP. Additionally:
+
+- `ARM_Cortex-M55_0` to `ARM_Cortex-M55_(N-1)` represent LCP cores.
+- `ARM_Cortex-M55_N` represents the RSE.
+
+To verify core assignments, you can set up alerts (e.g., print statements or store variables), connect to a debugger, and test the configuration.
+{{% /notice %}}
+
 ![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``.
 
+RSE debug symbol file location:
+```command
+rd-infra/tf-m/cmake_build/<plat>/<cfg>/bin/bl1_1.elf
+rd-infra/tf-m/cmake_build/<plat>/<cfg>/bin/bl1_2.elf
+rd-infra/tf-m/cmake_build/<plat>/<cfg>/bin/bl2.elf
+```
+
+LCP debug symbol file location:
+```command
+rd-infra/scp/output/<plat>/<cfg>/lcp_ramfw/rdv3-lcp-bl2.elf
+```
+
 ![scp symbols alt-text#center](images/scp_symbols.png "Figure 6. Load SCP symbols")
 
 Select **Apply** then **Debug**. The debugger now connects to the model.
 
+## Setting breakpoints
 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.
 
 Set a breakpoint at ``cmn700_discovery()``. Continue execution and the code stops at the breakpoint you specify.