Hi,
Sharing here the design notes and work in progress patches to get some early feedback on the implementation approach.
Introduction ============ This RFC is about extending Linux coresight driver support to address kernel panic and watchdog reset scenarios. This would help coresight users to debug kernel panic and watchdog reset with the help of coresight trace data.
For simplicity, watchdog and kernel panic are addressed in separate sections.
Coresight trace capture: Kernel panic -------------------------------------
From the coresight driver point of view, addressing the kernel panic situation has four main requirements.
a. Support for allocation of trace buffer pages from reserved memory area. Platform can advertise this using a new device tree property added to relevant coresight nodes.
b. Support for stopping coresight blocks at the time of panic
c. Saving required metadata in the specified format
d. Support for reading trace data captured at the time of panic
Allocation of trace buffer pages from reserved RAM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A new optional device tree property "memory-region" will be added to the ETR/ETF device nodes, that would give the base address and size of trace buffer.
Static allocation of trace buffers would ensure that both IOMMU enabled and disabled cases are handled. Also, platforms that support persistent RAM will allow users to read trace data in the subsequent boot without booting the crashdump kernel.
Note: For ETR sink devices, this reserved region will be used for both trace capture and trace data retrieval. For ETF sink devices, internal SRAM would be used for trace capture, and they would be synced to reserved region for retrieval.
Disabling coresight blocks at the time of panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In order to avoid the situation of losing relevant trace data after a kernel panic, it would be desirable to stop the coresight blocks at the time of panic.
This can be achieved by configuring the comparator, CTI and sink devices as below,
Comparator(triggers on kernel panic) --->External out --->CTI -- | ETR/ETF stop <------External In <--------------
Note: No supporting patches are shared for this, since we are planning to make use of the System configuration manager to achieve the required configuration. This is a work in progress.
Saving metadata at the time of kernel panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Coresight metadata involves all additional data that are required for a successful trace decode in addition to the trace data. This involves ETR/ETF, ETE register snapshot etc.
A new optional device property "memory-region" will be added to the ETR/ETF/ETE device nodes for this.
Reading trace data captured at the time of panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trace data captured at the time of panic, can be read from rebooted kernel or from crashdump kernel using the below mentioned interface.
Steps for reading trace data captured in previous boot ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1. cd /sys/bus/coresight/devices/tmc_etrXX/
2. Change to special mode called, read_prevboot.
#echo 1 > read_prevboot
3. Dump trace buffer data to a file,
#dd if=/dev/tmc_etrXX of=~/cstrace.bin
4. Reset back to normal mode
#echo 0 > read_prevboot
General flow of trace capture and decode incase of kernel panic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Enable source and sink on all the cores using the sysfs interface. ETR sink will have trace buffers allocated from reserved memory.
2. Run relevant tests.
3. On a kernel panic, all coresight blocks are disabled, necessary metadata is synced by kernel panic handler.
System would eventually reboot or boot a crashdump kernel.
4. For platforms that supports crashdump kernel, raw trace data can be dumped using the coresight sysfs interface from the crashdump kernel itself. Persistent RAM is not a requirement in this case.
5. For platforms that supports persistent RAM, trace data can be dumped using the the coresight sysfs interface in the subsequent Linux boot. Crashdump kernel is not a requirement in this case. Persistent RAM ensures that trace data is intact across reboot.
Coresight trace capture: Watchdog reset --------------------------------------- The main difference between addressing the watchdog reset and kernel panic case are below,
a. Saving coresight metadata need to be taken care by the SCP(system control processor) firmware in the specified format, instead of kernel.
b. Reserved memory region given by firmware for trace buffer and metadata has to be in persistent RAM. Note: This is a requirement for watchdog reset case but optional in kernel panic case.
Watchdog reset can be supported only on platforms that meet the above two requirements.
Testing so far: --------------- Watchdog reset has been tested on Marvell SOCs using the above approach on 5.x kernel version with sysfs method.
Linu Cherian (5): dt-bindings: arm: coresight-tmc: Add "memory-region" property ccoresight: tmc-etr: Add support to use reserved trace memory coresight: core: Add provision for panic callbacks coresight: tmc: Add support for panic sync handling coresight: tmc: Add support for reading tracedata from previous boot
.../bindings/arm/arm,coresight-tmc.yaml | 9 ++ drivers/hwtracing/coresight/coresight-core.c | 31 +++++ drivers/hwtracing/coresight/coresight-priv.h | 1 + .../hwtracing/coresight/coresight-tmc-core.c | 112 ++++++++++++++++++ .../hwtracing/coresight/coresight-tmc-etf.c | 69 +++++++++++ .../hwtracing/coresight/coresight-tmc-etr.c | 98 ++++++++++++++- drivers/hwtracing/coresight/coresight-tmc.h | 32 +++++ include/linux/coresight.h | 11 ++ 8 files changed, 362 insertions(+), 1 deletion(-)