Unable to hit breakpoint with JTAG gdb on Raspberry Pi

Question

I prepared an SD card with RPi OS Lite and have modified my config.txt to enable jtag and point it to boot u-boot.bin file, instead of default kernel.img file. When I insert an SD card, my RPi-3B+ is able to boot the u-boot successfully.

I have connected a FT2232H based Flyswatter2 JTAG debugger to Rpi-3B+ and using the following command to make openocd connection with JTAG adapter. Things look good so far.

$ sudo openocd -f /usr/local/share/openocd/scripts/interface/ftdi/flyswatter2.cfg -f /usr/local/share/openocd/scripts/board/rpi3.cfg
[sudo] password for naveen:
Open On-Chip Debugger 0.12.0-g4d87f6dca (2024-03-22-16:22)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : Transport "jtag" was already selected
trst_only separate trst_push_pull

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 4000 kHz
Info : JTAG tap: bcm2837.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : bcm2837.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : bcm2837.cpu1: hardware has 6 breakpoints, 4 watchpoints
Info : bcm2837.cpu2: hardware has 6 breakpoints, 4 watchpoints
Info : bcm2837.cpu3: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
Info : starting gdb server for bcm2837.cpu0 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for bcm2837.cpu1 on 3334
Info : Listening on port 3334 for gdb connections
Info : starting gdb server for bcm2837.cpu2 on 3335
Info : Listening on port 3335 for gdb connections
Info : starting gdb server for bcm2837.cpu3 on 3336
Info : Listening on port 3336 for gdb connections

I am able to connect my gdb to openocd and inspect data from target.

$ /opt/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gdb u-boot
Reading symbols from u-boot...
(gdb) target remote :3333
Remote debugging using :3333
0x000000003b379450 in ?? ()
(gdb) mon halt
(gdb) mon reg pc
pc (/64): 0x000000003b379450

I tried setting breakpoints.

(gdb) mon load_image /home/naveen/.repos/src/arm64/u-boot/u-boot.bin 0x80000
597272 bytes written at address 0x00080000
downloaded 597272 bytes in 2.389555s (244.093 KiB/s)
(gdb) b *0x80000
Breakpoint 1 at 0x80000: file arch/arm/cpu/armv8/start.S, line 31.
(gdb) mon resume 0x80000
(gdb)

After this I never hit my breakpoint. On the serial I can see that u-boot booted till the shell without hitting the breakpoint. Ques 1 : Why the breakpoint is not hit and how can I fix it?

Ques 2 : Since the breakpoints are already set, I thought to power cycle the raspberry pi, but that just breaks the JTAG connection for sometime. And u-boot hits normally without hitting my breakpoint.

Examination failed, GDB will be halted. Polling again in 3100ms
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
Polling target bcm2837.cpu1 failed, trying to reexamine
Error: Invalid ACK (7) in DAP response
Error: JTAG-DP STICKY ERROR
Error: Could not initialize the APB-AP
Examination failed, GDB will be halted. Polling again in 3100ms
Error: Invalid ACK (7) in DAP response
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Polling target bcm2837.cpu2 failed, trying to reexamine
Info : bcm2837.cpu2: hardware has 6 breakpoints, 4 watchpoints
Polling target bcm2837.cpu3 failed, trying to reexamine
Info : bcm2837.cpu3: hardware has 6 breakpoints, 4 watchpoints
Polling target bcm2837.cpu0 failed, trying to reexamine
Info : bcm2837.cpu0: hardware has 6 breakpoints, 4 watchpoints
Polling target bcm2837.cpu1 failed, trying to reexamine
Info : bcm2837.cpu1: hardware has 6 breakpoints, 4 watchpoints

Is there a way that I can set breakpoints first and then powercycle/reset the Pi, so that breakpoint is hit? I do not want to keep doing mon load_image again and again. This doesn't look clean approach. I tried mon reset after setting breakpoint but it gives me error :

(gdb) mon reset
JTAG tap: bcm2837.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
bcm2837.cpu0: how to reset?

PS : I am using the latest clone of openocd fork from raspberry pi.

Answer 1

If you want to debug early U-Boot code, just create an endless loop in U-Boot where the code will wait until you have connected gdb.

U-Boot relocates itself from the original location it was loaded to. To debug it after relocation you need the relocation address which is printed out by the bdinfo command.

Assuming that your are in the directory where you built U-Boot, you enter gdb with:

gdb-multiarch u-boot -ex 'target remote localhost:3333'

Now in gdb you need to inform it of the address:

add-symbol-file u-boot <relocaddr>
lay src

Now you should be able to see the the source location where you are in U-Boot and can set break-points at the function you want to debug, e.g.

b do_booti

The relocation address is stored in a structure to which on arm64 register x18 is pointing (r9 on arm32). You can display the structure with:

p/x *(gd_t *)$x18