What version of linux should I expect to contain a version of perf
that knows about libopencsd?
Debian is currently at 4.15.11. Is that new enough?
It contains a
tools/perf/arch/arm/util/cs-etm.c
and
tools/include/linux/coresight-pmu.h
but if I build perf (with make VF=1 -C tools/perf )
then Auto-detecting system features:
does not mention libopencsd.
but then make it doesn't try on x86?
some clue about whether to expect this to work with 4.15.11, or if I
need a newer mainline, or if that is not sufficient, and I still need
the perf-opencsd-master mentioned in the HOWTO would be useful. Or
perhaps https://github.com/Linaro/perf-opencsd is the place to go?
Also how does the enabling machinery work?
I can't enable this in debian until a) its in the debian mainline
kernel packages and b) libopencsd is uploaded, but I can mess with it
locally and get bugs filed to make it work in due course.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Hi
I'm adding Coresight tracing support to FreeBSD.
The kernel support is currently on review (https://reviews.freebsd.org/D14618, https://reviews.freebsd.org/D12875).
At this step I would like to include OpenCSD to base FreeBSD distribution, but I have small local change preventing me to do so.
Here is a small patch to OpenCSD attached. Can someone take a look? We use LLVM and the 'params' vector is left uninitialized in ETMv4 decoder.
I'm not sure if this is correct fix, but it works fine for us.
I also added a pull request here: https://github.com/Linaro/OpenCSD/pull/12
Thank you.
Ruslan
They're not needed anymore.
Suggested-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
Signed-off-by: Kim Phillips <kim.phillips(a)arm.com>
---
drivers/hwtracing/coresight/Kconfig | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index 506fe5db3074..d4f683366cd2 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -24,7 +24,7 @@ config CORESIGHT_LINKS_AND_SINKS
config CORESIGHT_LINK_AND_SINK_TMC
tristate "Coresight generic TMC driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Trace Memory Controller driver.
Depending on its configuration the device can act as a link (embedded
@@ -34,7 +34,7 @@ config CORESIGHT_LINK_AND_SINK_TMC
config CORESIGHT_SINK_TPIU
tristate "Coresight generic TPIU driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Trace Port Interface Unit driver,
responsible for bridging the gap between the on-chip coresight
@@ -45,7 +45,7 @@ config CORESIGHT_SINK_TPIU
config CORESIGHT_SINK_ETBV10
tristate "Coresight ETBv1.0 driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for the Embedded Trace Buffer version 1.0 driver
that complies with the generic implementation of the component without
@@ -53,7 +53,7 @@ config CORESIGHT_SINK_ETBV10
config CORESIGHT_SOURCE_ETM3X
tristate "CoreSight Embedded Trace Macrocell 3.x driver"
- depends on !ARM64 && CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT && !ARM64
help
This driver provides support for processor ETM3.x and PTM1.x modules,
which allows tracing the instructions that a processor is executing
@@ -62,7 +62,7 @@ config CORESIGHT_SOURCE_ETM3X
config CORESIGHT_SOURCE_ETM4X
tristate "CoreSight Embedded Trace Macrocell 4.x driver"
- depends on ARM64 && CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT && ARM64
help
This driver provides support for the ETM4.x tracer module, tracing the
instructions that a processor is executing. This is primarily useful
@@ -71,7 +71,7 @@ config CORESIGHT_SOURCE_ETM4X
config CORESIGHT_DYNAMIC_REPLICATOR
tristate "CoreSight Programmable Replicator driver"
- depends on CORESIGHT_LINKS_AND_SINKS
+ depends on CORESIGHT
help
This enables support for dynamic CoreSight replicator link driver.
The programmable ATB replicator allows independent filtering of the
@@ -80,7 +80,7 @@ config CORESIGHT_DYNAMIC_REPLICATOR
config CORESIGHT_STM
tristate "CoreSight System Trace Macrocell driver"
depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
- depends on STM && CORESIGHT_LINKS_AND_SINKS
+ depends on STM
help
This driver provides support for hardware assisted software
instrumentation based tracing. This is primarily used for
--
2.16.2
This allows modules to match struct device.bus to amba_bustype for the
purpose of casting the device to an amba_device with to_amba_device().
Cc: Alex Williamson <alex.williamson(a)redhat.com>
Cc: Eric Auger <eric.auger(a)redhat.com>
Cc: Russell King <linux(a)armlinux.org.uk>
[RESEND due to new coresight modularization dependency]
Signed-off-by: Kim Phillips <kim.phillips(a)arm.com>
---
Reviving https://lkml.org/lkml/2017/6/20/682, since it's needed by
CoreSight modularization, and I can't tell what fate the original
version had.
Change(s) from RFC: none.
drivers/amba/bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228d2f02..12283bd06733 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -197,6 +197,7 @@ struct bus_type amba_bustype = {
.pm = &amba_pm,
.force_dma = true,
};
+EXPORT_SYMBOL_GPL(amba_bustype);
static int __init amba_init(void)
{
--
2.16.2
Hi,
Any updates to below emails,.?
Awaiting your kind response for regarding my previous email. If it makes
sense to talk, please let me know how your calendar looks.
I would appreciate if you could pass along my details to the appropriate
person if you don't handle this.
Do you have any other requirement kindly let me know your exact target
industry and target audience and target location, we will provide the exact
cost and counts with many more ....
Regards,
Chris
From: Chris Samuel [mailto:chris.samuel@lead-marketings.com]
Sent: Tuesday, April 03, 2018 3:40 PM
To: 'coresight(a)lists.linaro.org'
Subject: IBM lotus-accounts
Hi,
A quick check to see if you would you be interested to acquire updated
Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint,
Accounts with verified email and phone numbers.
kindly let me know your exact target industry and target audience and target
location, we will provide the exact database counts with cost and many
more....
Appreciate your time and look forward to your response.
Best Regards,
Chris,
Marketing Executive,
If you do not want to receive from us then reply back "Unsubscribe" as a
Subject Line.
Tracing problem
I have been using CoreSight PTM component on Zynq for more than two
years. I started out by programming a simple library to program these
components on a “bare-metal” system (without OS). Then, I moved on Linux
and Mathieu Poirier (I can't thank him enough) helped me a lot during
this phase. So far, I have been tracing small portions of my
applications and the amount of trace generated was not that important. I
was getting the expected trace i.e. for each branch (direct or
indirect), I was getting a branch address packet in my trace. Now, I
started tracing the whole .text section of binaries and I am not
understanding the obtained trace.
Here is how I configure Linux kernel driver (Kernel v4.9):
|cd /sys/bus/coresight/devices/f889c000.ptm0 echo 1 > addr_idx echo 0 >
addr_acctype echo 0 > addr_idx echo 0 > addr_acctype echo 20 > mode echo
100e0 104b4 > addr_range # These two addresses represent the beginning
and end of .text section |
Then, I enable the trace sink component (either ETB or TPIU) and trace
source (PTM) component.
|cd /sys/bus/coresight/devices/ echo 1 > f8801000.etb/enable_sink echo 1
> f889c000.ptm0/enable_source |
Then, I run my application and stop tracing.
|./application.elf ./disable # simply writes 0 to each enabled component
(source and sink) |
Then, I recover the trace using |dd|.
When I trace small portions of my application, the obtained trace gives
the right behavior. I check it manually by looking at |objdump| of the
binary.
However, when I trace the whole .text section of the application, the
amount of obtained trace is very small (even smaller than if I trace
only main function of the application) which is quite strange for me.
Basically, the obtained trace is going through libc functions that call
the main function and it stops while it is in libc. I don’t understand
why I am getting this strange behavior. Do you have any ideas about what
I am doing wrong.
I have attached a binary source code that I am trying to trace.
Thank you for your help and time.
Best regards,
Muhammad
Hi,
A quick check to see if you would you be interested to acquire updated
Slack, IBM Lotus Domino, IBM Lotus Notes, LogMeIn, Microsoft SharePoint,
Accounts with verified email and phone numbers.
kindly let me know your exact target industry and target audience and target
location, we will provide the exact database counts with cost and many
more....
Appreciate your time and look forward to your response.
Best Regards,
Chris,
Marketing Executive,
If you do not want to receive from us then reply back "Unsubscribe" as a
Subject Line.
This patch set is to explore Coresight tracing data for postmortem
debugging. When kernel panic happens, the Coresight panic kdump can
help to save on-chip tracing data and tracer metadata into DRAM, later
relies on kdump and crash/perf tools to recovery tracing data for
"offline" analysis.
The documentation is important to understand the purpose of Coresight
panic kdump, the implementation of framework and usage. Patches 0001
and patch 0002 are used for creating new sub directory for placing
Coresight docs and add a new doc for Coresight panic kdump.
Patch 0003 introduces the simple panic kdump framework which provides
helper functions can be used by Coresight devices, and it registers
panic notifier for dump tracing data.
Patches 0004/0005 support panic kdump for ETB; Patch 0006 supports the
kdump for ETMv4.
This patch set has been reworked by following suggestions at Linaro
HKG18 connect (mainly suggestions from Mathieu, thanks a lot!), and
it's rebased on acme git tree [1] with last commit 109d59b900e7 ('perf
vendor events s390: Add JSON files for IBM z14').
Due Coresight kdump data structure has been changed significantly, the
corresponding crash extension program also has been updated for this
reason [2]; furthermore the crash extension program is updated to
dynamically generate kernel buildid according to vmlinux elf info [3],
this is a fixing for the old code which uses hard-coded buildid value.
This patch set has been verified on 96boards Hikey620 with Coresight
enabling by the sysFS interface. Also the updated crash extension
program has been verified to cowork with Coresight panic kdump and it
successfully extracts tracing data from the vmcore and finally can be
decoded by perf tool.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
[2] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump.c
[3] https://git.linaro.org/people/leo.yan/crash.git/tree/extensions/csdump_buil…
Changes from v3:
* Following Mathieu suggestion, reworked the panic kdump framework,
used kdump array to maintain source and sink device handlers;
* According to Mathieu suggestion, optimized panic notifier to
firstly dump panic CPU tracing data and then dump other CPUs tracing
data;
* Refined doc to reflect these implementation changes;
* Changed ETMv4 driver to add source device handler at probe phase;
* Refactored crash extension program to reflect kernel changes.
Changes from v2:
* Add the two patches for documentation.
* Following Mathieu suggestion, reworked the panic kdump framework,
removed the useless flag "PRE_PANIC".
* According to comment, changed to add and delete kdump node operations
in sink enable/disable functions;
* According to Mathieu suggestion, handle kdump node
addition/deletion/updating separately for sysFS interface and perf
method.
Changes from v1:
* Add support to dump ETMv4 meta data.
* Wrote 'crash' extension csdump.so so rely on it to generate 'perf'
format compatible file.
* Refactored panic dump driver to support pre & post panic dump.
Changes from RFC:
* Follow Mathieu's suggestion, use general framework to support dump
functionality.
* Changed to use perf to analyse trace data.
Leo Yan (6):
doc: Add Coresight documentation directory
doc: Add documentation for Coresight panic kdump
coresight: Support panic kdump functionality
coresight: tmc: Hook callback for panic kdump
coresight: Set and clear sink device handler for kdump node
coresight: etm4x: Support panic kdump
Documentation/trace/coresight-cpu-debug.txt | 187 ----------
Documentation/trace/coresight.txt | 383 ---------------------
.../trace/coresight/coresight-cpu-debug.txt | 187 ++++++++++
.../trace/coresight/coresight-panic-kdump.txt | 130 +++++++
Documentation/trace/coresight/coresight.txt | 383 +++++++++++++++++++++
MAINTAINERS | 5 +-
drivers/hwtracing/coresight/Kconfig | 9 +
drivers/hwtracing/coresight/Makefile | 1 +
drivers/hwtracing/coresight/coresight-etm-perf.c | 5 +
drivers/hwtracing/coresight/coresight-etm4x.c | 27 ++
drivers/hwtracing/coresight/coresight-etm4x.h | 15 +
.../hwtracing/coresight/coresight-panic-kdump.c | 199 +++++++++++
drivers/hwtracing/coresight/coresight-priv.h | 12 +
drivers/hwtracing/coresight/coresight-tmc-etf.c | 30 ++
drivers/hwtracing/coresight/coresight.c | 16 +-
include/linux/coresight.h | 4 +
16 files changed, 1019 insertions(+), 574 deletions(-)
delete mode 100644 Documentation/trace/coresight-cpu-debug.txt
delete mode 100644 Documentation/trace/coresight.txt
create mode 100644 Documentation/trace/coresight/coresight-cpu-debug.txt
create mode 100644 Documentation/trace/coresight/coresight-panic-kdump.txt
create mode 100644 Documentation/trace/coresight/coresight.txt
create mode 100644 drivers/hwtracing/coresight/coresight-panic-kdump.c
--
2.7.4
