Debugging U-Boot drivers in SDK 2018.3

In this brief tutorial we will discuss how to debug uboot drivers in SDK 2018.3. The main issue with debugging uboot is that the code relocates. In this tutorial we shall discuss how to overcome this in SDK, and how to add breakpoints to debug potential driver issue.

The use-case we will use here is the debugging of the PS GEM driver (zynq_gem) on the RFSoC board; ZCU111. The SDK supports debugging on a running target, so users can boot u-boot from SD card and connect to this running target in SDK. User can then set the relocation information, and set a breakpoint. Then upon a reboot the breakpoint should be hit and user can step through the uboot code as normal.

Determining the uboot relocation address and offset:

Boot into u-boot and use the bdinfo utility to obtain this information. For example:

Here, we can see that the reloc_off is 0x77ED9000, and the relocaddr is 0x7FED9000

Determining a uboot driver function address after relocation:

In this use-case, we shall be debugging the zynq_gem driver. So, a good place to start here is the zynq_gem_probe(). Users can get the address of this function from the uboot.map file, and add this to the relocation address to find the relocated address of the zynq_gem_probe().

For example:

So, the relocated address would be the relocaddr + the offset in the map file; 0x7FED9000 + 0x4187C = 0x7FF1A87C

Connecting to Running Target in SDK:

Launch SDK 2018.3, and Run → Debug Configurations

Double click on the Xilinx C/C++ (System Debugger) to create a new debug configuration. 

Select Attach to running target as the Debug Type

If the board is connected directly to your machine, select Conection as local. However, as in the case here the board is connected remotely. User can set this up by selecting New

and setting up the target connection.

Updating the relocated symbol information:

We need to stop the processor (CortexA53 #0), and update the memory map to set the relocated symbol information. Users can do this from the XSCT command line in SDK

Adding the breakpoint to the relocated uboot driver function:

Users can set the breakpoint from XSCT too using the address calculated above:

Debugging relocated uboot function in SDK:

Now, if the user re-boots the uboot then the breakpoint will be hit, and the user can then step through the code to see if the uboot is executing as expected:

Users may need to highlight the processor to enable the debugging symbols to step over, into, ect: