Hi Linaro Coresight Team,
We are debugging Arm ETB. We don't know how to dump the ETB data with the right method. Please give me some comments, thanks so much.
* Let's me give a description for our ETB environment first.
For the Core-sight components, after enabled ETM and ETB. We can dump the ETB data after a while.
[cid:image004.jpg@01D76CF0.86E6C320]
According to ARM_CoreSight_Architecture_Specification.pdf, then We think it works by changing the trace source ID.
[cid:image005.jpg@01D76CF0.86E6C320]
The following data is from the head of trace buffer.
Before the trace source ID = 2:
00000005 = 00 | 0b10<<1+0b1 | 0x0 | 0x0
After the trace source ID = 4:
00000009 = 00 | 0b100<<1+0b1 | 0x0 | 0x0
0000000B
00000000
04000000
00800000
The registers about ETM are as follows.
TRCCONFIGR(id:0x10)=0x31F07
TRCTRACEIDR(id:0x40)=0x2
TRCIDR8(id:0x180)=0x1
TRCIDR9(id:0x184)=0x20
TRCIDR10(id:0x188)=0x2
TRCIDR11(id:0x18c)=0x0
TRCIDR12(id:0x190)=0x1
TRCIDR13(id:0x194)=0x0
TRCIDR0(id:0x1e0)=0x8020EFF
TRCIDR1(id:0x1e4)=0x4100F401 ARM ETM4.0.1
TRCIDR2(id:0x1e8)=0x420004
* How to use OpenCSD for M7?
We also try to dump with your source code "OpenCSD" https://github.com/Linaro/OpenCSD, it's a useful tool. But maybe we lost some configuration, our ETB can't be dumped.
Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x0
Idx:0; ID:0; I_NOT_SYNC : I Stream not synchronised
Idx:285; ID:0; I_INCOMPLETE_EOT : Incomplete packet at end of trace.[I_NOT_SYNC]
ID:0 END OF TRACE DATA
Trace Packet Lister : Trace buffer done, processed 288 bytes.
The attachments are the settings and trace buffer.
So my question is:
* Should we use ETM4D instead of ETMV4I?
#define OCSD_BUILTIN_DCD_ETMV4D "ETMV4D" /**< ETMv4 data decoder */
* Does OpenCSD support ETMV4D and Cortex-M7?
We can see the TODO from git repo.
Support to be added: ETMv4 data trace - packet processing and decode.
const char *decoderName = bDataChannel ? OCSD_BUILTIN_DCD_ETMV4D : OCSD_BUILTIN_DCD_ETMV4I;
I didn't see the M7 support.
69 { "Cortex-M0", { ARCH_V7, profile_CortexM } },
70 { "Cortex-M0+", { ARCH_V7, profile_CortexM } },
71 { "Cortex-M3", { ARCH_V7, profile_CortexM } },
72 { "Cortex-M4", { ARCH_V7, profile_CortexM } }
* A stupid question, could you kindly tell me which ARM document introduce the data encoder?
I debug test code step by step(see below lines), but it doesn't match with ETB trace buffer. I am not sure if there has more document about PEencoder/decoder.
debug_count += 1;
4B11 ldr r3,0x604
681B ldr r3,[r3]
3301 adds r3,#0x1
4A0F ldr r2,0x604
6013 str r3,[r2]
[cid:image011.jpg@01D76CF0.86E6C320]
[PC-bas<f and trace analyzer p roaessng Element System bus System PE interface JTAG port Trae:e unit Control and trace flWing FIFO generatOn Cores i g ht core"ht Figure 1-2 Example SOC with a trace unit and a dedicated trace buffer]
Looking forward to your feedback.
Thank you so much.
BR//Jinnan
This patchset introduces initial concepts in CoreSight system
configuration management support. to allow more detailed and complex
programming to be applied to CoreSight systems during trace capture.
Configurations consist of 2 elements:-
1) Features - programming combinations for devices, applied to a class of
device on the system (all ETMv4), or individual devices.
2) Configurations - a set of programmed features used when the named
configuration is selected.
Features and configurations are declared as a data table, a set of register,
resource and parameter requirements. Features and configurations are loaded
into the system by the virtual cs_syscfg device. This then matches features
to any registered devices and loads the feature into them.
Individual device classes that support feature and configuration register
with cs_syscfg.
Once loaded a configuration can be enabled for a specific trace run.
Configurations are registered with the perf cs_etm event as entries in
cs_etm/events. These can be selected on the perf command line as follows:-
perf record -e cs_etm/<config_name>/ ...
This patch set has one pre-loaded configuration and feature.
A named "strobing" feature is provided for ETMv4.
A named "autofdo" configuration is provided. This configuration enables
strobing on any ETM in used.
Thus the command:
perf record -e cs_etm/autofdo/ ...
will trace the supplied application while enabling the "autofdo" configuation
on each ETM as it is enabled by perf. This in turn will enable strobing for
the ETM - with default parameters. Parameters can be adjusted using configfs.
The sink used in the trace run will be automatically selected.
A configuration can supply up to 15 of preset parameter values, which will
subsitute in parameter values for any feature used in the configuration.
Selection of preset values as follows
perf record -e cs_etm/autofdo,preset=1/ ...
(valid presets 1-N, where N is the number supplied in the configuration, not
exceeding 15. preset=0 is the same as not selecting a preset.)
Applies to & tested against coresight/next-ETE-TRBE (5.12-rc3 base)
Changes since v6:
Fixed kernel test robot issues-
Reported-by: kernel test robot <lkp(a)intel.com>
Changes since v5:
1) Fix code style issues from auto-build reports, as
Reported-by: kernel test robot <lkp(a)intel.com>
2) Update comments to get consistent docs for API functions.
3) remove unused #define from autofdo example.
4) fix perf code style issues from patch 4 (Mathieu)
5) fix configfs code style issues from patch 9. (Mathieu)
Changes since v4: (based on comments from Matthieu and Suzuki).
No large functional changes - primarily code improvements and naming schema.
1) Updated entire set to ensure a consistent naming scheme was used for
variables and struct members that refer to the key objects in the system.
Suffixes _desc used for all references to feature and configuraion descriptors,
suffix _csdev used for all references to load feature and configs in the csdev
instances. (Mathieu & Suzuki).
2) Dropped the 'configurations' sub dir in cs_etm perf directories as superfluous
with the configfs containing the same information. (Mathieu).
3) Simplified perf handling code (suzuki)
4) Multiple simplifications and improvements for code readability (Matthieu
and Suzuki)
Changes since v3: (Primarily based on comments from Matthieu)
1) Locking mechanisms simplified.
2) Removed the possibility to enable features independently from
configurations.Only configurations can be enabled now. Simplifies programming
logic.
3) Configuration now uses an activate->enable mechanism. This means that perf
will activate a selected configuration at the start of a session (during
setup_aux), and disable at the end of a session (around free_aux)
The active configuration and associated features will be programmed into the
CoreSight device instances when they are enabled. This locks the configuration
into the system while in use. Parameters cannot be altered while this is
in place. This mechanism will be extended in future for dynamic load / unload
of configurations to prevent removal while in use.
4) Removed the custom bus / driver as un-necessary. A single device is
registered to own perf fs elements and configfs.
5) Various other minor issues addressed.
Changes since v2:
1) Added documentation file.
2) Altered cs_syscfg driver to no longer be coresight_device based, and moved
to its own custom bus to remove it from the main coresight bus. (Mathieu)
3) Added configfs support to inspect and control loaded configurations and
features. Allows listing of preset values (Yabin Cui)
4) Dropped sysfs support for adjusting feature parameters on the per device
basis, in favour of a single point adjustment in configfs that is pushed to all
device instances.
5) Altered how the config and preset command line options are handled in perf
and the drivers. (Mathieu and Suzuki).
6) Fixes for various issues and technical points (Mathieu, Yabin)
Changes since v1:
1) Moved preloaded configurations and features out of individual drivers.
2) Added cs_syscfg driver to manage configurations and features. Individual
drivers register with cs_syscfg indicating support for config, and provide
matching information that the system uses to load features into the drivers.
This allows individual drivers to be updated on an as needed basis - and
removes the need to consider devices that cannot benefit from configuration -
static replicators, funnels, tpiu.
3) Added perf selection of configuarations.
4) Rebased onto the coresight module loading set.
To follow in future revisions / sets:-
a) load of additional config and features by loadable module.
b) load of additional config and features by configfs
c) enhanced resource management for ETMv4 and checking features have sufficient
resources to be enabled.
d) ECT and CTI support for configuration and features.
Mike Leach (10):
coresight: syscfg: Initial coresight system configuration
coresight: syscfg: Add registration and feature loading for cs devices
coresight: config: Add configuration and feature generic functions
coresight: etm-perf: update to handle configuration selection
coresight: syscfg: Add API to activate and enable configurations
coresight: etm-perf: Update to activate selected configuration
coresight: etm4x: Add complex configuration handlers to etmv4
coresight: config: Add preloaded configurations
coresight: syscfg: Add initial configfs support
Documentation: coresight: Add documentation for CoreSight config
.../trace/coresight/coresight-config.rst | 244 ++++++
Documentation/trace/coresight/coresight.rst | 16 +
drivers/hwtracing/coresight/Makefile | 7 +-
.../hwtracing/coresight/coresight-cfg-afdo.c | 153 ++++
.../coresight/coresight-cfg-preload.c | 31 +
.../coresight/coresight-cfg-preload.h | 13 +
.../hwtracing/coresight/coresight-config.c | 275 ++++++
.../hwtracing/coresight/coresight-config.h | 253 ++++++
drivers/hwtracing/coresight/coresight-core.c | 12 +-
.../hwtracing/coresight/coresight-etm-perf.c | 150 +++-
.../hwtracing/coresight/coresight-etm-perf.h | 12 +-
.../hwtracing/coresight/coresight-etm4x-cfg.c | 182 ++++
.../hwtracing/coresight/coresight-etm4x-cfg.h | 30 +
.../coresight/coresight-etm4x-core.c | 38 +-
.../coresight/coresight-etm4x-sysfs.c | 3 +
.../coresight/coresight-syscfg-configfs.c | 396 +++++++++
.../coresight/coresight-syscfg-configfs.h | 45 +
.../hwtracing/coresight/coresight-syscfg.c | 804 ++++++++++++++++++
.../hwtracing/coresight/coresight-syscfg.h | 81 ++
include/linux/coresight.h | 7 +
20 files changed, 2716 insertions(+), 36 deletions(-)
create mode 100644 Documentation/trace/coresight/coresight-config.rst
create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c
create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c
create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h
create mode 100644 drivers/hwtracing/coresight/coresight-config.c
create mode 100644 drivers/hwtracing/coresight/coresight-config.h
create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c
create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h
create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c
create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h
create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c
create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h
--
2.17.1
This patch series is to correct the pointer usages for the snapshot
mode.
Patch 01 allows the AUX trace in the free run mode and only syncs the
AUX ring buffer when taking snapshot.
Patch 02 is to polish code, it removes the redundant header maintained
in tmc-etr driver and directly uses pointer perf_output_handle::head.
Patch 03 removes the callback cs_etm_find_snapshot() which wrongly
calculates the buffer headers; we can simply use the perf's common
function __auxtrace_mmap__read() for headers calculation.
This patch can be cleanly applied on the mainline kernel with:
commit 97e5bf604b7a ("Merge branch 'for-5.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/dennis/percpu")
And it has been tested on Arm64 Juno board.
Leo Yan (3):
coresight: etm-perf: Correct buffer syncing for snapshot
coresight: tmc-etr: Use perf_output_handle::head for AUX ring buffer
perf cs-etm: Remove callback cs_etm_find_snapshot()
.../hwtracing/coresight/coresight-etm-perf.c | 30 +++-
.../hwtracing/coresight/coresight-etm-perf.h | 2 +
.../hwtracing/coresight/coresight-tmc-etr.c | 10 +-
tools/perf/arch/arm/util/cs-etm.c | 133 ------------------
4 files changed, 32 insertions(+), 143 deletions(-)
--
2.25.1
Hello everyone,
I'm interested in performing data value tracing using CoreSight. Do
you know a board offering this feature?
So far I know that data value tracing is supported by CoreSight in
Cortex-A5 and Cortex-A7, although there might be other cores too
(probably 32 bits). In case you have not dealt with data value tracing
before, do you know a board with accessible CoreSight components
featuring either Cortex-A5 or Cortex-A7?
Any help will be greatly appreciated.
Regards,
Farzam
Hi Jon,
This series contain the remaining 8 patches I submitted at v3 that
weren't merged yet at -next.
This series is rebased on the top of your docs-next branch.
No changes here, except by some Reviewed/ack lines, and at the
name of the final patch (per PCI maintainer's request).
Mauro Carvalho Chehab (8):
docs: admin-guide: reporting-issues.rst: replace some characters
docs: trace: coresight: coresight-etm4x-reference.rst: replace some
characters
docs: driver-api: ioctl.rst: replace some characters
docs: usb: replace some characters
docs: vm: zswap.rst: replace some characters
docs: filesystems: ext4: blockgroup.rst: replace some characters
docs: networking: device_drivers: replace some characters
docs: PCI: Replace non-breaking spaces to avoid PDF issues
Documentation/PCI/acpi-info.rst | 18 +++++++++---------
Documentation/admin-guide/reporting-issues.rst | 2 +-
Documentation/driver-api/ioctl.rst | 8 ++++----
Documentation/filesystems/ext4/blockgroup.rst | 2 +-
.../device_drivers/ethernet/intel/i40e.rst | 6 +++---
.../device_drivers/ethernet/intel/iavf.rst | 2 +-
.../coresight/coresight-etm4x-reference.rst | 2 +-
Documentation/usb/ehci.rst | 2 +-
Documentation/usb/gadget_printer.rst | 2 +-
Documentation/vm/zswap.rst | 4 ++--
10 files changed, 24 insertions(+), 24 deletions(-)
--
2.31.1
(Maintainers bcc, to avoid too many recipient troubles)
As discussed at:
https://lore.kernel.org/linux-doc/871r9k6rmy.fsf@meer.lwn.net/
It is better to avoid using :doc:`foo` to refer to Documentation/foo.rst, as the
automarkup.py extension should handle it automatically, on most cases.
There are a couple of exceptions to this rule:
1. when :doc: tag is used to point to a kernel-doc DOC: markup;
2. when it is used with a named tag, e. g. :doc:`some name <foo>`;
On this series:
Patch 1 manually adjust the references inside driver-api/pm/devices.rst,
as there it uses :file:`foo` to refer to some Documentation/ files;
Patch 2 converts a table at Documentation/dev-tools/kunit/api/index.rst
into a list, carefully avoiding the
The remaining patches convert the other occurrences via a replace script.
They were manually edited, in order to honour 80-columns where possible.
This series based on docs-next branch. In order to avoid merge conflicts,
I rebased it internally against yesterday's linux-next, dropping a patch
and a hunk that would have caused conflicts there.
I'll re-send the remaining patch (plus another patch) with conflicting
changes, together with any other doc:`filename` reference that might
still be upstream by 5.14-rc1.
---
v2:
- dropped media patches (as I merged via my own tree);
- removed one patch that would conflict at linux-next (adm1177.rst);
- removed one hunk fron kunit patch that would also conflict at
linux-next.
Mauro Carvalho Chehab (29):
docs: devices.rst: better reference documentation docs
docs: dev-tools: kunit: don't use a table for docs name
docs: admin-guide: pm: avoid using ReST :doc:`foo` markup
docs: admin-guide: hw-vuln: avoid using ReST :doc:`foo` markup
docs: admin-guide: sysctl: avoid using ReST :doc:`foo` markup
docs: block: biodoc.rst: avoid using ReST :doc:`foo` markup
docs: bpf: bpf_lsm.rst: avoid using ReST :doc:`foo` markup
docs: core-api: avoid using ReST :doc:`foo` markup
docs: dev-tools: testing-overview.rst: avoid using ReST :doc:`foo`
markup
docs: dev-tools: kunit: avoid using ReST :doc:`foo` markup
docs: devicetree: bindings: submitting-patches.rst: avoid using ReST
:doc:`foo` markup
docs: doc-guide: avoid using ReST :doc:`foo` markup
docs: driver-api: avoid using ReST :doc:`foo` markup
docs: driver-api: gpio: using-gpio.rst: avoid using ReST :doc:`foo`
markup
docs: driver-api: surface_aggregator: avoid using ReST :doc:`foo`
markup
docs: driver-api: usb: avoid using ReST :doc:`foo` markup
docs: firmware-guide: acpi: avoid using ReST :doc:`foo` markup
docs: i2c: avoid using ReST :doc:`foo` markup
docs: kernel-hacking: hacking.rst: avoid using ReST :doc:`foo` markup
docs: networking: devlink: avoid using ReST :doc:`foo` markup
docs: PCI: endpoint: pci-endpoint-cfs.rst: avoid using ReST :doc:`foo`
markup
docs: PCI: pci.rst: avoid using ReST :doc:`foo` markup
docs: process: submitting-patches.rst: avoid using ReST :doc:`foo`
markup
docs: security: landlock.rst: avoid using ReST :doc:`foo` markup
docs: trace: coresight: coresight.rst: avoid using ReST :doc:`foo`
markup
docs: trace: ftrace.rst: avoid using ReST :doc:`foo` markup
docs: userspace-api: landlock.rst: avoid using ReST :doc:`foo` markup
docs: virt: kvm: s390-pv-boot.rst: avoid using ReST :doc:`foo` markup
docs: x86: avoid using ReST :doc:`foo` markup
.../PCI/endpoint/pci-endpoint-cfs.rst | 2 +-
Documentation/PCI/pci.rst | 6 +--
.../special-register-buffer-data-sampling.rst | 3 +-
Documentation/admin-guide/pm/intel_idle.rst | 16 +++++---
Documentation/admin-guide/pm/intel_pstate.rst | 9 +++--
Documentation/admin-guide/sysctl/abi.rst | 2 +-
Documentation/admin-guide/sysctl/kernel.rst | 37 ++++++++++---------
Documentation/block/biodoc.rst | 2 +-
Documentation/bpf/bpf_lsm.rst | 13 ++++---
.../core-api/bus-virt-phys-mapping.rst | 2 +-
Documentation/core-api/dma-api.rst | 5 ++-
Documentation/core-api/dma-isa-lpc.rst | 2 +-
Documentation/core-api/index.rst | 4 +-
Documentation/dev-tools/kunit/api/index.rst | 8 ++--
Documentation/dev-tools/kunit/faq.rst | 2 +-
Documentation/dev-tools/kunit/index.rst | 14 +++----
Documentation/dev-tools/kunit/start.rst | 4 +-
Documentation/dev-tools/kunit/tips.rst | 5 ++-
Documentation/dev-tools/kunit/usage.rst | 8 ++--
Documentation/dev-tools/testing-overview.rst | 16 ++++----
.../bindings/submitting-patches.rst | 11 +++---
Documentation/doc-guide/contributing.rst | 8 ++--
Documentation/driver-api/gpio/using-gpio.rst | 4 +-
Documentation/driver-api/ioctl.rst | 2 +-
Documentation/driver-api/pm/devices.rst | 8 ++--
.../surface_aggregator/clients/index.rst | 3 +-
.../surface_aggregator/internal.rst | 15 ++++----
.../surface_aggregator/overview.rst | 6 ++-
Documentation/driver-api/usb/dma.rst | 6 +--
.../acpi/dsd/data-node-references.rst | 3 +-
.../firmware-guide/acpi/dsd/graph.rst | 2 +-
.../firmware-guide/acpi/enumeration.rst | 7 ++--
Documentation/i2c/instantiating-devices.rst | 2 +-
Documentation/i2c/old-module-parameters.rst | 3 +-
Documentation/i2c/smbus-protocol.rst | 4 +-
Documentation/kernel-hacking/hacking.rst | 4 +-
.../networking/devlink/devlink-region.rst | 2 +-
.../networking/devlink/devlink-trap.rst | 4 +-
Documentation/process/submitting-patches.rst | 32 ++++++++--------
Documentation/security/landlock.rst | 3 +-
Documentation/trace/coresight/coresight.rst | 8 ++--
Documentation/trace/ftrace.rst | 2 +-
Documentation/userspace-api/landlock.rst | 11 +++---
Documentation/virt/kvm/s390-pv-boot.rst | 2 +-
Documentation/x86/boot.rst | 4 +-
Documentation/x86/mtrr.rst | 2 +-
46 files changed, 171 insertions(+), 147 deletions(-)
--
2.31.1
Hi,
We are a group of researchers from NYU trying to bring up Coresight ETM
interfaces on ThunderX2.
So we dug out this old thread (
https://lists.linaro.org/pipermail/coresight/2018-August/001626.html) and
trying to get things spinning. We are current on Linux 5.12.9 kernel, but
it seems some of the DTS entries are missing from the upstream.
Just to be sure, would it be possible that you could share the DTS scripts?
Thank you!
Zhenghao