Hi,
I have followed procedure to integrate libopenCSD in perf tool in target ARM. (based on kernel 4.18rc1)
I’ve seen in documentation that perf record need parameters cs_etm/(a)xxxxx.etr/u …<mailto:cs_etm/@xxxxx.etr/u%20…>
I would like to know if ETR device is mandatory to use coresight trace with perf ?
In my architecture, I’ve :
1 .funnel
1 .tpiu
2 .etm
1 .etf
1 .stm
1 replicator but no ETR ☹
If possible without ETR, do you have examples of perf record cmd usage ?
I’ve configured my coresight register as followed :
echo 1 > /sys/bus/coresight/devices/xxxx.stm/hwevent_select
echo 2 > /sys/bus/coresight/devices/xxxx.stm/hwevent_extmux_select
// Need to track IRQ up of UART
echo 0x200000 > /sys/bus/coresight/devices/xxxx.stm/hwevent_enable
echo 1 > /sys/bus/coresight/devices/yyyy.etf/enable_sink
echo 1 > /sys/bus/coresight/devices/xxxx.stm/enable_source
Which perf record cmd I must enter to catch my STM event ?
Thanks for your help.
Christophe.
Hi Mike, Mathieu,
[ + CoreSight ML ]
When I work on the CoreSight + perf tool and used crash extension
program to extract the tracing data from perf aux buffer, finally I
can get the trace data for about 1.6MB from ETF sink from DB410c board.
To verify the extracted trace data, I used 'snapshot' mode under
OpenCSD code base, you could see the tar file for this [1]. After
you download this file, you could place it under OpenCSD folder:
$ cp db410c_snapshot_kdump.tgz my_opencsd/decoder/tests/snapshots
$ cd my_opencsd/decoder/tests/snapshots
$ tar zxvf db410c_snapshot_kdump.tgz
$ cd db410c_snapshot_kdump
$ ../../bin/builddir/trc_pkt_lister
$ ../../bin/builddir/trc_pkt_lister -decode
If I use the command 'trc_pkt_lister' without any extra options, it
can print out trace packets successfully; but if I add the extra
option '-decode' it uses 'decode all' mode and it reports the errors as:
483710 Idx:53086; ID:10; [0xf8 ]; I_ATOM_F3 : Atom format 3.; NNN
483711 Idx:53086; ID:10; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0xffff000008abc9f0 )
483712 Idx:53088; ID:10; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE
483713 Idx:53194; ID:10; [0x6b 0x8c 0x08 0xfa 0xdc 0x95 0x5c ]; I_COND_RES_F1 : Conditional Result, format 1.
483714 DCD_ETMV4_0016 : 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Data Path fatal error
483715 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Trace buffer done, processed 53216 bytes.
You also could check detailed log trc_pkt_lister.ppl in the shared
tar packet; After searched for the OpenCSD code and found this error is
due it cannot support some types of packets [2].
So want to check what's the best for this issue; seems to me we need
to fix this so it can support well to complete the decoding?
Thanks in advance for suggestion.
Leo Yan
[1] http://people.linaro.org/~leo.yan/opencsd_db410c/db410c_snapshot_kdump.tgz
[2] https://github.com/Linaro/OpenCSD/blob/master/decoder/source/etmv4/trc_pkt_…
Good day Leo,
Please meet my new friend Christophe. He is from ST-Micro and is
currently working on integrating the CS framework in their next
platform. I would be grateful if you could share with him the
instructions you have used to get STM doing on the dragon board and
how you got the snapshot decoder to decode the traces.
Christophe is also looking to get a trace snapshot that is known to be
working properly to test in his environment.
Many thanks,
Mathieu
This series adds the support for using the tmc-etr in perf mode for
storing the trace to system RAM. The ETR uses a separate buffer (double
buffering) for storing the trace. This is copied back to the ring buffer
when the event is stopped. We try to match the ETR buffer to the larger
of perf ring buffer or the size configured for the ETR via sysfs. This
allows tuning the buffer size to prevent overflows and loosing trace
data, as we don't have overflow interrupt support (yet).
Applies on coresight/next
Changes since v2:
- Split hotplug lock cleanup from per-cpu path management
- Add support for tracing on hotplugged CPUs (based on patch by Mathieu)
- Fix handling of perf mode in etb10 driver
- Fix CS_UNLOCK() typo in ETR perf driver
- Rename call backs from tmc_etr_<op>_perf_buffer => tmc_<op>_etr_buffer
to be consistent with ETF driver
- Modify the commit description for removing set_buffer call back.
Changes since v1 :
- Fix path for each CPU where the event might be recorded.
- Handle errors in enabling source
- Remove set_buffer callback to avoid complicating the error handling.
- Fix a bug in handling sysfs mode specific buffers
Changes since [0] :
- Drop buffer rotation logic for etr-buf
- Do not use perf ring buffer. (Add support later)
- Fix handling of sink, preventing mixed modes of operation.
[0] - TMC ETR perf support
- http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
Suzuki K Poulose (13):
coresight: Fix handling of sinks
coresight: etb10: Fix handling of perf mode
coresight: perf: Fix per cpu path management
coresight: perf: Avoid unncessary CPU hotplug read lock
coresight: perf: Allow tracing on hotplugged CPUs
coresight: perf: Disable trace path upon source error
coresight: tmc-etr: Handle driver mode specific ETR buffers
coresight: tmc-etr: Relax collection of trace from sysfs mode
coresight: Convert driver messages to dev_dbg
coresight: perf: Remove reset_buffer call back for sinks
coresight: perf: Add helper to retrieve sink configuration
coresight: perf: Remove set_buffer call back
coresight: etm-perf: Add support for ETR backend
.../coresight/coresight-dynamic-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-etb10.c | 100 +++----
drivers/hwtracing/coresight/coresight-etm-perf.c | 134 +++++----
drivers/hwtracing/coresight/coresight-etm-perf.h | 26 ++
drivers/hwtracing/coresight/coresight-etm3x.c | 4 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 4 +-
drivers/hwtracing/coresight/coresight-funnel.c | 4 +-
drivers/hwtracing/coresight/coresight-priv.h | 2 +-
drivers/hwtracing/coresight/coresight-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-stm.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 94 +++---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 327 ++++++++++++++++++---
drivers/hwtracing/coresight/coresight-tmc.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc.h | 4 +
drivers/hwtracing/coresight/coresight-tpiu.c | 6 +-
drivers/hwtracing/coresight/coresight.c | 31 +-
include/linux/coresight.h | 12 +-
17 files changed, 517 insertions(+), 247 deletions(-)
--
2.7.4
New version of the library has been released.
Fixes issue raised where a segfault can occur in the memory caching
code if the first memory
location the decoder attempts to access does not have an associated
memory image registered
with the library
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Coresight uses DT graph bindings to describe the connections of the
components. However we have some undocumented usage of the bindings
to describe some of the properties of the connections.
The coresight driver needs to know the hardware ports invovled
in the connection and the direction of data flow to effectively
manage the trace sessions. So far we have relied on the "port"
address (as described by the generic graph bindings) to represent
the hardware port of the component for a connection.
The hardware uses separate numbering scheme for input and output
ports, which implies, we could have two different (input and output)
ports with the same port number. This could create problems in the
graph bindings where the label of the port wouldn't match the address.
e.g, with the existing bindings we get :
port@0{ // Output port 0
reg = <0>;
...
};
port@1{
reg = <0>; // Input port 0
endpoint {
slave-mode;
...
};
};
With the new enforcement in the DT rules, mismatches in label and address
are not allowed (as see in the case for port@1). So, we need a new mechanism
to describe the hardware port number reliably.
Also, we relied on an undocumented "slave-mode" property (see the above
example) to indicate if the port is an input port. Let us formalise and
switch to a new property to describe the direction of data flow.
There were three options considered for the hardware port number scheme:
1) Use natural ordering in the DT to infer the hardware port number.
i.e, Mandate that the all ports are listed in the DT and in the ascending
order for each class (input and output respectively).
Pros :
- We don't need new properties and if the existing DTS list them in
order (which most of them do), they work out of the box.
Cons :
- We must list all the ports even if the system cannot/shouldn't use
it.
- It is prone to human errors (if the order is not kept).
2) Use an explicit property to list both the direction and the hw port
number and direction. Define "coresight,hwid" as 2 member array of u32,
where the members are port number and the direction respectively.
e.g
port@0{
reg = <0>;
endpoint {
coresight,hwid = <0 1>; // Port # 0, Output
}
};
port@1{
reg = <1>;
endpoint {
coresight,hwid = <0 0>; // Port # 0, Input
};
};
Pros:
- The bindings are formal but not so reader friendly and could
potentially lead to human errors.
Cons:
- Backward compatiblity is lost.
3) Use explicit properties (implemented in the series) for the hardware
port id and direction. We define a new property "coresight,hwid" for
each endpoint in coresight devices to specify the hardware port number
explicitly. Also use a separate property "direction" to specify the
direction of the data flow.
e.g,
port@0{
reg = <0>;
endpoint {
direction = <1>; // Output
coresight,hwid = <0>; // Port # 0
}
};
port@1{
reg = <1>;
endpoint {
direction = <0>; // Input
coresight,hwid = <0>; // Port # 0
};
};
Pros:
- The bindings are formal and reader friendly, and less prone to errors.
Cons:
- Backward compatibility is lost.
After a round of discussions [1], the following option (4) is adopted :
4) Group ports based on the directions under a dedicated node. This has been
checked with the upstream DTC tool to resolve the "address mismatch" issue.
e.g,
out-ports { // Output ports for this component
port@0 { // Outport 0
reg = 0;
endpoint { ... };
};
port@1 { // Outport 1
reg = 1;
endpoint { ... };
};
};
in-ports { // Input ports for this component
port@0 { // Inport 0
reg = 0;
endpoint { ... };
};
port@1 { // Inport 1
reg = 1;
endpoint { ... };
};
};
This series implements Option (4) listed above and falls back to the old
bindings if the new bindings are not available. This allows the systems
with old bindings work with the new driver. The driver now issues a warning
(once) when it encounters the old bindings. The series contains DT update
for Juno platform. The remaining in-kernel sources could be updated once
we are fine with the proposal.
It also cleans up the platform parsing code to reduce the memory usage by
reusing the platform description.
Applies on coresight/next
Changes since V1:
- Implement the proposal by Rob.
- Drop the DTS updates for all platforms except Juno
- Drop the incorrect fix in coresight_register. Instead document the code
to prevent people trying to un-fix it again.
- Add a patch to drop remote device references in DT graph parsing
- Split of_node refcount fixing patch, fix a typo in the comment.
- Add Reviewed-by tags from Mathieu.
- Drop patches picked up for 4.18-rc series
Changes since RFC:
- Fixed style issues
- Fix an existing memory leak coresight_register (Found in code update)
- Fix missing of_node_put() in the existing driver (Reported-by Mathieu)
- Update the existing dts in kernel tree.
Suzuki K Poulose (10):
coresight: Document error handling in coresight_register
coresight: platform: Refactor graph endpoint parsing
coresight: platform: Fix refcounting for graph nodes
coresight: platform: Fix leaking device reference
coresight: Fix remote endpoint parsing
coresight: Add helper to check if the endpoint is input
coresight: platform: Cleanup coresight connection handling
coresight: dts: Document usage of graph bindings
coresight: Cleanup coresight DT bindings
dts: juno: Update coresight bindings for hw port
.../devicetree/bindings/arm/coresight.txt | 95 ++++----
arch/arm64/boot/dts/arm/juno-base.dtsi | 161 ++++++-------
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 52 ++--
arch/arm64/boot/dts/arm/juno.dts | 13 +-
drivers/hwtracing/coresight/coresight.c | 35 +--
drivers/hwtracing/coresight/of_coresight.c | 262 ++++++++++++++-------
include/linux/coresight.h | 9 +-
7 files changed, 353 insertions(+), 274 deletions(-)
--
2.7.4
This series adds the support for using the tmc-etr in perf mode for
storing the trace to system RAM. The ETR uses a separate buffer (double
buffering) for storing the trace. This is copied back to the ring buffer
when the event is stopped. We try to match the ETR buffer to the larger
of perf ring buffer or the size configured for the ETR via sysfs. This
allows tuning the buffer size to prevent overflows and loosing trace
data, as we don't have overflow interrupt support (yet).
Applies on coresight/next
Changes since v1 :
- Fix path for each CPU where the event might be recorded.
- Handle errors in enabling source
- Remove set_buffer callback to avoid complicating the error handling.
- Fix a bug in handling sysfs mode specific buffers
Changes since [0] :
- Drop buffer rotation logic for etr-buf
- Do not use perf ring buffer. (Add support later)
- Fix handling of sink, preventing mixed modes of operation.
[0] - TMC ETR perf support
- http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
Suzuki K Poulose (10):
coresight: Fix handling of sinks
coresight: perf: Fix per cpu path management
coresight: perf: Disable trace path upon source error
coresight: tmc-etr: Handle driver mode specific ETR buffers
coresight: tmc-etr: Relax collection of trace from sysfs mode
coresight: Convert driver messages to dev_dbg
coresight: perf: Remove reset_buffer call back for sinks
coresight: perf: Add helper to retrieve sink configuration
coresight: perf: Remove set_buffer call back
coresight: etm-perf: Add support for ETR backend
.../coresight/coresight-dynamic-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-etb10.c | 84 ++----
drivers/hwtracing/coresight/coresight-etm-perf.c | 91 +++---
drivers/hwtracing/coresight/coresight-etm-perf.h | 26 ++
drivers/hwtracing/coresight/coresight-etm3x.c | 4 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 4 +-
drivers/hwtracing/coresight/coresight-funnel.c | 4 +-
drivers/hwtracing/coresight/coresight-priv.h | 2 +-
drivers/hwtracing/coresight/coresight-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-stm.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 94 +++---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 327 ++++++++++++++++++---
drivers/hwtracing/coresight/coresight-tmc.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc.h | 4 +
drivers/hwtracing/coresight/coresight-tpiu.c | 6 +-
drivers/hwtracing/coresight/coresight.c | 31 +-
include/linux/coresight.h | 12 +-
17 files changed, 473 insertions(+), 232 deletions(-)
--
2.7.4
This series adds the support for using the tmc-etr in perf mode for
storing the trace to system RAM. The ETR uses a separate buffer (double
buffering) for storing the trace. This is copied back to the ring buffer
when the event is stopped. We try to match the ETR buffer to the larger
of perf ring buffer or the size configured for the ETR via sysfs. This
allows tuning the buffer size to prevent overflows and loosing trace
data, as we don't have overflow interrupt support (yet).
Applies on coresight/next
Changes since [0] :
- Drop buffer rotation logic for etr-buf
- Do not use perf ring buffer. (Add support later)
- Fix handling of sink, preventing mixed modes of operation.
[0] - TMC ETR perf support
- http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
Suzuki K Poulose (6):
coresight: Fix handling of sinks
coresight: tmc-etr: Handle driver mode specific ETR buffers
coresight: tmc-etr: Relax collection of trace from sysfs mode
coresight: Convert driver messages to dev_dbg
coresight: perf: Remove reset_buffer call back for sinks
coresight: etm-perf: Add support for ETR backend
.../coresight/coresight-dynamic-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-etb10.c | 62 +---
drivers/hwtracing/coresight/coresight-etm-perf.c | 9 +-
drivers/hwtracing/coresight/coresight-etm3x.c | 4 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 4 +-
drivers/hwtracing/coresight/coresight-funnel.c | 4 +-
drivers/hwtracing/coresight/coresight-replicator.c | 4 +-
drivers/hwtracing/coresight/coresight-stm.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 66 +---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 337 +++++++++++++++++++--
drivers/hwtracing/coresight/coresight-tmc.c | 4 +-
drivers/hwtracing/coresight/coresight-tmc.h | 4 +
drivers/hwtracing/coresight/coresight-tpiu.c | 4 +-
drivers/hwtracing/coresight/coresight.c | 22 +-
include/linux/coresight.h | 5 +-
15 files changed, 375 insertions(+), 162 deletions(-)
--
2.7.4