-
-
Notifications
You must be signed in to change notification settings - Fork 845
09_hw_debug_JTAG: Why do we need the X1_JTAG_boot binary? #82
-
I'm not sure why do we need to have that special binary loaded on the Pi before we can start debugging it with JTAG? What I have noticed is that as long as we have the bootloader on the SD card, and the UART USB connected, the Pi will boot and the loader will be waiting for minipush to connect.
NOTE: I use different adapters then you so I use my own OpenOCD config files, but I think it should not matter. If it does, I can share my files with you.
- Plug the JTAG adapter,
- start OpenOCD -> check it is connected and now listening for gdb
$ openocd -f scripts/openocd/ftdi-c232hm-ddhsl-0.cfg -f scripts/openocd/rpi4.cfg
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020年10月13日-17:27)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: rpi4.tap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : rpi4.a72.0: hardware has 6 breakpoints, 4 watchpoints
Info : rpi4.a72.1: hardware has 6 breakpoints, 4 watchpoints
Info : rpi4.a72.2: hardware has 6 breakpoints, 4 watchpoints
Info : rpi4.a72.3: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for rpi4.a72.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for rpi4.a72.1 on 3334
Info : Listening on port 3334 for gdb connections
Info : starting gdb server for rpi4.a72.2 on 3335
Info : Listening on port 3335 for gdb connections
Info : starting gdb server for rpi4.a72.3 on 3336
Info : Listening on port 3336 for gdb connections
- start gdb-multiarch
Once gdb is started:
(gdb) target extended-remote :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00000000020003e4 in ?? ()
(gdb) monitor reset halt
...
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from target/aarch64-unknown-none-softfloat/debug/kernel...
(gdb) load
Loading section .text, size 0xc634 lma 0x80000
Loading section .rodata, size 0x301d lma 0x8c640
Loading section .data, size 0xb0 lma 0x90000
Start address 0x0000000000080000, load size 63233
Transfer rate: 66 KB/sec, 10538 bytes/write.
(gdb) break _start
Breakpoint 1 at 0x80018: file src/arch/aarch64/raspberrypi/start.rs, line 56.
(gdb) c
Continuing.
Breakpoint 1, bootloader::arch::board::start::_start () at src/arch/aarch64/raspberrypi/start.rs:56
56 if cpu::BOOT_CORE_ID == cpu::core_id() {
The same method also works with gdb-remote launch configuration in vscode. We just skip the target extended-remote :3333 command and put all the others in a gdb script debug.gdb:
{
"name": "Debug JTAG",
"type": "gdb",
"request": "attach",
"cwd": "${workspaceFolder}",
"executable": "${workspaceRoot}/target/aarch64-unknown-none-softfloat/debug/kernel",
"target": ":3333",
"remote": true,
"valuesFormatting": "parseText",
"gdbpath": "gdb-multiarch",
"autorun": [
"source -v debug.gdb",
],
}You can disconnect and restart from vscode any time you want. You can set breakpoints etc...
Maybe I'm missing something @andre-richter and as usual would appreciate your enlightening feedback.
Beta Was this translation helpful? Give feedback.
All reactions
There is a bit of history and organic growth behind the current situation.
Back when the tutorials were for RPi3 only, the X1 helper binary, in its GPIO driver, configured the JTAG pins.
Then the RPi4 came out, with basically no documentation at the time, and the GPIO JTAG setup code that was used for the Pi3 didn't work out of the box. I had an email exchange with somebody working on it as well, and he found out that you additionally need to write to some undocumented memory location to make it work on the Pi4. I haven't checked since if the official documentation has to say something about this now.
This was when I decided to introduce enable_jtag_gpio=1 into the config.txt, so the X1 b...
Replies: 3 comments
-
There is a bit of history and organic growth behind the current situation.
Back when the tutorials were for RPi3 only, the X1 helper binary, in its GPIO driver, configured the JTAG pins.
Then the RPi4 came out, with basically no documentation at the time, and the GPIO JTAG setup code that was used for the Pi3 didn't work out of the box. I had an email exchange with somebody working on it as well, and he found out that you additionally need to write to some undocumented memory location to make it work on the Pi4. I haven't checked since if the official documentation has to say something about this now.
This was when I decided to introduce enable_jtag_gpio=1 into the config.txt, so the X1 binary lost a lot of its meaning at this point.
I still thought its nice-to-have that it spits out a "ready-to-connect" message, so I never fully removed it.
But you are right, the UART chainloader in waiting state is just good enough.
Beta Was this translation helpful? Give feedback.
All reactions
-
Cool. Makes it super clear. And now we have it documented 😁.
Let me know if opening issues for such topics is the right channel to engage or if I should use a different method.
Beta Was this translation helpful? Give feedback.
All reactions
-
Fine for me! Setting up something separately just takes time for maintenance that I don't have 😅
I'll start labeling questions from now on, this makes them more discoverable.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1