i.MX ProcessorsのトピックRe: Linux kernel debug breakpoint problem

Linux kernel debug breakpoint problem

debuguser — Tue, 09 Feb 2016 11:27:16 GMT

Hello,

I have an i.MX7 Rev B board running Freescale Yocto Linux (Linux imx7dsabresd 3.14.38-6UL_ga+ge4944a5) and I'm debugging the kernel using JTAG halted mode debug.

I'm attempting to set a breakpoint so I can debug a kernel module, but when the breakpoint is hit, it causes a kernel exception rather entering into debug mode in the debugger:

root@imx7dsabresd:~# modprobe -r imx_rpmsg_tty

Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x80086600

Internal error: : 2 [#1] PREEMPT SMP ARM

Modules linked in: imx_rpmsg_tty evbug

CPU: 1 PID: 735 Comm: modprobe Not tainted 3.14.38-6UL_ga+ge4944a5 #4

task: a81c6880 ti: a8bc4000 task.ti: a8bc4000

PC is at SyS_delete_module+0x0/0x174

LR is at ret_fast_syscall+0x0/0x30

pc : [<80086600>] lr : [<8000e460>] psr: 80080013

sp : a8bc5fa8 ip : 10c53c7d fp : 000aedf0

r10: 00000000 r9 : a8bc4000 r8 : 8000e5e4

r7 : 00000081 r6 : 000aee24 r5 : 000aee24 r4 : 000aedf0

r3 : 00000000 r2 : 76f00104 r1 : 00000800 r0 : 000aee24

Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user

Control: 10c53c7d Table: a854c06a DAC: 00000015

Process modprobe (pid: 735, stack limit = 0xa8bc4238)

Stack: (0xa8bc5fa8 to 0xa8bc6000)

5fa0: 000aedf0 000aee24 000aee24 00000800 76f00104 00000000

5fc0: 000aedf0 000aee24 000aee24 00000081 00000001 00000000 00000001 000aedf0

5fe0: 76ec5eb0 7ebe4a64 00016e3c 76ec5ebc 60080010 000aee24 00000000 00000000

Code: e59510c8 e8bd40f8 eaffff84 80a78208 (e120be70)

---[ end trace 062b135e73d4dfd6 ]---

Segmentation fault

Logging shows that the CP14 DBGDSCR register has both the halted mode debug and monitor mode debug bits cleared when the exception is taken - this lead me to believe that the Cortex-A7 core is being powered down in some way and then restored, and it is this that is clearing the halted mode debug bit from the DBGDSCR - I can find nothing in the kernel which explicitly does this.

Disabling CPU idle by removing it from the kernel or disabling it by issuing the following commands:

echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable

echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state2/disable

echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state1/disable

echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state2/disable

didn't help.

It may be that the core is not powering down, however keeping the core busy by adding a ‘while 1’ loop in bash does help reduce this exception from happening, but does not solve the problem to an acceptable level.

Any help on this issue would be appreciated.

Thank you.

Andrew.

Re: Linux kernel debug breakpoint problem

jiri-b36968 — Tue, 09 Feb 2016 13:18:06 GMT

Hello Andrew,

If I have problem like this I would call ARM :smileyhappy:. We will check it.

Quick note 3.14.52 is available.

michalsusen

markruthenbeck

/Jiri

Re: Linux kernel debug breakpoint problem

jiri-b36968 — Thu, 11 Feb 2016 08:43:40 GMT

Hello Andrew,

this fault indicates some access issue.

some hits so far:

- WFI instruction in Linux which implements the delay have to be replaced by NOP - could be in kernel menu config.

- MMU has to be set correctly to enable debugger to access SoC - please check http://www.lauterbach.com/pdfnew/training_rtos_linux.pdf page 25 DACR

Please describe your setup more deeply (HW+SW). Presume that you use DS-5 + DSTREAM - please correct me. We will try to replicate it.

/Jiri

Re: Linux kernel debug breakpoint problem

debuguser — Thu, 11 Feb 2016 18:05:39 GMT

Hi Jiri,

I replaced the WFI instruction with NOP and the problem still happened, also the MMU global writes are enabled, there is no problem writing memory.

We now have an acceptable work around however - I'll look into this again in a couple of weeks, it might be tools related but difficult to tell.

Please close this thread and I'll create a new one when I have more precise information.

Thank you for your help,

Andrew.