aah yes - i need to followup to get it merged, but this should work way easier than the jtag route. Though, it also needs the very latest tifs firmware. my production ai64 is on order, waiting for it to arrive to run some experiments.
Awesome news! Looking forward to working with the R5 cores.
@kaelinl, If it is not too much trouble, what was your DogTag and Kernel for the working Dhrystone. I am going to start another thread to discuss some R5 experimentation I would like to perform.
@FredEckert @kaelinl → Apparently the TIFS firmware (that allows firewall access) update is yet to be released - due in 8.5 release of the firmware from TI. So you might not be able to use the openocd dmem path just yet for j721e… This could explain the various fails you might see as a consequence.
Hmmm OK, that’s unfortunate. Thanks for the information though!
Do you have any sense of when it’ll become available? And is this firmware something I can flash in-place myself? (…what is TIFS?)
Separately, if I end up going the JTAG+TagConnect route, is it indeed infeasible to connect the probe without removing the heatsink? Where’d you get that fan shown in the pictures?
I figure if that new firmware is going to take more than a couple weeks I’ll spend the few hundred dollars on the aggressively overpriced debug equipment and do it the hard way.
Sorry, what is DogTag?
I’m running the following (unmodified) kernel:
debian@BeagleBone:~$ uname -a
Linux BeagleBone 5.10.120-ti-arm64-r63 #1bullseye SMP Fri Sep 2 01:18:17 UTC 2022 aarch64 GNU/Linux
This is the bbai64-debian-11.4-xfce-edgeai-arm64-2022-09-02-10gb.img.xz image.
Oh, also, for reference, these are the openocd options I derived from @Nishanth_Menon 's patches and the J721e datasheet. I have no idea where the 0x1d500000 size came from in the original sample for am625 and am pretty sure it’s wrong.
adapter driver dmem
dmem base_address 0x4C40002000
dmem ap_address_offset 0x0ff
dmem max_aps 10
dmem emu_base_address 0x4C60000000 0x1d500000
dmem emu_ap_list 1
if { ![info exists SOC] } {
set SOC j721e
}
source [find target/ti_k3.cfg]
adapter speed 2500
No worries on the dogtag, I figured it out. I had to tweak the makefile for my configuration.
Output:
Microseconds for one run through Dhrystone: 0.308095
Dhrystones per Second: 3245750.000000
Running:
Debian@BeagleBone:~$ cat /etc/dogtag
BeagleBoard.org Debian Bullseye Xfce Image 2022-08-26
debian@BeagleBone:~$ uname -a
Linux BeagleBone 5.10.120-ti-arm64-r64 #1bullseye SMP Tue Sep 27 18:52:35 UTC 2022 aarch64 GNU/Linux
Thanks to all for the information. As a new user, the main beaglebone-ai-64 repo wasn’t even on my radar.
Thanks. I just got my ai64 yesterday. I tried the steps below a bit…
Build steps:
sudo apt-get install libhidapi-dev libtool libusb-1.0-0-dev pkg-config
git clone https://github.com/nmenon/openocd.git
cd openocd
git checkout dap_dmem
./bootstrap
./configure --enable-dmem
make -j4
Debug steps:
cd openocd/tcl
sudo ../src/openocd -f ./board/ti_j721e_swd_native.cfg
This is the tcl snippet from above comment..
$ sudo k3conf dump processor
|--------------------------------------------------------------------------------|
| VERSION INFO |
|--------------------------------------------------------------------------------|
| K3CONF | (version 0.2-nogit built Wed Jul 27 21:21:50 UTC 2022) |
| SoC | J721E SR2.0 |
| SYSFW | ABI: 3.1 (firmware version 0x0008 '8.5.0-v08.04.07-9-g13fbe (Chill)') |
|--------------------------------------------------------------------------------|
|--------------------------------------------------------------------------------------|
| Device ID | Processor ID | Processor Name | Processor State | Processor Frequency |
|--------------------------------------------------------------------------------------|
| 202 | 32 | A72SS0_CORE0 | DEVICE_STATE_ON | 2000000000 |
| 203 | 33 | A72SS0_CORE1 | DEVICE_STATE_ON | 2000000000 |
| 142 | 3 | C66SS0_CORE0 | DEVICE_STATE_OFF | 1350000000 |
| 143 | 4 | C66SS1_CORE0 | DEVICE_STATE_OFF | 1350000000 |
| 15 | 48 | C71SS0 | DEVICE_STATE_OFF | 1000000000 |
| 250 | 1 | MCU_R5FSS0_CORE0 | DEVICE_STATE_ON | 1000000000 |
| 251 | 2 | MCU_R5FSS0_CORE1 | DEVICE_STATE_ON | 1000000000 |
| 245 | 6 | R5FSS0_CORE0 | DEVICE_STATE_OFF | 1000000000 |
| 246 | 7 | R5FSS0_CORE1 | DEVICE_STATE_OFF | 1000000000 |
| 247 | 8 | R5FSS1_CORE0 | DEVICE_STATE_ON | 1000000000 |
| 248 | 9 | R5FSS1_CORE1 | DEVICE_STATE_OFF | 1000000000 |
|--------------------------------------------------------------------------------------|
So, Info : starting gdb server for j721e.cpu.main1_r5.0 on 3340
should have connected, but…
gdb-multiarch --eval-command="set architecture arm" --eval-command="target remote localhost:3340" test.elf
Error: target->coreid 0 powered down!
I need to dig in more on the addresses a bit more…
TIFS - is TI Foundational security (firmware that runs inside the security enclave)… I hear it is due to be released in a couple of weeks, but working in TI, I do have access to a prebuilt, so I am able to check things out… as in the log above, I did try it out a bit…
debian@BeagleBone:~/openocd/openocd/tcl$ sudo devmem2 0x4C60000000
/dev/mem opened.
Memory mapped at address 0xffff9d48f000.
Read at address 0x4C60000000 (0xffff9d48f000): 0x00001003
debian@BeagleBone:~/openocd/openocd/tcl$ sudo devmem2 0x4C40002000
/dev/mem opened.
Memory mapped at address 0xffff9df24000.
Read at address 0x4C40002000 (0xffff9df24000): 0x1BB6402F
AM625 has a single R5, base at 0x1d400000 <–> 0x1d500000
in case of j721E, look at the last of the R5 cluster’s debug base 0x1d510000 → So, we need to account for it 0x1d500000 <–> 0x1d600000
The other one is the ap_address_offset → it is 0x100
I am trying to confirm max_aps-> 10 should work fine, since we dont refer to any AP > 8… but I will confirm the hardware config later today.
Got it working…
couple of gotchas:
a) minor tweaks on the cfg file needed
b) for some reason, I think if the core is in wfi, I think openocd seems to think the core is powered down in j721e… but, if i put a while(1) at the end as in the video, build the example code with -ggdb, i can use gdb-dashboard easily.
1 Like
Ah, I see! DogTag is a BeagleBoard-specific release identifier. Very funny 
That repo and the general BeagleBoard-Device-Trees (sorry, can’t easily grab the link now) have been very helpful when fiddling with peripherals.
This is the same error I got, so at least it seems I was on the right track. Impressive work!
Since it sounds like you also had to introduce the while loop to make the core appear online, do you know whether there’s any chance this would work without the new firmware but with the while loop? It sounds like you know what’s going on and expect the firmware to be necessary, so I guess probably not.
Commits · nmenon/openocd · GitHub → I still have a couple of comments from upstream maintainer that I need to get clarity on…
Adding some debug prints this is what I see:
Error: dmem_emu_ap_q_read EMU AP reg: 0x00000014
Error: dmem_emu_get_ap_reg: R 0x4c7d510314 > 0xd2800000
Error: target->coreid 0 powered down!
I dug a little more into this → looks like coresight status register read seems to be translated by openocd as core powered down… reached out to the debug folks for clarity as to my knowledge, TI had’nt customized ARM or coresight components (could be a integration oversight)…
but anyways, yeah - robert nelson checked out the current firmware with the devmem2 commands out and reported that firewalls are behaving as designed 
→ so no access seem to get through… I will try and push internally here to ship the firmwares out asap - at least the good news is that the new firmwares should work…
Ok, that’s very helpful. I’ll probably plunk down the cash for the debug hardware in the next few days if I don’t hear anything suggesting the new firmware will be available soon.
Thank you!
I decided to try my hand at debugging code on the Cortex-R5 the old fashioned hardware JTAG way… I plunked down the cash and I’m now the proud owner of a shiny new TUMPA 
Happy to report the heatsink doesn’t interfere at all with the Tag-Connect.
However, I have run into an issue that I am having some trouble getting around. Same error occurs on both Win and Linux hosts Invalid ACK (4) in DAP response.
D:\Users\Frede\Desktop\openocd-v0.12.0-rc1-i686-w64-mingw32\bin>.\openocd.exe -f .\BBAI64.cfg
Open On-Chip Debugger 0.12.0-rc1 (2022-09-18-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 16000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 16000 kHz
Info : JTAG tap: j721e.cpu tap/device found: 0x1bb6402f (mfg: 0x017 (Texas Instruments), part: 0xbb64, ver: 0x1)
Error: Invalid ACK (4) in DAP response
versions tested:
- Windows 10: openocd-v0.12.0-rc1-i686-w64-mingw32.tar.gz
- Debian Bullseye: xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-09-01-17:56)
debug dump:
Info : 285 1207 core.c:1133 jtag_examine_chain_display(): JTAG tap: j721e.cpu tap/device found: 0x1bb6402f (mfg: 0x017 (Texas Instruments), part: 0xbb64, ver: 0x1)
Debug: 286 1207 core.c:1364 jtag_validate_ircapture(): IR capture validation scan
Debug: 287 1207 core.c:1422 jtag_validate_ircapture(): j721e.cpu: IR capture 0x01
Debug: 288 1223 command.c:155 script_debug(): command - dap init
Debug: 289 1223 arm_dap.c:97 dap_init_all(): Initializing all DAPs ...
Debug: 290 1223 arm_dap.c:121 dap_init_all(): DAP j721e.cpu configured by default to use ADIv5 protocol
Debug: 291 1223 arm_adi_v5.c:679 dap_dp_init(): j721e.dap
Debug: 292 1223 arm_adi_v5.c:711 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 293 1223 arm_adi_v5.h:639 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Error: 294 1238 adi_v5_jtag.c:446 jtagdp_overrun_check(): Invalid ACK (4) in DAP response
Debug: 295 1245 command.c:545 run_command(): Command 'dap init' failed with error code -107
User : 296 1245 command.c:608 command_run_line():
Debug: 297 1245 command.c:545 run_command(): Command 'init' failed with error code -4
User : 298 1245 command.c:608 command_run_line():
I was thinking it may be due to improper configuration of the TUMPA RST signal polarity select jumper block as it was the only jumper block I couldn’t clearly see in the pictures in the K3 SoC OpenOCD HOWTO.
Any tips to work through this would be greatly appreciated!!
Fred
EDIT:
Figured it out. Didn’t specify the search path.
D:\Users\Frede\Desktop\openocd-v0.12.0-rc1-i686-w64-mingw32\bin> .\openocd.exe -s ..\share\openocd\scripts\ -f .\BBAI64.cfg
Open On-Chip Debugger 0.12.0-rc1 (2022-09-18-17:56)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 16000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 16000 kHz
Info : JTAG tap: j721e.cpu tap/device found: 0x1bb6402f (mfg: 0x017 (Texas Instruments), part: 0xbb64, ver: 0x1)
Info : starting gdb server for j721e.cpu.sysctrl on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for j721e.cpu.a72.0 on 3334
Info : Listening on port 3334 for gdb connections
Info : starting gdb server for j721e.cpu.a72.1 on 3335
Info : Listening on port 3335 for gdb connections
Info : starting gdb server for j721e.cpu.mcu_r5.0 on 3336
Info : Listening on port 3336 for gdb connections
Info : starting gdb server for j721e.cpu.mcu_r5.1 on 3337
Info : Listening on port 3337 for gdb connections
Info : starting gdb server for j721e.cpu.main0_r5.0 on 3338
Info : Listening on port 3338 for gdb connections
Info : starting gdb server for j721e.cpu.main0_r5.1 on 3339
Info : Listening on port 3339 for gdb connections
Info : starting gdb server for j721e.cpu.main1_r5.0 on 3340
Info : Listening on port 3340 for gdb connections
Info : starting gdb server for j721e.cpu.main1_r5.1 on 3341
Info : Listening on port 3341 for gdb connections
Sorry for cluttering up Tony’s stellar initial post with all this R5 debugging junk. Maybe all this info will help some other folks out someday…
2 Likes
Got a bit further with the hardware JTAG but now am up against the previously mentioned:
gdb-multiarch --eval-command="set architecture arm" --eval-command="target remote localhost:3340" test.elf
Error: target->coreid 0 powered down!
@Nishanth_Menon did you get any clarity on the issue? How did you get past it in the video?
I recollect starting the core up using the remote proc commands before i attempted to talk to the core… jtag will not be able to switch on the clocks and power to the processor, hence the need to start it up with remoteproc commands.
1 Like
Hey @Tony_Kao,
For your dhrystone branch, I am wondering where you got the files in your r5/ folder? I am trying to code up a Cortex-R5F Whetstone and I’m hoping to use the dpl clock API:
include <kernel/dpl/ClockP.h>
I looked at the files in the PROCESSOR-SDK-J721E Software development kit (SDK) | TI.com, and they are a bit older (c 2015-2017) than the ones you are using (c 2018-2021).
Thanks again for the R5 example!!!
Regards,
FredE
EDIT: Ferreted it out: MCU-PLUS-SDK-AM64X Software development kit (SDK) | TI.com
MCU-PLUS-SDK-AM64X
MCU+ SDK for AM64x – RTOS, No-RTOS
Version: 08.03.00.18
Release date: 20 Jun 2022
1 Like
Btw what should I do if i want to use Jlink for this?
Assuming you’re referring to debugging the R5 cores – it probably works. You’d need the TagConnect probe and depending on which J-Link model you have some variant of adapter for the various connector sizes.
1 Like