Enabling JTAG for i.MX8MQ

[kunalkotecha1]

Hi NXP Team,

I am facing an issue with i.MX8MQ and the system is getting hanged at any time. So, debug this further we are trying to connect JTAG. We have Jlink Plus Segger with us and we tried with JLinkGDBServer utility, however, in the supported devices list it is not showing i.MX8MQ A-53 core. I believe i.MX8MQ A-53 core is not supported by JTAB. Is this understanding correct?

So, we are following the steps mentioned in this ticket, which uses openocd with JTAG. We are able to connect to the device and when it is connected it halts the core A-53. With "continue" command we can resume the processor. However, we are not able to set any breakpoint. While resuming from halt after setting any breakpoint, GDB gives an error and openocd tells unable to set breakpoint error. Can anyone please suggest if I am missing anything? It is very much urgent for us to continue with debugging the system hang issue. Thank you in advance.

Regards,

Kunal

[jdavid75_presonus]

Any more info on this thread?  I have the exact same problem as you describe:  I can connect with openocd, I can then connect with gdb and halt execution.  The program counter matches correctly to the source file location.  If I set a breakpoint, it says it is set at a virtual address and source file location, but when I "continue" I get the same error message as you, with very similar debug output from openocd.

Furthermore, I believe it is something more subtle than not being able to access memory, because I can disassemble the virtual address correctly, I can view the memory with "x" command from gdb.  I just can't run once a breakpoint is set.

[sinanakman]

Hi Kunal

It seems when you halt at 0x000000000091577c this is before the MMU is enabled. So the break point address 0xffff80001009d270 is probably not yet mapped. You need to continue until after the the page tables are set and this address range is available.. I don't use JLINK but for example with my BDI3000 I can set break points using physical addresses or have the it translate the address using kernel page tables. I recommend to set break points first where the memory maps are set and then you can set further break points in the new address space.

Hope this helps

Regards

Sinan Akman

[kunalkotecha1]

Hi @sinanakman,

I tried setting the breakpoint at the current program counter i.e. 0x000000000091577c and then set the breakpoint to another address like 0xffff80001009d270. In this case, also GDB and openocd are giving the same error as shared previously. I believe page tables will be loaded once the kernel has completed booting right? Can you suggest any command or way to debug further?

Regards,

Kunal

[sinanakman]

Hi Kunal

I suggest after you halt successfully out of reset find out where you are with this address 0x91577c . If this is your early boot loader code debug through there to see how the address space is being set up. With this knowledge, when it loads the kernel find out the address of your kernel's early code. Again debug through there to see how it maps memory. You can then set up break points in that address space in other routines easily. It can be a bit tedious but it will give you ability and full clarity on how to debug a code that maps or remaps the address space. With my debugger I usually set a break point at an early kernel address and then provide the address of kernel pages to debugger for address translation. Not every debugger has this capability.

As for the debugger suggestion I use BDI3000 and PEEDI and both works fine on ARMv8. If you need more information on those please send me an e-mail.

Best regards

Sinan Akman

[igorpadykov]

Hi Kunal

unfortunately I am not aware of JLink scripts supporting Cortex-A53, may be recommended

to apply to segger directly:

https://forum.segger.com/index.php/Thread/4447-SOLVED-Cortex-A53-support/
NXP uses Lauterbach Trace32 as debugger tool for Cortex-A53 cores.

Best regards
igor

[kunalkotecha1]

Hi @igorpadykov,

Can you share the exact part number/model/version of the debugger that can be used with i.MX8MQ A53? The debugger product page will be an added help.

Regards,

Kunal

[igorpadykov]

 

https://www.lauterbach.com/frames.html?home.html

Best regards
igor

[kunalkotecha1]

Thank you, @igorpadykov  and @sinanakman

For now, we can close this ticket.

Regards,

Kunal

[sinanakman]

Hi Kunal

It looks like by the time your JTAG probe tries to halt the SoC it already hangs and debug communication is not possible.

I recommend that instead of gdb client use the telnet interface to reset and halt your board. You might be able to see some more info at the telnet command line if halt didn't work. If this is the case you can try to insert brk instructions early in the code that you are debugging before the hang happens and single step and/or set new break points from there.

Hope this helps

Regards

Sinan Akman

[kunalkotecha1]

Hi @sinanakman,

Thank you for your response. Below are the steps I am using to communicate JLink Plus with i.MX8MQ via OpenOCD:

1. sudo openocd -f interface/jlink.cfg -f board/nxp_mcimx8m-evk.cfg [cloned and compiled openocd]
2. . environment-setup-aarch64-poky-linux [toolchain setup for target]

Start GDB Client

1. aarch64-poky-linux-gdb vmlinux
2. set directories linux-imx
3. target extended-remote localhost:3333

After this JTAG is connected and i.MX8MQ system halts with GDB logs : "0x000000000091577c in ?? ()". After this, if I provide continue command using gdb, the i.MX8MQ system resumes from halt state.

Now, in order to set any breakpoint, I again kept the system into a halt state and provided the "b cpu_suspend" command in gdb. It is able to set the breakpoint with gdb logs "Breakpoint 1 at 0xffff80001009d270: file /usr/src/kernel/arch/arm64/kernel/suspend.c, line 87". However, I am not able to resume the system from halt state if I provide any breakpoints. While giving "continue" command after setting breakpoints:

GDB Error: 

Cannot insert breakpoint 1.
Cannot access memory at address 0xffff80001009d270

OpenOCD Error: 

Debug: 9657 26077 gdb_server.c:3272 gdb_input_inner(): received packet: 'mffff80001009d270,4'
Debug: 9658 26077 gdb_server.c:1463 gdb_read_memory_packet(): addr: 0xffff80001009d270, len: 0x00000004
Debug: 9659 26077 target.c:2431 target_read_buffer(): reading buffer of 4 byte at 0xffff80001009d270
Debug: 9696 26079 aarch64.c:2062 aarch64_read_cpu_memory(): Reading CPU memory address 0xffff80001009d270 size 4 count 1
Error: 9859 26090 aarch64.c:2132 aarch64_read_cpu_memory(): abort occurred - dscr = 0x03007f53
Debug: 9986 26095 armv8_dpm.c:1345 armv8_dpm_handle_exception(): Exception taken to EL 3, DLR=0x0000000000919800 DSPSR=0x600002cc
Debug: 9987 26095 armv8_dpm.c:560 armv8_dpm_modeswitch(): restoring mode, cpsr = 0x600002cc

I believe there is some problem with accessing the memory. Also, below is the hwstatus of i.MX8MQ. 

(gdb) monitor jlink hwstatus
VTarget = 3.328 V
TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1

Can you please suggest what could be the issue here? Any approaches will be appreciated.

Regards,

Kunal

[haidong_zheng]

@kunalkotecha1 :

In my test, I see the same issue when set sw breakpoint under Linux Kernel. 

I assume memory can't be modified under Linux Kernel if sw breakpoint used. 

But if we use HW breakpoint, openocd breakpoint setting will work well. 

For HW breakpoint there is another issue, openocd cfg file may declare 4 cores for 8MQ/8MM/8MP, but only examine one core at openocd startup.

So openocd startup:

Option 1:

Set A53 cores to 1 in tcl/board/imx8mq-evk.cfg (or other cfg for other 8M chips) and limit Linux Kernel cpus=1 in boot args:maxcpus=1 

Option 2:

examine all cores at openocd startup by change:

tcl/target/imx8m.cfg

for { set _core 0 } { $_core < $_cores } { incr _core } {

cti create $_CTINAME.$_core -dap $_CHIPNAME.dap -ap-num 1 \
-baseaddr [lindex $CTIBASE $_core]

set _command "target create $_TARGETNAME.$_core aarch64 -dap $_CHIPNAME.dap \
-dbgbase [lindex $DBGBASE $_core] -cti $_CTINAME.$_core"

if { $_core != 0 } {
# non-boot core examination may fail
# set _command "$_command -defer-examine"
set _smp_command "$_smp_command $_TARGETNAME.$_core"
} else {
set _smp_command "target smp $_TARGETNAME.$_core"
}

eval $_command
}