Minimal Cortex-R5 example on BBAI-64

[Nishanth_Menon]

@kaelinl

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.

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.

[kaelinl]

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.

[kaelinl]

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.

[Nishanth_Menon]

Commits · nmenon/openocd · GitHub → I still have a couple of comments from upstream maintainer that I need to get clarity on…

@kaelinl

Since it sounds like you also had to introduce the while loop to make the core appear online

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)…

@kaelinl

Do you know whether there’s any chance this would work without the new firmware but with the while loop?

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…

[kaelinl]

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!

[FredEckert]

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…

[FredEckert]

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?

[Nishanth_Menon]

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.

kaofishy/bbai64_cortex-r5_example/blob/main/Makefile#L27

[FredEckert]

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

[Stat_headcrabed]

Btw what should I do if i want to use Jlink for this?

[kaelinl]

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.