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:Are you using a compressed kernel or uncompressed one ?
Stuart Hirons said:What kernel config options did you use to build the kernel ?
The kernel source code you can find here.https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/dandelion&id=187f00df199084e0a971a8a893fa13d37daa0b0c. This is the HEAD of commit.
Stuart Hirons said:What version of DS-5 are you using ?
v5.27.1.
More findings:
1. The error "Target Message: Could not determine target state" is encounted after a while. I guess about 10 secs. If I press the "continue" button immediately when the HW breakpoint is hit, this error is not encounted. However, the HW breakpoint is not hit any more . I expect after decompressing, code execution will stop at breakpoint again. In fact, the board can bring up successfully. But I want to go through from u-boot stage to the stage that MMU is enabled for studying. Below is the normal log without debugger. Do you know why?
(IPQ40xx) # bootipq [189/36702] MMC read: dev # 0, block # 11298, count 16384 ... 16384 blocks read: OK ## Booting kernel from FIT Image at 84000000 ... Using 'config@ap.dk04.1-c1' configuration Trying 'kernel@1' kernel subimage Description: ARM OpenWrt Linux-3.14.77 Type: Kernel Image Compression: gzip compressed Data Start: 0x840000e4 Data Size: 3333042 Bytes = 3.2 MiB Architecture: ARM OS: Linux Load Address: 0x80208000 Entry Point: 0x80208000 Hash algo: crc32 Hash value: c5897e53 Hash algo: sha1 Hash value: 6b4ada9edbe9ba5ea1ba7f4a38ca39e14df1791d Verifying Hash Integrity ... crc32+ sha1+ OK ## Flattened Device Tree from FIT Image at 84000000 Using 'config@ap.dk04.1-c1' configuration Trying 'fdt@ap.dk04.1-c1' FDT blob subimage Description: ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x84381e4c Data Size: 38506 Bytes = 37.6 KiB Architecture: ARM Hash algo: crc32 Hash value: fdd837e6 Hash algo: sha1 Hash value: d3dc88c9c414032285a836fb54e530e88e0757d1 Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0x84381e4c Uncompressing Kernel Image ... OK Loading Device Tree to 86ff3000, end 86fff669 ... OK Using machid 0x8010001 from environment Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.14.77 (tonyhe@tonyhe-H55M-S2) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r35193) ) #7 SMP PREEMPT Tue Aug 8 22:24:50 CS7 [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C1 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] PERCPU: Embedded 7 pages/cpu @dfbc7000 s8192 r8192 d12288 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125952 [ 0.000000] Kernel command line: cpuidle.off=1 rootfsname=rootfs rootwait clk_ignore_unused [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 495804K/507904K available (4590K kernel code, 373K rwdata, 1580K rodata, 184K init, 604K bss, 12100K reserved, 0K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB) [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0208000 - 0xc080ecec (6172 kB) [ 0.000000] .init : 0xc080f000 - 0xc083d000 ( 184 kB) [ 0.000000] .data : 0xc083e000 - 0xc089b548 ( 374 kB) [ 0.000000] .bss : 0xc089b548 - 0xc0932614 ( 605 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] Architected cp15 timer(s) running at 48.00MHz (virt). [ 0.000008] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps every 2863311552512ns [ 0.000017] Switching to timer-based delay loop [ 0.000330] Calibrating delay loop (skipped), value calculated using timer frequency.. 96.00 BogoMIPS (lpj=480000) [ 0.000347] pid_max: default: 32768 minimum: 301 [ 0.000612] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000628] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.012335] CPU: Testing write buffer coherency: ok [ 0.012694] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.012766] Setting up static identity map for 0x80213058 - 0x802130b0 [ 0.090627] CPU1: Booted secondary processor [ 0.090670] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.110624] CPU2: Booted secondary processor [ 0.110661] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.130664] CPU3: Booted secondary processor [ 0.130698] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.130835] Brought up 4 CPUs [ 0.130879] SMP: Total of 4 processors activated (384.00 BogoMIPS). [ 0.130887] CPU: All CPU(s) started in SVC mode. [ 0.141311] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5 [ 0.141696] pinctrl core: initialized pinctrl subsystem [ 0.142141] regulator-dummy: no parameters [ 0.142809] NET: Registered protocol family 16 [ 0.144356] DMA: preallocated 2048 KiB pool for atomic coherent allocations [ 0.155369] hw-breakpoint: Debug register access (0xee003e17) caused undefined instruction on CPU 3 [ 0.155377] hw-breakpoint: Debug register access (0xee003e17) caused undefined instruction on CPU 1 [ 0.155384] hw-breakpoint: Debug register access (0xee003e17) caused undefined instruction on CPU 2 [ 0.155391] hw-breakpoint: CPU 1 failed to disable vector catch [ 0.155422] hw-breakpoint: Debug register access (0xee003e17) caused undefined instruction on CPU 0
2. I also tried multi-core connection after the kernel brings up. DS-5 shows 4 cores are running instead of 1 in the bootloader mode. However, if I interrupt 4 cores, the board will reboot silently after a while. I am looking for the source of the silent reboot.
Thanks for your help!
Tony He
Hi Tony,
Many thanks for the update.
Can you try rebuilding your kernel with
CONFIG_CPU_IDLE=n
please ?
This is currently set to Y in your kernel options and may be preventing correct operation of the DSTREAM unit (see also https://community.arm.com/tools/b/blog/posts/error-tad9-nal52-why-is-ds-5-unable-to-control-my-target-when-debugging-the-linux-kernel-via-jtag)
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
Can you try these kernel options and let me know how you get on please ?
Your two solutions should be what I am looking for. I will try tomorrow when I get back to work. I see the hope to solve my problems, so I can not help replying you now. Thanks！
Stuart Hirons said: 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
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.