How to debug via JTAG on Hikey970?


#1

Hi,

I want to use a Segger J-Link Pro JTAG debugger to help me debug one PCIe problem that makes the kernel crash when two PCIe devices are present (e.g the onboard Realtek 6818 Ethernet and a mini-PCIe 802.11ac radio module).

My J-Link is connected via a ARM-JTAG-20-10 from Olimax to the female JTAG header on the Hikey970 (using an additional male-male 10 pin header).
When attempting to connect using the JLinkExe, the target voltage is correctly detected as 1.8V but I can’t connect/attach to the CPU.

C:\Program Files (x86)\SEGGER\JLink_V640>JLink.exe -device Cortex-A53
SEGGER J-Link Commander V6.40 (Compiled Oct 26 2018 15:06:29)
DLL version V6.40, compiled Oct 26 2018 15:06:02

Connecting to J-Link via USB...O.K.
Firmware: J-Link Pro V4 compiled Oct 26 2018 12:05:09
Hardware version: V4.00
S/N: xxxxxxxxx
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
IP-Addr: 192.168.100.2
VTref=1.833V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>auto
Device "CORTEX-A53" selected.

Connecting to target via SWD
Found SW-DP with ID 0x5BA02477
Failed to power up DAP
Found SW-DP with ID 0x5BA02477
Failed to power up DAP
Found SW-DP with ID 0x5BA02477
Failed to power up DAP
Found SW-DP with ID 0x5BA02477
Failed to power up DAP
Cannot connect to target.
J-Link>

The J-link input led (arrow from target to pc) is Orange constant, which according to the J-Link doc, seems to indicate that the target is in reset state…but this is not true because board has booted and is running linux. The J-Link output led is off.

The Hikey970 schematics doc refers two JTAG_SEL pins but the remaining documentation does not say how to set these pins or how to use the JTAG. This Hikey960 post seems to refer some steps how to enable the JTAG but I am not sure if they apply to the Hikey970…and they were not completely clear to me.

I’ve also tried to follow the OpenOCD JTAG and Hikey steps without success.

Has anyone tried to use the JTAG on the Hikey970?
Do I need to run some special J-Link script to enable the Hi3670 JTAG debug (based on Cortex A53/A73)?

Any suggestions/guidance would be very much appreciated.

Thanks.


Hikey970 running Debian image: Two PCIe devices cause kernel crash (possible race condition?)
#2

I apologize for insisting on this subject but so far, I couldn’t find anyone that reported to have been able to use the JTAG on the Hikey970 or to give me a little more information. But I find it hard to believe that no one has tried to use JTAG (e.g. to debug drivers or kernel).

Is anyone able to at least confirm that the steps referred on the Hikey960 documentation (to apply “01” to the JTAG_SEL pins) are still valid on the Hikey970?

To apply this “01” sequence, we should solder two wires on the referred test points? Or this should be done in another way?

Anyone knows where are these test points physically located on the baord? I’ve tried but couldn’t find them.

Thank you.


#3

I’ve not tried JTAG on either board but… I understand from my e-mail archive that if you’re using an FTDI/openocd stack on hikey960 you need srst_push_pull to get things to come alive. No idea what the equivalent setting is called for J-Link (or if this is also true to hikey970).


#4

Hi Daniel,

First of all, thank you for spending your time and trying to help me.
However I didn’t got further.

I took a look at that srst_push_pull setting (used on OpenOCD) but I am not sure if the equivalent in the JLink is the normal “Reset” or not (I suppose it should be).
Anyway, I decided to give it another try to eventually spot any mistake of mine while trying with the OpenOCD and ensured I was specifying that srst_push_pull.
For simplicity, I have just tried with what I believe is a minimal target config:

transport select jtag

adapter_khz 5000

jtag_ntrst_delay 300
reset_config trst_and_srst separate trst_push_pull srst_push_pull

set _CHIPNAME hi3670

set _TARGETNAME $_CHIPNAME.cpu

jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0x3 -enable

Command:

INTERFACE=interface/jlink.cfg
openocd -f ./tcl/$INTERFACE -f ./tcl/target/hi970_0.cfg

The output that I get is:

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 5000 kHz
jtag_ntrst_delay: 300
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
hi3670_dbginit
Info : No device selected, using first device.
Info : J-Link Pro V4 compiled Oct 26 2018 12:05:09
Info : Hardware version: 4.00
Info : VTarget = 1.857 V
Info : clock speed 5000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Error: hi3670.dap: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
^C

On Windows and using JLinkExe, I get:

Connecting to target via JTAG
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Could not measure total IR len. TDO is constant high.
Cannot connect to target.

and the led behavior is as I have described in my initial post (input led is ORANGE constant indicating target is in reset).

Based on this I still believe we need to perform some action on the board side to “expose” the JTAG chain.
And my only guess is that we should perform some action on those JTAG_SEL pins (either modifying the hardware or on the bootloader, actuating on the referred “GPIO_184” - which I don’t know for certain what will be the visible GPIO number/name known by the CPU since this platform uses 29 GPIO group modules, where the “GPIO22-27” module masks “GPIO_176-GPIO_223” - range does not match, which means the correspondence is not direct).
But without some help or without some proper documentation on this subject, just “trying-and-seeing what happens” could cause serious damage to the board or radios…

Kind regards


#5

Hi,

Just an update regarding the GPIO 184:

  • I was able to locate it through the device tree and it seems to correspond to GPIO_320 in Linux Kernel;

  • however, changing direction and forcing value to 1 or zero didn’t make any difference (JLink stills keeps the ORANGE led constant ON) and depending on the interface I choose (JTAG or SWD), it either complains:

    SWD (which based on the olimex 20-to-10 cable attached on the board should be the correct one):

    Type “connect” to establish a target connection, ‘?’ for help
    J-Link>con
    Please specify target interface:
    J) JTAG (Default)
    S) SWD
    T) cJTAG
    TIF>S
    Specify target interface speed [kHz]. : 4000 kHz
    Speed>auto
    Device “CORTEX-A53” selected.

    Connecting to target via SWD
    Found SW-DP with ID 0x5BA02477
    Failed to power up DAP
    Found SW-DP with ID 0x5BA02477
    Failed to power up DAP
    Found SW-DP with ID 0x5BA02477
    Failed to power up DAP
    Found SW-DP with ID 0x5BA02477
    Failed to power up DAP
    Cannot connect to target.
    J-Link>

    JTAG:

    Type “connect” to establish a target connection, ‘?’ for help
    J-Link>con
    Please specify target interface:
    J) JTAG (Default)
    S) SWD
    T) cJTAG
    TIF>J
    Device position in JTAG chain (IRPre,DRPre) : -1,-1 => Auto-detect
    JTAGConf>
    Specify target interface speed [kHz]. : 4000 kHz
    Speed>auto
    Device “CORTEX-A53” selected.

    Connecting to target via JTAG
    Could not measure total IR len. TDO is constant high.
    Could not measure total IR len. TDO is constant high.
    Could not measure total IR len. TDO is constant high.
    Could not measure total IR len. TDO is constant high.
    Cannot connect to target.
    J-Link>

It is possible that I am trying to actuate in this GPIO too late for the debugger to be able to get access to the core (but the JLink should be able to send a reset to the target anyway).
I will give it a few more tries trying to write to the GPIO memory location from the UEFI/GRUB/Bootloader command prompt…

Kind regards