Minimal Cortex-R5 example on BBAI-64

Nishanth_Menon · October 4, 2022, 5:50pm

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 · October 4, 2022, 7:25pm

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 · October 4, 2022, 7:28pm

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 · October 4, 2022, 9:09pm

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…

kaelinl · October 4, 2022, 10:24pm

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 · October 27, 2022, 2:34am

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 · October 28, 2022, 1:59am

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 · October 28, 2022, 2:23am

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.

github.com

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


      
          
          
all: $(APP)
          
          
clean:
          	rm -f $(APP)
          
          
$(APP): $(APP_SOURCES) gcc.ld
          	$(CROSS_CC) $(CFLAGS) -Og --specs=nosys.specs --specs=nano.specs -T gcc.ld -o $(APP) $(APP_SOURCES)
          	$(CROSS_SIZE) $(APP)
          	$(CROSS_OBJDUMP) -xd $(APP) > $(APP).lst
          	# sudo cp $(APP) /lib/firmware/
          	# sudo echo stop > /sys/class/remoteproc/remoteproc18/state
          	# sudo echo $(APP) > /sys/class/remoteproc/remoteproc18/firmware
          	# sudo echo start > /sys/class/remoteproc/remoteproc18/state
          	# sudo cat /sys/kernel/debug/remoteproc/remoteproc18/trace0

FredEckert · November 4, 2022, 8:28pm

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 · November 6, 2022, 4:35pm

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

kaelinl · November 7, 2022, 12:08am

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.

Kendall_Auel · April 20, 2023, 10:33pm

I’ve tried building the dhrystone branch on my Linux desktop, and also on the BBAI64 itself. But either way I see no output in the trace file. Can you tell me, what was the “tweak” you made to the makefile to get it working for you? The main branch (hello world) works as expected.

FredEckert · April 21, 2023, 1:02am

Hi Kendall,

If I recall correctly, the tweak was adding the -u _printf_float linker directive.

Here is the makefile from the dhrystone-fixup_makefile branch in my fork:

APP ?= test.elf
APP_SOURCES ?= $(wildcard r5/*.S) \
          $(wildcard r5/*.c) \
	  test.c dhry_1.c dhry_2.c

CROSS_COMPILE ?= arm-none-eabi-

.PHONY: $(APP)

CROSS_CC ?= $(CROSS_COMPILE)gcc
CROSS_SIZE ?= $(CROSS_COMPILE)size
CROSS_OBJDUMP ?= $(CROSS_COMPILE)objdump

ARCH ?= r5

ifeq ($(ARCH),r5)
	CFLAGS += -fno-exceptions -mcpu=cortex-r5 -marm -mfloat-abi=hard -O3 -I r5
endif

all: $(APP)

clean:
	rm -f $(APP)

$(APP): $(APP_SOURCES) gcc.ld
	$(CROSS_CC) $(CFLAGS) --specs=nosys.specs --specs=nano.specs -T gcc.ld -o $(APP) $(APP_SOURCES) -u _printf_float
	$(CROSS_SIZE) $(APP)
	$(CROSS_OBJDUMP) -xd $(APP) > $(APP).lst
	# sudo cp $(APP) /lib/firmware/
	# sudo echo stop > /sys/class/remoteproc/remoteproc18/state
	# sudo echo $(APP) > /sys/class/remoteproc/remoteproc18/firmware
	# sudo echo start > /sys/class/remoteproc/remoteproc18/state
	# sudo cat /sys/kernel/debug/remoteproc/remoteproc18/trace0

Credit goes to Nishanth Menon for the makefile concept, which I got from studying his fork.

If this doesn’t get it going, try pulling down a copy of my fork.

Best regards,
Fred Eckert

Kendall_Auel · April 21, 2023, 10:19pm

Hurray!!

From the dhrystone branch, adding the “-u _printf_float” didn’t do the trick. But when I copied and pasted your entire makefile into the branch, I am now seeing the dhrystone results in the trace0 file.

Thank you for your help… I’ve been puzzling this one out for a while.

jwinarske · October 4, 2023, 2:46pm

Tagging on here since I couldn’t find a working OpenOCD TUMPA cfg.

bbai64.cfg

adapter driver ftdi
ftdi vid_pid 0x0403 0x6010
ftdi layout_init 0x0038 0x087b
ftdi layout_signal nTRST -data 0x0020
ftdi layout_signal nSRST -data 0x0010
reset_config srst_push_pull
transport select jtag
reset_config srst_only srst_push_pull
adapter srst delay 20
if { ![info exists SOC] } {
        set SOC j721e
}
source [find target/ti_k3.cfg]
adapter speed 2500

Also on Linux if you install the openocd uev rule file, you can avoid having to use sudo when running openocd:

sudo cp contrib/60-openocd.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules && udevadm trigger