You are currently reviewing an older revision of this page.
Hafnium is a reference Secure Partition Manager (SPM) for systems that implement the Armv8.4-A Secure-EL2 extension. It enables multiple, isolated Secure Partitions (SPs) to run at Secure-EL1.More information about Hafnium can be found here.
Regarding the TotalCompute software stack which also include the BL32(SPM), the BL32(SPM) is implemented as Hafnium software component. You can find the introduction Here
The TC software stack can both support buildroot and Android build, since the hafnium is part of fimrware, we take buildroot as example.
Firstly, we follow the
Run the software image based on Armv-A Base RevC AEM FVP model by below cmds:
BL1 --> BL2 --> BL1 --> BL31 --> BL32 --> BL31 --> BL33
We recommend reading the Arm Trusted Firmware Design document for more information
This article outlines how to debug TF-A:
When debugging TF-A it is important to know which boot stage(s) contain the functionality that you are interested in; this way the correct symbols and debug information can be loaded, allowing us to set breakpoints on textual symbol names rather than raw addresses, see function call target names rather than PC relative offsets, and so on. It also means we can skip unnecessary parts of the boot flow.
From the ARM DS Debug control pannel, navigate to:Debug Congtrol--> New Debug Connection... -->Choose "Model Connection --> Debug connection name, such as "TF-A" -> Next --> Target Selection --> Add a new model ...
Debug Congtrol--> New Debug Connection... -->Choose "Model Connection --> Debug connection name, such as "TF-A" -> Next --> Target Selection --> Add a new model ...
Then, "Select Model Interface(Iris)" --> Next--> choose "Launch and connect to specific model" --> Next --> Browse the Model Path to select the downloaded file path of “Armv-A Base RevC AEM FVP model” --> Finish
At last, the model is imported as below:
-C pctl.startup=0.0.0.0 -C bp.secure_memory=1 -C cluster0.NUM_CORES=4 -C cache_state_modelled=0 -C bp.pl011_uart0.untimed_fifos=1 -C bp.ve_sysregs.mmbSiteDefault=0 -C bp.ve_sysregs.exit_on_shutdown=1 -C bp.secureflashloader.fname=/home/jett/jetzho01_share/trusted-firmware-a/build/fvp/debug/bl1.bin -C bp.flashloader0.fname=/home/jett/jetzho01_share/trusted-firmware-a/build/fvp/debug/fip.bin -I -p
On the window that opens, navigate to the "Debugger" tab, tick "Connect only", tick "Execute debugger commands", and copy-paste the following into the text box to automatically load all symbols into the correct virtual address space each time you connect to the model:
add-symbol-file <workspace>/arm-tf/build/fvp/debug/bl1/bl1.elf EL3:0 add-symbol-file <workspace>/arm-tf/build/fvp/debug/bl2/bl2.elf EL1S:0 add-symbol-file <workspace>/arm-tf/build/fvp/debug/bl31/bl31.elf EL3:0
Replacing <workspace> with the path to your workspace directory.
<workspace>
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; TF-A uses absolute addresses for its symbols so we ensure an offset of 0.
`EL3:0'
Click "Apply" and then "Debug" to connect to the paused model. You can now step through the TF-A code or set a breakpoint on the symbol corresponding to the functionality that you are interested.
For the FVP, the BL1 start from address 0, when debuging with ARM DS debugger, mis-matching source and disassembly views in the Debugger, when debugging startup code around address 0x0, is caused by “dangling” debug data.Some information about this topic can be found at link.
So for the BL1, we can add some change into Makefile as below for BL1 to avoid this issue.
diff --git a/bl1/bl1.mk b/bl1/bl1.mkindex 95fe50ed0..cc793142a 100644--- a/bl1/bl1.mk+++ b/bl1/bl1.mk@@ -30,5 +30,6 @@ ifneq ($(findstring gcc,$(notdir $(LD))),) else ifneq ($(findstring ld,$(notdir $(LD))),) BL1_LDFLAGS += --sort-section=alignment endif-+ BL1_LDFLAGS += --no-gc-sections+ BL1_LDFLAGS += -z undefs BL1_DEFAULT_LINKER_SCRIPT_SOURCE := bl1/bl1.ld.S