Enable JTAG In U-Boot

#1

Reference: JTAG/SWD debugging? -> [SOLVED] Is there a way to load a program directly into SRAM using USB OTG?

So I just worked around my UART mux-change issue by altering the UART mux in the TPL instead of figuring out why u-boot wasn’t honoring my change in arch/arm/dts/rk3588-rock-5b.dts.

With that done, and displaying the output on the changed mux instead of the original mux, I connected my STM32 SWD lines to the pins that were previously the original UART2 mux0 pins.

No clue if that’s all it’ll take (eg. if I have to enable jtag the way uart was, or even if jtag drivers are made for u-boot), but it’s not working for me.

$ openocd -f /usr/share/openocd/scripts/interface/stlink-dap.cfg -f <pathToCustom>/rk3308.cfg -d3 simply results in

...
Debug: 67 78 stlink_usb.c:2609 stlink_dump_speed_map(): 5 kHz
Debug: 68 370 stlink_usb.c:748 stlink_usb_error_check(): STLINK_JTAG_GET_IDCODE_ERROR
Error: 69 370 stlink_usb.c:2959 stlink_usb_open(): init mode failed (unable to connect to the target)
Debug: 70 370 stlink_usb.c:1323 stlink_usb_exit_mode(): MODE: 0x01
...

rk3308.cfg only contains transport select dapdirect_swd since I was only looking for ANY good connection before adding other needed customizations.

And in case anyone doubts using STM32 SWD to do the job, know that I’ve already done it with other boards like my nrf52840 dongle.

EDIT0: Looking at the dtb decompiled, I see

...
	pinctrl {
		#address-cells = <0x02>;
		#size-cells = <0x02>;
		compatible = "rockchip,rk3588-pinctrl";
...
		jtag {
		};
...

so definitely looks like I need to enable it in some way…

EDIT1: Actually, ya know, I don’t think I do need to “enable” it in u-boot. I ought to be able to use it with BOOTROM(/maskrom), but the result is the same.

#2

except rk3308 all rockchip have jtag/swd pins muxed to sdcard, so first you need to load minimal ‘switch’ bin, to be able connect using swd (tested with rk3399, rk3288).
look in rk3588 trm for tms.
i was able to switch between swd/sdcard even in u-boot, but at that stage you already have memory initialized. so if you want to have soc in ‘almost’ default state, use bootrom/rkdevtool

1 Like
#3

HEY Indy! Good to hear from you. Don’t know if you were pinged from me referencing your threads (I’m new to this forum). Loved your movies (Indiana Jones… XD).

However, I fear I must counter your “rockchip have jtag/swd pins muxed to sdcard” if I’m reading and understanding the schematics correctly (feel free to correct me as I know I don’t know it all (hence, why I’m asking)).

In radxa_rock_5b_v142_sch.pdf:p11/32, where the default UART2_{TX,RX}_M0, which has the alternate function of JTAG_{TCK,TMS}_M2 at GPIO0_B{5,6}, that does NOT apply to the sdcard (:p13/32) which has SDMMC_D{2,3}/JTAG_{TCK,TMS}_M0 tied together.

In my original post, I mentioned how I shoved the UART2 mux from M0 to M2 in the TPL, so I expected JTAG M2 to be available. Given they are using the same pins in the header, and my sd-card also worked with UART2M0, I don’t think that’s the problem.

use bootrom/rkdevtool

Am I supposed to do anything here? Like I said, with just a bare board (no sdcard, no SPI content), openocd shows me nothing with the command in my OP.

I can confirm that Rockchip RK3588 TRM V1.0-Part1-20220309.pdf:p1395 says “By default, jtag_tckm0 and jtag_tmsm0 are connected to corresponding IO pad.”
However, it also states “There are three sets of serial debug interface to debug.” which shows the JTAGM2 (that is my choice) is NOT tied to the sdcard.

#4

try to look at bare-rkxxxx
feel free to improve it :slight_smile:

#5

Neat! Is that something I’d be writing using something like rkdeveloptool db rk3588_spl_loader_v1.08.111.bin (where the bin would be replaced with that build output (whatever it does, I’m not an Assembly person and only took a peek, though it is small, so that helps with the fear-factor))?

EDIT0: I guess since I’ll be doing some experimenting, and I’m not fluent in Assembly, I’ll see about trying something with CMSIS (since there doesn’t appear to be any official rockchip SDK). Maybe just change the LED color as a first test.

EDIT1: Ah yes, I see your Makefile mentions rkdeveloptool.

#6

Okay, I finally got myself back to it after making an early first attempt.
I dropped CMSIS as it didn’t appear to support 64-bit.

I went with your code and adjusted it to:
//weird, markdown excludes the “.*” elements from the code markdown below.
.cpu cortex-a55
.global _start

VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_ADDRESS = 0xFD5FA148
VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_DATA = 0x08001D50

_start:
        # move from coprocessor register to arm register
        mrs x9, mpidr_el1
        # test it
        tst x9, 0b11
        b.eq . + 0x0c
        # 
        wfe
        b.al . - 0x04
        # move to x9 register bits 
        movz x9, :abs_g0_nc:VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_ADDRESS
        movk x9, :abs_g1:VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_ADDRESS
        movz w10, :abs_g0_nc:VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_DATA
        movk w10, :abs_g1:VCCIO3_5_IOC_GPIO4C_PULL_UP_DOWN_DATA
        str w10, [x9]
        b.al .

Built with: $ aarch64-linux-gnu-gcc -g -mcpu=cortex-a55 -nostdlib <file>.S -o <outFile>.elf
I then objdumped it with: $ aarch64-linux-gnu-objcopy -S -O <inFile>.elf <outFile>.bin
And then packed that bin with [SOLVED] Is there a way to load a program directly into SRAM using USB OTG? using $ pack.py rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.11.bin <inFile>.bin <loaderFile>.bin
And finally flashed it with $ rkdeveloptool db <loaderFile>.bin

rkdeveloptool looks to hang, which I guess you already know since you kill it in your Makefile.

Now the purpose of that app is to simply enable the red led, but I’m not sure if I’m even doing that right (obviously not since it doesn’t light up).

The radxa_rock_5b_v142_sch.pdf:p20 shows the red led is located at GPIO4-C5.
While Rockchip RK3588 TRM V1.0-Part1-20220309.pdf shows GPIO4 to be based at FEC50000:p19, I’m guessing I shouldn’t be going that route considering there’s no info on the data fields to go into that address, along with you using “GRF” addresses in your code.

The closest I could find with addresses that relate to manipulating that GPIO is BUS_IOC:p17 and VCCIO3_5_IOC:p17.
Specifically BUS_IOC_GPIO4C_IOMUX_SEL_H:p984 (IOMUX like the GRF*IOMUX in yours) and VCCIO3_5_IOC_GPIO4C_P:p1052.

It doesn’t look like I need to do anything with BUS_IOC_GPIO4C_IOMUX_SEL_H since it defaults to 0x00000000 which sets bits 7:4 to 4'h0: GPIO. So that seems good so far.
I see your code is setting the use of JTAG in your IOMUX, so that’s why you make changes with yours.

Then going to VCCIO3_5_IOC_GPIO4C_P, I see it is GPIO4C Pull-up/down Control:p1029 and defaults to 0x1550. The only thing I’m looking to change here I guess is bit 11 gpio4c5_ps which I set to 1 (1'b1: PU Selection). But that also means I need to change bit 27 to 1 to enable the write to bit 11.
So that changes from the default of 0x1550 to 0x08001D50.
The options are (name; offset; read/write; default; description):

“VCCIO3_5_IOC_GPIO4C_DS_H; 0x0094; W; 0x00000111; GPIO4C Driver Strength Control High bits”:p1041 (2’b01: 7.5mA 33ohm)
“VCCIO3_5_IOC_GPIO4C_P; 0x0148; W; 0x00001550; GPIO4C Pull-up/down Control”:p1052 (1’b0: PD Selection)
“VCCIO3_5_IOC_GPIO4C_P; 0x0148; W; 0x00001550; GPIO4C Pull-up/down Control”:p1052 (1’b1: PU/PD Enable)
“VCCIO3_5_IOC_GPIO4C_IE; 0x01B8; W; 0x0000007C; GPIO4C Input Enable Control”:p1057 (0x1 Active High input buffer enable)
“VCCIO3_5_IOC_GPIO4C_SMT; 0x0248; W; 0x00000000; GPIO4C Schmitt Trigger Control”:p1063 (1’b0: CMOS Input)

But like I said, it doesn’t seem to work (no red led).
So if you or anyone else have an eye for what I may be missing or doing wrong, I’m all ears/eyes.