FAQs for RTOS Debugger for Linux

The embedded tools company

Search FAQs

PDF document ( 90KB / 26-Oct-2020 )

After booting Linux, why does the target die or loose connection to the debugger?
Ref: 0395

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:
  • re-compile the kernel with disabled power management.
  • disable the idle states for all cores from the Linux shell e.g.
    echo 1 > /sys/devices/system/cpu/cpu<x>/cpuidle/state<x>/disable
  • remove the idle-states property from the device tree if available
  • add a command line parameter that disables power management if supported by the used Linux distrubution. This can be done for instance in NXP Linux distributions for i.MX using the "jtag=on" parameter. In some other distributions the "nohlt" parameter is used. Please refer to the documentation of the kernel command line parameters of your Linux distribution for more information.

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.
Ref: 0252

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.
Ref: 0426

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)

I can't get the mapping to Linux task names in the Trace.Chart.TASK window for Arm/Arm64.
Ref: 0552

Make sure that CONFIG_PID_IN_CONTEXTIDR is enabled in the Linux kernel configuration. Using this option, the kernel will write the Process ID on a task switch to the CONTEXTIDR Register which is then used by TRACE32 to identify the tasks.

On-chip breakpoints do not stop the program execution during kernel boot.
Ref: 0478

On-chip breakpoints can be removed by the kernel during boot:
  • The Linux kernel resets on Arm the breakpoints as well as the Vector Catch Register when booting if CONFIG_HAVE_HW_BREAKPOINT is enabled in the kernel configuration. See arch/<arm|arm64>/kernel/hw_breakpoint.c.
    This can be detected on Armv8 by enabling the option TrOnchip.Set TDA ON.
  • A similar problem can also be seen on Intel x86 when the debug registers are cleared during boot. Please refer to arch/x86/include/asm/debugreg.h. This can be detected by enabling the option TrOnchip.Set GeneralDetect ON.

The kernel boots fine without debugger, it crashes however when the debugger is attached.
Ref: 0477

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..."
Ref: 0521

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?
Ref: 0388

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?
Ref: 0304

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   Impressum     Privacy Policy
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: 26-Oct-2020