In this blog entry we will discuss how we can debug the Versal™ boot images such as the ATF and U-Boot (pre and post relocation) in Vitis™.
Boot image debug is a vital part of any custom board bring up, and hopefully this blog will allow users to fully debug a custom board boot image.
Even if you are using a development board, this blog will provide useful insights into how the boot images work on Versal devices.
I will be targeting the VCK190 Xilinx Development board, however the steps will be the same for a custom Versal Board.
This is the third blog in the Versal "from the ground up" debug Series. Users can see previous blogs in this series here:
The Hardware Design:
The Hardware design consists of the CIPS and the NoC for connection to the DDR.
The Software Design:
The u-boot.elf that is delivered in the images/linux folder does not have the symbol information needed for debug in Vitis. Therefore, we will need to use the u-boot binary that is in the work directory in PetaLinux.
We will also enable the ATF debug so that the symbol information is added to the bl31.elf file too.
I have used PetaLinux to create the Linux Images as shown below:
petalinux-create -t project --template versal -n versal_linux
cd versal_linux
petalinux-config --get-hw-description=<path to XSA>
Select DTG Settings -> (versal-vck190-reva) MACHINE_NAME
ARM Trusted Firmware Confguration -> [*] atf debug
Take a note of the Yocto Settings -> TMPDIR Location.
Open build/conf/local.conf and comment out (#) the line INHERIT += "rm_work"
petalinux-build -c u-boot
Because we will be debugging the u-boot, we need the symbol file. The u-boot.elf created in U-Boot does not have the symbol info.
However, we can copy this from the TMP directory into the images/linux folder in the PetaLinux Project directory:
As a sanity check, users can use objdump to read and verify the symbol files:
petalinux-package --boot --plm --psmfw --uboot --dtb
Debugging in Vitis:
I find that the easiest way to debug the boot images is to load the boot image onto your SD/QSPI and debug on the running target.
So let's place the BOOT.BIN on the SD card and boot.
Setting up Debug:
Launch Vitis and close the welcome screen.
Create a new Debug Configuration:
Double Click on Single Application Debug:
Because I have the boot image running from the SD card, I have selected "Attach to Running Target" as the Debug Type:
This will launch the debug perspective, and you should see the device targets:
Debug Pre U-Boot Relocation:
Launch the XSCT, and add the symbol files and add the breakpoints:
If we now power cycle the board, we should see the bl31_main breakpoint hit:
From here, users can step through the code and check that the hand-off between the ATF and the U-Boot is executed correctly.
If users hit Resume, then we will see the U-Boot board_init_f breakpoint hit:
Users can step through the code here. For example, there is the setup_reloc function that users can use to find the U-Boot relocation address (or use bdinfo).
Debug Post U-Boot Relocation:
The U-Boot code will relocate itself, and because we have the symbol file memory mapped, this will be incorrect.
As a result we need to pass the relocated address so that the debugger can compensate for this.
First, we need to find the relocation address. This can be obtained from the bdinfo or from the U-boot code directly.
The relocation address in my example (and this will be different for different users) is 0x77EEB000.
We can update the memmap info with the relocation address. First however, we need to clear the existing memmap and update.
I have now added a breakpoint at the board_init_r function:
Again, if we power cycle, the bl31_main is hit, then if we resume we will hit the board_init_r function:
