You might face different issues when running a complete Linux software stack on a CPU Fixed Virtual Platforms (FVPs). The purpose of this blog is to provide possible solutions to solve common issues that you might encounter when running on CPU FVPs.
This document describes necessary steps to get a working Linux system running on these platforms, including the following system components software:
In addition, this document describes the steps to debug the Trusted Firmware-A and Linux Kernel by using the Arm DS.
Arm Ecosystem Fixed Virtual Platforms (FVPs) model hardware subsystems target different market segments and applications.
FVPs use binary translation technology to deliver fast, functional simulations of Arm-based systems, including processor, memory, and peripherals. They implement a programmer's view suitable for software development and enable execution of full software stacks, providing a widely available platform ahead of silicon.
Arm provides different types of FVPs. There are several freely available, pre-built Armv8‑A FVPs for download from Arm Ecosystem Models on Arm Developer website. You can use these FVPs without a license. For example, the AEMv8-A Base Platform RevC FVP is freely available, and it supports the latest Armv8‑A architecture versions up to v8.7 and Armv9-A.
The Arm reference software stack is based on the above RevC model. However, some Armv8 FVPs with a fixed number of cores are replaced by FVPs with a configurable number of cores, for example:
The Arm reference software stack is the codebase. Follow the Armv-A Base AEM FVP Platform Software User Guide to set up the environment, download the software stack, and get the toolchain.
The FVP_Base_Cortex-<xxx> FVP is available for you to build and run Linux host environments. Contact Arm Support (support@arm.com) to request access.
This document supports running the software stack on the following FVPs:
However, this is not a full list. This blog might apply to more FVP platforms, but no test is done for these platforms, for example:
If you build the software without any modification, you might get the following error message after running the software stack:
ASSERT: File lib/cpus/aarch64/cpu_helpers.S Line 00035
The previous error message is issued because the TF-A does not build the cpu_ops into the images:
31 /* Get the matching cpu_ops pointer */ 32 bl get_cpu_ops_ptr 33 #if ENABLE_ASSERTIONS 34 cmp x0, #0 35 ASM_ASSERT(ne) 36 #endif
The cpu_ops are defined in the source file as follows:
lib/cpus/aarch64/cortex_a510.S lib/cpus/aarch64/cortex_a53.S lib/cpus/aarch64/cortex_a55.S lib/cpus/aarch64/cortex_a57.S lib/cpus/aarch64/cortex_a65.S lib/cpus/aarch64/cortex_a65ae.S lib/cpus/aarch64/cortex_a710.S lib/cpus/aarch64/cortex_a715.S lib/cpus/aarch64/cortex_a72.S lib/cpus/aarch64/cortex_a73.S
Check the Makefile (plat/arm/board/fvp/platform.mk) of the FVP platform. You can find the following code:
ifeq (${HW_ASSISTED_COHERENCY}, 0) # Cores used without DSU FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a35.S \ lib/cpus/aarch64/cortex_a53.S \ lib/cpus/aarch64/cortex_a57.S \ lib/cpus/aarch64/cortex_a72.S \ lib/cpus/aarch64/cortex_a73.S else # Cores used with DSU only ifeq (${CTX_INCLUDE_AARCH32_REGS}, 0) # AArch64-only cores FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a76.S \ lib/cpus/aarch64/cortex_a76ae.S \ lib/cpus/aarch64/cortex_a77.S \ lib/cpus/aarch64/cortex_a78.S \ lib/cpus/aarch64/neoverse_n_common.S \ lib/cpus/aarch64/neoverse_n1.S \ lib/cpus/aarch64/neoverse_n2.S \ lib/cpus/aarch64/neoverse_e1.S \ lib/cpus/aarch64/neoverse_v1.S \ lib/cpus/aarch64/neoverse_v2.S \ lib/cpus/aarch64/cortex_a78_ae.S \ lib/cpus/aarch64/cortex_a510.S \ lib/cpus/aarch64/cortex_a710.S \ lib/cpus/aarch64/cortex_a715.S \ lib/cpus/aarch64/cortex_x3.S \ lib/cpus/aarch64/cortex_a65.S \ lib/cpus/aarch64/cortex_a65ae.S \ lib/cpus/aarch64/cortex_a78c.S \ lib/cpus/aarch64/cortex_hayes.S \ lib/cpus/aarch64/cortex_hunter.S \ lib/cpus/aarch64/cortex_x2.S \ lib/cpus/aarch64/neoverse_poseidon.S endif # AArch64/AArch32 cores FVP_CPU_LIBS += lib/cpus/aarch64/cortex_a55.S \ lib/cpus/aarch64/cortex_a75.S endif
HW_ASSISTED_COHERENCY = 0 and CTX_INCLUDE_AARCH32_REGS =1 are default build options.
Building the cpu_ops into the TF-A image requires different build options, depending on the CPU type. For example, different platforms require different build options when building the TF-A:
Note: The build option USE_COHERENT_MEM cannot be enabled with HW_ASSISTED_COHERENCY=1.
Perform the following steps to build cpu_ops into the TF-A image:
3.1 Modify the following build script to add build options. The Arm reference software stack uses the build-scripts to build the TF-A.
build-scripts/ configs/aemfvp-a/aemfvp-a
3.2 Add TF-A build options, depending on the CPU type. For example:
ARM_TF_BUILD_FLAGS="$ARM_TF_BUILD_FLAGS HW_ASSISTED_COHERENCY=1 USE_COHERENT_MEM=0 "
ARM_TF_BUILD_FLAGS="$ARM_TF_BUILD_FLAGS HW_ASSISTED_COHERENCY=1 USE_COHERENT_MEM=0 CTX_INCLUDE_AARCH32_REGS=0"
3.3 Rebuild the TF-A by using the following commands:
./build-scripts/build-arm-tf.sh -p aemfvp-a -f busybox clean ./build-scripts/build-arm-tf.sh -p aemfvp-a -f busybox build
3.4 Package the built TF-A into the BusyBox disk image by using the following command:
./build-scripts/aemfvp-a/build-test-busybox.sh -p aemfvp-a package
If you build the software without modifying the device tree, you might get the following error message after running the software stack:
[ 0.563774] pci-host-generic 40000000.pci: host bridge /pci@40000000 ranges: [ 0.563972] pci-host-generic 40000000.pci: MEM 0x0050000000..0x005fffffff -> 0x0050000000 [ 0.564233] pci-host-generic 40000000.pci: ECAM at [mem 0x40000000-0x4fffffff] for [bus 00-01] [ 0.564878] pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00 [ 0.565014] pci_bus 0000:00: root bus resource [bus 00-01] [ 0.565138] pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff] [ 0.565266] Internal error: synchronous external abort: 96000010 [#1] PREEMPT SMP [ 0.565366] Modules linked in: [ 0.565448] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.13.13 #1 [ 0.565534] Hardware name: FVP Base RevC (DT) [ 0.565621] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO BTYPE=--) [ 0.565746] pc : pci_generic_config_read+0x3c/0xe4 [ 0.565832] lr : pci_generic_config_read+0x28/0xe4 [ 0.565966] sp : ffff80001205b960 [ 0.566006] x29: ffff80001205b960 x28: 0000000000000000 x27: ffff8000116904b8 [ 0.566179] x26: ffff800011741060 x25: 0000000000000000 x24: ffff800011fca8b8 [ 0.566366] x23: 0000000000000000 x22: ffff80001205ba64 x21: 0000000000000087 [ 0.566566] x20: 0000000000000004 x19: ffff80001205b9c4 x18: 0000000000000030 [ 0.566723] x17: 000000000000003f x16: 000000000000000b x15: ffffffffffffffff [ 0.566923] x14: ffff80009205b697 x13: ffff800011ca2a30 x12: 0000000000000267 [ 0.567096] x11: 00000000000000cd x10: ffff800011cfaa30 x9 : 00000000fffff000 [ 0.567270] x8 : ffff800011ca2a30 x7 : ffff800011cfaa30 x6 : 0000000000000001 [ 0.567443] x5 : 0000000000000000 x4 : ffff800012800000 x3 : 0000000000000000 [ 0.567624] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800012800000 [ 0.567790] Call trace: [ 0.567866] pci_generic_config_read+0x3c/0xe4 [ 0.567966] pci_bus_read_config_dword+0x7c/0xd0 [ 0.568066] pci_bus_generic_read_dev_vendor_id+0x38/0x1b4 [ 0.568198] pci_scan_single_device+0xa0/0x150 [ 0.568311] pci_scan_slot+0x44/0x130 [ 0.568435] pci_scan_child_bus_extend+0x54/0x2a0 [ 0.568525] pci_scan_root_bus_bridge+0x68/0xdc [ 0.568666] pci_host_probe+0x1c/0xc4 [ 0.568782] pci_host_common_probe+0x11c/0x19c [ 0.568918] platform_probe+0x6c/0xdc [ 0.569017] really_probe+0xe4/0x510 [ 0.569129] driver_probe_device+0x64/0xc4 [ 0.569263] device_driver_attach+0xc4/0xd0 [ 0.569366] __driver_attach+0x94/0x134 [ 0.569508] bus_for_each_dev+0x70/0xd0 [ 0.569613] driver_attach+0x28/0x34 [ 0.569737] bus_add_driver+0x108/0x1f0 [ 0.569836] driver_register+0x7c/0x130 [ 0.569966] __platform_driver_register+0x2c/0x40 [ 0.570084] gen_pci_driver_init+0x20/0x2c [ 0.570171] do_one_initcall+0x50/0x1b0 [ 0.570266] kernel_init_freeable+0x220/0x2a4 [ 0.570409] kernel_init+0x18/0x124 [ 0.570491] ret_from_fork+0x10/0x30 [ 0.570566] Code: 7100069f 540001c0 71000a9f 54000300 (b9400001) [ 0.570778] ---[ end trace 6db9afd6e7186a9a ]--- [ 0.570827] note: swapper/0[1] exited with preempt_count 1 [ 0.570952] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 0.571066] SMP: stopping secondary CPUs [ 0.571147] Kernel Offset: disabled [ 0.571174] CPU features: 0x10000081,a3300e46 [ 0.571266] Memory Limit: none [ 0.571366] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
On CPU FVP platforms, PCI and SMMU devices are not supported. To make Linux run successfully, remove the PCI and SMMU nodes from the device tree.
The Arm reference software stackuses the following device tree:
linux/arch/arm64/boot/dts/arm/fvp-base-revc.dts
Perform the following steps to remove the PCI and SMMU node from the device tree:
1.1 Delete the following lines from the device tree:
155 pci: pci@40000000 { 156 #address-cells = <0x3>; 157 #size-cells = <0x2>; 158 #interrupt-cells = <0x1>; 159 compatible = "pci-host-ecam-generic"; 160 device_type = "pci"; 161 bus-range = <0x0 0x1>; 162 reg = <0x0 0x40000000 0x0 0x10000000>; 163 ranges = <0x2000000 0x0 0x50000000 0x0 0x50000000 0x0 0x10000000>; 164 interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>, 165 <0 0 0 2 &gic 0 0 GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>, 166 <0 0 0 3 &gic 0 0 GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>, 167 <0 0 0 4 &gic 0 0 GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>; 168 interrupt-map-mask = <0x0 0x0 0x0 0x7>; 169 msi-map = <0x0 &its 0x0 0x10000>; 170 iommu-map = <0x0 &smmu 0x0 0x10000>; 171 172 dma-coherent; 173 }; 174 175 smmu: iommu@2b400000 { 176 compatible = "arm,smmu-v3"; 177 reg = <0x0 0x2b400000 0x0 0x100000>; 178 interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING>, 179 <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>, 180 <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>, 181 <GIC_SPI 77 IRQ_TYPE_EDGE_RISING>; 182 interrupt-names = "eventq", "gerror", "priq", "cmdq-sync"; 183 dma-coherent; 184 #iommu-cells = <1>; 185 msi-parent = <&its 0x10000>; 186 };
1.2 Rebuild Linux by using the following commands:
./build-scripts/build-linux.sh -p aemfvp-a -f busybox clean ./build-scripts/build-linux.sh -p aemfvp-a -f busybox build
1.3 Package the built Linux to the BusyBox disk image by using the following command:
On Arm64 SMP systems, cores are identified by the MPIDR_EL1 register. The MPIDR_EL1 in the Arm Architecture Reference Manual does not provide strict enforcement of MPIDR_EL1 layout.
For example, Cortex-A55 has a layout different from the layout of Cortex-A53.
The following two tables compare the MPIDR_EL1 Layout between Cortex-A55 and Cortex-A53.
Cortex-A55 MPIDR_EL1 Layout
Cortex-A53 MPIDR_EL1 Layout
Linux Kernel boots the CPU cores according to the affinity values in the device tree. However, different CPU FVP platforms use different affinity values. If the affinity value in the device tree is not consistent with the CPU FVP platform, you might get the following error:
[ 0.023728] psci: failed to boot CPU2 (-22) [ 0.023948] CPU2: failed to boot: -22 [ 0.025770] psci: failed to boot CPU3 (-22) [ 0.025867] CPU3: failed to boot: -22 [ 0.027567] psci: failed to boot CPU4 (-22) [ 0.027679] CPU4: failed to boot: -22 [ 0.029541] psci: failed to boot CPU5 (-22) [ 0.029615] CPU5: failed to boot: -22 [ 0.031410] psci: failed to boot CPU6 (-22) [ 0.031467] CPU6: failed to boot: -22 [ 0.033319] psci: failed to boot CPU7 (-22) [ 0.033383] CPU7: failed to boot: -22
Affinity values in the device tree must be consistent with the affinity values in the FVP platform. Perform the following steps to modify affinity values:
2.1 Get correct affinity value for the FVP platforms
The parameter pctl.CPU-affinities in the FVP platform shows the correct affinity values, for example:
$FVP_Base_Cortex-A55x4 -l |grep pctl.CPU-affinities pctl.CPU-affinities=0.0.0.0, 0.0.1.0, 0.0.2.0, 0.0.3.0 $FVP_Base_Cortex-A57x2-A53x4 -l |grep pctl.CPU-affinities pctl.CPU-affinities=0.0.0.0, 0.0.0.1, 0.0.1.0, 0.0.1.1, 0.0.1.2, 0.0.1.3
The CPU affinity values on the FVP_Base_Cortex-A55x4 are:
0x0,0x0100,0x0200,0x300
The CPU affinity values on the FVP_Base_Cortex-A57x2-A53x4 are:
0x0,0x1,0x0100,0x0101,0x0102,0x0103
2.2 Modify the affinity values in the device tree to be consistent with the FVP platform
You must change the affinity value in the device tree:
Consider FVP_Base_Cortex-A57x2-A53x4 as an example:
cpu0: cpu@0 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x0 0x000>; enable-method = "psci"; }; cpu1: cpu@1 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x0 0x01>; enable-method = "psci"; }; cpu2: cpu@100 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x0 0x100>; enable-method = "psci"; }; cpu3: cpu@101 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x00 0x101>; enable-method = "psci"; }; cpu4: cpu@102 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x00 0x102>; enable-method = "psci"; }; cpu5: cpu@103 { device_type = "cpu"; compatible = "arm,armv8"; reg = <0x00 0x103>; enable-method = "psci"; };
2.3 Remove unnecessary CPU nodes from the device tree, according to the CPU numbers of the FVP platform.
2.4 Rebuild the Linux by using the following commands:
2.5 Package the built Linux to the BusyBox disk image by using the following command:
After adding extra TF-A build options and removing the PCI and MMU nodes from the device tree, you can follow the Arm Reference Solution Guide to build the software stack.
The final images are like the following:
$ tree output/aemfvp-a/aemfvp-a/ output/aemfvp-a/aemfvp-a/ ├── Image -> ../components/linux/Image ├── Image.defconfig -> ../components/linux/Image.defconfig ├── fip-uboot.bin ├── fip-uefi.bin ├── fvp-base-revc.dtb -> ../components/linux/fvp-base-revc.dtb ├── tf-bl1.bin -> ../components/fvp/tf-bl1.bin ├── tf-bl2.bin -> ../components/fvp/tf-bl2.bin ├── tf-bl2u.bin -> ../components/fvp/tf-bl2u.bin ├── tf-bl31.bin -> ../components/fvp/tf-bl31.bin ├── uboot.bin -> ../components/aemfvp-a/uboot.bin └── uefi.bin -> ../components/aemfvp-a/uefi.bin
After the build of the software stack, you can follow the guide to run the software stack on the Armv-A Base AEM FVP platform.
CPU FVP platforms have a fixed number of cores, so you cannot use the model-scripts/aemfvp-a/boot.sh to run the CPU FVP platforms.
To run the software stack in the CPU FVP platform, use the command like the following:
<PATH_TO_FVP>/FVP_Base_Cortex-A55x4 \ -C pctl.startup=0.0.0.0 \ -C bp.secure_memory=0 \ -C cache_state_modelled=0 \ -C bp.ve_sysregs.mmbSiteDefault=0 \ -C bp.ve_sysregs.exit_on_shutdown=1 \ -C bp.pl011_uart0.untimed_fifos=1 \ -C bp.pl011_uart0.unbuffered_output=1 \ -C bp.pl011_uart0.out_file=<PATH_TO_LOG>/uart0.log \ -C bp.pl011_uart1.untimed_fifos=1 \ -C bp.pl011_uart1.unbuffered_output=1 \ -C bp.pl011_uart1.out_file=<PATH_TO_LOG>/uart1.log \ -C bp.secureflashloader.fname=<SRC_PATH>/output/aemfvp-a/aemfvp-a/tf-bl1.bin \ -C bp.flashloader0.fname=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fip-uboot.bin \ -C bp.virtioblockdevice.image_path=<SRC_PATH>/output/aemfvp-a/components/aemfvp-a/grub-busybox.img \ --data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/Image@0x80080000 \ --data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb@0x83000000
After the previous command is run, the CPU FVP starts booting Trusted Firmware-A, followed by UEFI/U-Boot, Linux, and BusyBox.
If you use the GUI, you can run it as shown in the following figure:
On some CPU FVP platforms, you might encounter the following error and the system cannot boot successfully.
Warning: target instance not found: 'FVP_Base_Cortex_A65AEx4_Cortex_A76AEx4.cluster0.cpu0' (data: 'output/aemfvp-a/aemfvp-a/Image') In file: /tmp/plgbuild/abs_build/1153836_60931/trunk/work/fastsim/Framework/scx/SCXExportedVirtualSubsystem.cpp:358 Warning: target instance not found: 'FVP_Base_Cortex_A65AEx4_Cortex_A76AEx4.cluster0.cpu0' (data: 'output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb') In file: /tmp/plgbuild/abs_build/1153836_60931/trunk/work/fastsim/Framework/scx/SCXExportedVirtualSubsystem.cpp:358
The FVP platform contains multiple CPU instances, and the CPU instance names are different on different CPU FVP platforms.
To load raw data into right CPU instances, use the ––dataoption to specify correct CPU instance names, according to the CPU FVP platform. For example, on FVP_Base_Cortex-A55x4, the CPU0 instance is cluster0.cpu0:
--data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/Image@0x80080000 \ --data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb@0x83000000
To get the correct CPU0 instance name in the CPU FVP platform, run the command like the following:
$ FVP_Base_Cortex-A65AEx4+Cortex-A76AEx4 -l |grep RVBARADDR |grep cpu0 cluster0.subcluster0.cpu0.thread0.RVBARADDR=0 # (int , init-time) default = '0x0' : Value of RVBAR_ELx register. cluster0.subcluster0.cpu0.thread1.RVBARADDR=0 # (int , init-time) default = '0x0' : Value of RVBAR_ELx register. cluster0.subcluster1.cpu0.RVBARADDR=0 # (int , init-time) default = '0x0' : Value of RVBAR_ELx register. $ FVP_Base_Cortex-A55x4+Cortex-A78x4 -l |grep RVBARADDR |grep cpu0 cluster0.subcluster0.cpu0.RVBARADDR=0 # (int , init-time) default = '0x0' : Value of RVBAR_ELx register. cluster0.subcluster1.cpu0.RVBARADDR=0 # (int , init-time) default = '0x0' : Value of RVBAR_ELx register.
For FVP_Base_Cortex-A65AEx4+Cortex-A76AEx4, use the –data option like the following to run the FVP:
--data cluster0.subcluster0.cpu0.thread0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/Image@0x80080000 \ --data cluster0.subcluster0.cpu0.thread0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb@0x83000000
For FVP_Base_Cortex-A55x4+Cortex-A78x4, use the ––data option like the following to run the FVP:
--data cluster0.subcluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/Image@0x80080000 \ --data cluster0.subcluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb@0x83000000
To debug the TF-A and Linux kernel, the Arm DS debugger is used as the debugger. You can get the Arm DS from the Arm Developer website.
DWARF 5 is the default option in GCC 11 and Arm DS v2022.2 initial support for DWARF 5 debug information. If your GCC version is later than GCC11, download the latest Arm DS to get support for DWARF 5.
By default, Arm DS provides the following Base FVP models:
Arm FVPs that are not provided by Arm DS installation must be defined in the PATH environment variable of your OS to be available for Arm DS. Otherwise, you might get the following error when starting the debug connection:
For Linux, set up the PATH in the appropriate shell configuration file. For example, add the following line in ~/.bashrc,
export PATH=<your model path>/bin:$PATH
After changing the PATH environments, you might need to start the Arm DS from the terminal for the PATH to take effect. For example:
/opt/arm/developmentstudio-2022.2/bin/armds_ide
The FVP model to connect must be available in the Development Studio configuration database so that you can select it in the Model Connection dialog box.
If the FVP model is not available, you must import it and create a new model configuration. For details, see create a new model.
Most CPU FVP models are available for your edition of Arm DS and the FVPs are listed under the Arm FVP (Installed with Arm DS) and Arm FVP as shown in the following figure:
To use Arm DS to connect to an FVP model for bare-metal debugging, perform the following steps:
-C pctl.startup=0.0.0.0 \ -C bp.secure_memory=0 \ -C cache_state_modelled=0 \ -C bp.ve_sysregs.mmbSiteDefault=0 \ -C bp.ve_sysregs.exit_on_shutdown=1 \ -C bp.pl011_uart0.untimed_fifos=1 \ -C bp.pl011_uart0.unbuffered_output=1 \ -C bp.pl011_uart0.out_file=<PATH_TO_LOG>/uart0.log \ -C bp.pl011_uart1.untimed_fifos=1 \ -C bp.pl011_uart1.unbuffered_output=1 \ -C bp.pl011_uart1.out_file=<PATH_TO_LOG>/uart1.log \ -C bp.secureflashloader.fname=<SRC_PATH>/output/aemfvp-a/aemfvp-a/tf-bl1.bin \ -C bp.flashloader0.fname=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fip-uboot.bin \ -C bp.virtioblockdevice.image_path=<SRC_PATH>/output/aemfvp-a/components/aemfvp-a/grub-busybox.img \ --data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/Image@0x80080000 \ --data cluster0.cpu0=<SRC_PATH>/output/aemfvp-a/aemfvp-a/fvp-base-revc.dtb@0x83000000
Configure debugger settings in the Debugger
In Run control, choose Connect only to the target.
add-symbol-file “~/arm/sw/cpufvp-a/arm-tf/build/fvp/debug/bl1/bl1.elf” EL3:0 add-symbol-file “~/arm/sw/cpufvp-a/arm-tf/build/fvp/debug/bl2/bl2.elf” EL1S:0 add-symbol-file “~/arm/sw/cpufvp-a/arm-tf/build/fvp/debug/bl31/bl31.elf” EL3:0 add-symbol-file “~/arm/sw/cpufvp-a/linux/out/aemfvp-a/defconfig/vmlinux” EL2N:0
This step starts the debug connection, loads the application on the model, and loads the debug information into the debugger.