FAQs for RTOS Debugger for Linux
|After booting Linux, why does the target die or loose connection to the debugger?|
This is often caused by the kernel power management which turns the on-chip debug module off while going to power saving mode.
Possible solutions are:
|After halting at a function entry point with an on-chip breakpoint, or after stepping into a new function, the List window shows "???" for all assembler lines.|
This behavior is probably caused by the on demand paging mechanism of Linux.
Please read the "On-Demand Paging" chapter in the Linux Awareness Manual.
|Breakpoint are not working properly or stop working completely for the PowerPC e500 cores.|
The Linux kernel for e500 cores (PQ3/MPC85XX/QorIQ P10XX/P2020) has to be patched to enable debugging via JTAG. The MSR_KERNEL macro defined in arch/powerpc/include/asm/reg_book.h needs to be changes to include the MSR_DE bit: #define MSR_KERNEL (MSR_ME|MSR_RI|MSR_CE|MSR_DE)
|On-chip breakpoints do not stop the program execution during kernel boot.|
On-chip breakpoints can be removed by the kernel during boot:
|The kernel boots fine without debugger, it crashes however when the debugger is attached.|
You should check the information printed by the kernel when it panics. Some Linux kernel distributions have security mechanisms that treat a connected debugger via JTAG as a security violation and enter an infinite loop. This behavior can generally be deactivated by editing the kernel configuration or patching the kernel. In the case of some NXP Linux kernels for the i.MX processor family for instance, this security mechanism can be disabled by disabling CRYPTO_DEV_FSL_CAAM_SECVIO in the kernel configuration.
In some other cases, the crash could be simply due to debugging only a subset of the cores used by an SMP kernel. In case you attach the debugger to a single core for instance and halt that core, the SMP kernel panics as it detects that single cores are blocked.
|The kernel prints while debugging the warning "rcu_sched detected stalls on CPUs/tasks..."|
The kernel includes an RCU stall detection. You get this warning if you stop the program execution longer that the RCU timeout ( CONFIG_RCU_CPU_STALL_TIMEOUT ). You can disable this detection by writing 1 to the kernel variable rcu_cpu_stall_suppess :
Var.set rcu_cpu_stall_suppress = 1
|What does the kernel message soft lockup mean?|
The kernel detects when there is too much time gone between two timer ticks. This easily happens, if the system is halted with the debugger. Please switch off the soft lockup detection by disabling CONFIG_DETECT_SOFTLOCKUP in the kernel configuration.
|What is needed to revise a Linux trace with a TRACE32 instruction set simulator?|
The TRACE32 Linux awareness offers a dialogue window to save important information for a belated trace analysis on the TRACE32 Instruction Set Simulator. You just need to select the menu "Linux" > "Generate RAM Dump". The dialogue is based on the script ramdump.cmm available in the path of the Linux awareness.
Copyright © 2020 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 10-Jan-2020