We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
I have a QCA IPQ4019 board. I am following this blog https://community.arm.com/tools/b/blog/posts/porting-linux-made-easy-with-ds-5 to debug from the stage in which u-boot loads the Kernel. I can get to below step described in the blog.
>A compressed kernel will stop at the breakpoint at 0x80008000 before decompressing.
(Note, in my case the breakpoint is 0x80208000)
But I encounter error "Target Message: Could not determine target state" and I can not control the CPU core any more. Below is the full log. Any advice why there is such error? Thanks !
Signals handled by operating system Connected to running target QCA - IPQ4019-detect-debug-and-trace on USB:002273 cd "/home/tonyhe/DS-5-Workspace" Working directory "/home/tonyhe/DS-5-Workspace" hbreak -d -p *N:0x80208000 Hardware breakpoint 1 at N:0x80208000 condition 1 break-script 1 "" ignore 1 0 break-stop-on-cores 1 unsilence 1 Breakpoint 1 unsilenced break-stop-on-vmid 1 enable 1 Breakpoint 1 enabled Execution stopped in SVC mode at breakpoint 1: N:0x80208000 N:0x80208000 BL {pc}+0x1a20 ; 0x80209a20 Target Message: Could not determine target state
update1: add more details or background of my question. IPQ4019 is with 4 cores. In the u-boot mode, the debugger can not connect 4 cores. I encounter below error when connecting 4 cores. Debugger can only connect 1 core. It seems that the other 3 cores are power-down. So in my question, only 1 core is connected. I am suspecting the only core is also power-down when I encounter error "Target Message: Could not determine target state". Any suggestion?
Hi Stuart,
Stuart Hirons said: Can you try rebuilding your kernel with CONFIG_CPU_IDLE=n
Can you try rebuilding your kernel with
CONFIG_CPU_IDLE=n
Unfortunately, it doesn't work. I though twice. Because the core is out of control before kernel is decompressed and started, modifying this option doesn't help.
Stuart Hirons said: Secondly, if you interrupt 4 cores the rebooting of the board is probably caused by a watchdog timer not being kicked anymore and so it decides that the processors have crashed and so reboots the target. In your kernel debug options, can you also try disabling it by setting : CONFIG_QCOM_WDT=n
Secondly, if you interrupt 4 cores the rebooting of the board is probably caused by a watchdog timer not being kicked anymore and so it decides that the processors have crashed and so reboots the target.
In your kernel debug options, can you also try disabling it by setting :
CONFIG_QCOM_WDT=n
It doesn't work either.
I suddenly note the first issue should be same with the second issue.
First issue: After a while when the HW breakpoint on the physical address where the bootloader is going to load/jump to the kernel is hit, the core is out of control and the board also reboot silently as the second one.
So above two issues happening at different stages may are caused by same root cause.
Tony He