CoreSight

coresight@lists.linaro.org

5 participants
2698 discussions

[PATCH v2 00/16] coresight: Add support for CPU-wide trace scenarios

by Mathieu Poirier

This is the second revision of a patchset that adds support for CPU-wide trace scenarios and as such, it is now possible to issue the following commands: # perf record -e cs_etm/(a)20070000.etr/ -C 2,3 $COMMAND # perf record -e cs_etm/(a)20070000.etr/ -a $COMMAND The solution is designed to work for both 1:1 and N:1 source/sink topologies, though the former hasn't been tested for lack of access to HW. Most of the changes revolve around allowing more than one event to use a sink when operated from perf. More specifically the first event to use a sink switches it on while the last one is tasked to aggregate traces and switching off the device. This is the kernel part of the solution, with the user space portion to be released in a later set. All patches (user and kernel) have been rebased on v5.1-rc2 and are hosted here[1]. Everything has been tested on Juno and 410c dragonboard platforms. Regards, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git (5.1-rc2-cpu-wide-v2) == Changes for V2 == * Using define ETM4_CFG_BIT_CTXTID rather than hard coded value (Suzuki). * Moved pid out of struct etr_buf and into struct etr_perf_buffer (Suzuki). * Removed code related to forcing double buffering (Suzuki). * Fixed function reallocarray() for older distributions (Mike). * Fixed counter configuration when dealing with errors(Leo). * Automatically selecting PID_IN_CONTEXTIDR with ETMv4 driver. * Rebased to v5.1-rc2. Mathieu Poirier (16): coresight: pmu: Adding ITRACE property to cs_etm PMU coresight: etm4x: Add kernel configuration for CONTEXTID coresight: etm4x: Configure tracers to emit timestamps coresight: Adding return code to sink::disable() operation coresight: Move reference counting inside sink drivers coresight: Properly address errors in sink::disable() functions coresight: Properly address concurrency in sink::update() functions coresight: perf: Clean up function etm_setup_aux() coresight: perf: Refactor function free_event_data() coresight: Communicate perf event to sink buffer allocation function coresight: tmc-etr: Refactor function tmc_etr_setup_perf_buf() coresight: tmc-etr: Introduce the notion of process ID to ETR devices coresight: tmc-etr: Allow events to use the same ETR buffer coresight: tmc-etr: Add support for CPU-wide trace scenarios coresight: tmc-etf: Add support for CPU-wide trace scenarios coresight: etb10: Add support for CPU-wide trace scenarios drivers/hwtracing/coresight/Kconfig | 1 + drivers/hwtracing/coresight/coresight-etb10.c | 83 +++++-- .../hwtracing/coresight/coresight-etm-perf.c | 37 +++- drivers/hwtracing/coresight/coresight-etm4x.c | 120 ++++++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 82 +++++-- .../hwtracing/coresight/coresight-tmc-etr.c | 204 +++++++++++++++--- drivers/hwtracing/coresight/coresight-tmc.c | 2 + drivers/hwtracing/coresight/coresight-tmc.h | 6 + drivers/hwtracing/coresight/coresight-tpiu.c | 9 +- drivers/hwtracing/coresight/coresight.c | 28 +-- include/linux/coresight-pmu.h | 2 + include/linux/coresight.h | 7 +- tools/include/linux/coresight-pmu.h | 2 + 13 files changed, 482 insertions(+), 101 deletions(-) -- 2.17.1

7 years

Changing build-id cache a.k.a ~/.debug directory

by Wojciech Żmuda

Hello, The OpenCSD manual HOWTO.md mentions the ~/.debug directory with the following comment: Perf is expecting files related to the trace capture (perf.data) to be located under ~/.debug [3]. (...) [3]: Get in touch with us if you know a way to change this. Source: https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md I've just discovered how to control this, so I'm sharing. I'm not sure about your pull request policy on OpenCSD contribution, so I decided to use mailing list for that. This setting can be adjusted with the `perf config` command as follows: root@zynq:~# ls -l my_buildid ls: cannot access 'my_buildid': No such file or directory root@zynq:~# perf config --system buildid.dir=/root/my_buildid root@zynq:~# perf record -e cs_etm/(a)fe950000.etf2/u --per-thread ./testprogram Couldn't synthesize bpf events. ^C[ perf record: Woken up 4 times to write data ] Warning: AUX data lost 3 times out of 3! [ perf record: Captured and wrote 0.029 MB perf.data ] root@zynq:~# ls -l my_buildid total 16 drwxr-xr-x 3 root root 4096 Apr 18 16:06 '[kernel.kallsyms]' drwxr-xr-x 3 root root 4096 Apr 18 16:06 '[vdso]' drwxr-xr-x 3 root root 4096 Apr 18 16:06 lib drwxr-xr-x 3 root root 4096 Apr 18 16:06 root More examples on perf-config: http://man7.org/linux/man-pages/man1/perf-config.1.html Best regards, Wojciech

7 years

[RFC 00/17] perf tools: Add support for coresight CPU wide trace scenarios

by Mathieu Poirier

This patchset complements the kernel portion of the solution by adding the capability to decode and render traces based on the time they were executed. Most of the changes are related to decoding traces with multiple traceIDs, something that is mandatory when dealing with N:1 source/sink topologies. Both kernel and user space patches have been rebased on yesterday's linux-next and are available here[1]. Note that compiling the perf tools on both target and host platforms in the 5.1 cycle requires the addition of "CORESIGHT=1", i.e: $ make -C tools/perf CORESIGHT=1 VF=1 Moreover this set uses a new decoder callback that was introduced in version 0.11.0 of the openCSD library. Testing with a different version of the library than the one installed on a system can be done by using the CSINCLUDES and CSLIBS environment variables, as described in the library's documentation[2]. As with the kernel portion, I'm only sending to the coresight mailing list because of the merge window. Review and comments would be most appreciated. Thanks, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git/log/?h=next-201… [2]. https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md Mathieu Poirier (17): perf tools: Configure contextID tracing in CPU-wide mode perf tools: Configure timestsamp generation in CPU-wide mode perf tools: Configure SWITCH_EVENTS in CPU-wide mode perf tools: Add handling of itrace start events perf tools: Add handling of switch-CPU-wide events perf tools: Refactor error path in cs_etm_decoder__new() perf tools: Move packet queue out of decoder structure perf tools: Introduce the concept of trace ID queues perf tools: Get rid of unused cpu in struct cs_etm_queue perf tools: Move thread to traceid_queue perf tools: Move tid/pid to traceid_queue perf tools: Mandate using openCSD v0.11.0 perf tools: Use traceID aware memory callback API perf tools: Add support for multiple traceID queues perf tools: Linking PE contextID with perf thread mechanic perf tools: Add notion of time to decoding code perf tools: Add support for CPU-wide trace scenarios tools/build/feature/test-libopencsd.c | 4 +- tools/perf/arch/arm/util/cs-etm.c | 186 +++- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 270 +++-- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 39 +- tools/perf/util/cs-etm.c | 939 ++++++++++++++---- tools/perf/util/cs-etm.h | 104 ++ 6 files changed, 1208 insertions(+), 334 deletions(-) -- 2.17.1

7 years

Re: Replicator and funnel binding names

by Leo Yan

On Thu, Apr 04, 2019 at 09:47:53AM +0100, Suzuki K Poulose wrote: > Hi > > On 04/04/2019 05:47, Mathieu Poirier wrote: > > Good day to all, > > > > Suzuki and Leo have recently posted patches to unify the way funnel > > and replicators are supported. Those patches prompted me to have a > > closer look at the bindings we currently use. At this time we have: > > > > Non configurable replicator: "coresight-replicator" > > Configurable replicator: "coresight-dynamic-replicator" > > > > Non Configurable funnel: "coresight-static-funnel" (public but not merged yet) > > Configurable funnel: "coresight-funnel" > > > > This is quite confusing to me and I suggest the following: > > > > Non configurable replicator: "coresight-static-replicator" > > Configurable replicator: "coresight-dynamic-replicator" > > > > Non Configurable funnel: "coresight-static-funnel" > > Configurable funnel: "coresight-dynamic-funnel" > > > > Current bindings would be kept around for backward compatibility but > > marked as obsolete in the coresight DT bindings document. Leo has > > stepped forward to do the work and Rob Herring (DT maintainer) is on > > board with the idea. All we need is to settle on a naming convention, > > hence this email. > > I thought about it when I posted the original suggestion. But didn't want > to disturb the existing compatibles. But given that changing the > "coresight-funnel" doesn't really matter, as long as "primecell" appears > in the list of compatibles. And it is good to have it unified across all > components. So I am happy with the proposal. Cool! Thanks for confirmation, Suzuki. This looks good to me as well, will send patch set soon. Thanks, Leo Yan

7 years

[PATCH v3 00/20] coresight: Add support for CPU-wide trace scenarios

by Mathieu Poirier

This is the third revision of a patchset that adds support for CPU-wide trace scenarios and as such, it is now possible to issue the following commands: # perf record -e cs_etm/(a)20070000.etr/ -C 2,3 $COMMAND # perf record -e cs_etm/(a)20070000.etr/ -a $COMMAND The solution is designed to work for both 1:1 and N:1 source/sink topologies, though the former hasn't been tested for lack of access to HW. Most of the changes revolve around allowing more than one event to use a sink when operated from perf. More specifically the first event to use a sink switches it on while the last one is tasked to aggregate traces and switching off the device. This is the kernel part of the solution, with the user space portion to be released in a later set. All patches (user and kernel) have been rebased on v5.1-rc3 and are hosted here[1]. Everything has been tested on Juno, the 410c dragonboard, and hikey620 platforms. Regards, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git (5.1-rc3-cpu-wide-v3) == Changes for v3 == * Added review-by tags (some were dropped due to patch refactoring). * Split IDR and reference counting patches. * Moved IDR to struct tmc_drvdata to support 1:1 source/sink topologies. * Enhanced code comments related to design choices. * Renamed ETR buffer allocation functions to have a stronger perf semantic. * Rebased to v5.1-rc3. == Changes for V2 == * Using define ETM4_CFG_BIT_CTXTID rather than hard coded value (Suzuki). * Moved pid out of struct etr_buf and into struct etr_perf_buffer (Suzuki). * Removed code related to forcing double buffering (Suzuki). * Fixed function reallocarray() for older distributions (Mike). * Fixed counter configuration when dealing with errors(Leo). * Automatically selecting PID_IN_CONTEXTIDR with ETMv4 driver. * Rebased to v5.1-rc2. Mathieu Poirier (20): coresight: pmu: Adding ITRACE property to cs_etm PMU coresight: etm4x: Add kernel configuration for CONTEXTID coresight: etm4x: Skip selector pair 0 coresight: etm4x: Configure tracers to emit timestamps coresight: Adding return code to sink::disable() operation coresight: Move reference counting inside sink drivers coresight: Properly address errors in sink::disable() functions coresight: Properly address concurrency in sink::update() functions coresight: perf: Clean up function etm_setup_aux() coresight: perf: Refactor function free_event_data() coresight: Communicate perf event to sink buffer allocation functions coresight: tmc-etr: Refactor function tmc_etr_setup_perf_buf() coresight: tmc-etr: Create per-thread buffer allocation function coresight: tmc-etr: Introduce the notion of process ID to ETR devices coresight: tmc-etr: Introduce the notion of reference counting to ETR devices coresight: tmc-etr: Introduce the notion of IDR to ETR devices coresight: tmc-etr: Allocate and free ETR memory buffers for CPU-wide scenarios coresight: tmc-etr: Add support for CPU-wide trace scenarios coresight: tmc-etf: Add support for CPU-wide trace scenarios coresight: etb10: Add support for CPU-wide trace scenarios drivers/hwtracing/coresight/Kconfig | 1 + drivers/hwtracing/coresight/coresight-etb10.c | 83 ++++-- .../hwtracing/coresight/coresight-etm-perf.c | 37 ++- drivers/hwtracing/coresight/coresight-etm4x.c | 113 +++++++- .../hwtracing/coresight/coresight-tmc-etf.c | 82 ++++-- .../hwtracing/coresight/coresight-tmc-etr.c | 261 ++++++++++++++++-- drivers/hwtracing/coresight/coresight-tmc.c | 6 + drivers/hwtracing/coresight/coresight-tmc.h | 12 + drivers/hwtracing/coresight/coresight-tpiu.c | 9 +- drivers/hwtracing/coresight/coresight.c | 28 +- include/linux/coresight-pmu.h | 2 + include/linux/coresight.h | 7 +- tools/include/linux/coresight-pmu.h | 2 + 13 files changed, 546 insertions(+), 97 deletions(-) -- 2.17.1

7 years

Replicator and funnel binding names

by Mathieu Poirier

Good day to all, Suzuki and Leo have recently posted patches to unify the way funnel and replicators are supported. Those patches prompted me to have a closer look at the bindings we currently use. At this time we have: Non configurable replicator: "coresight-replicator" Configurable replicator: "coresight-dynamic-replicator" Non Configurable funnel: "coresight-static-funnel" (public but not merged yet) Configurable funnel: "coresight-funnel" This is quite confusing to me and I suggest the following: Non configurable replicator: "coresight-static-replicator" Configurable replicator: "coresight-dynamic-replicator" Non Configurable funnel: "coresight-static-funnel" Configurable funnel: "coresight-dynamic-funnel" Current bindings would be kept around for backward compatibility but marked as obsolete in the coresight DT bindings document. Leo has stepped forward to do the work and Rob Herring (DT maintainer) is on board with the idea. All we need is to settle on a naming convention, hence this email. Regards, Mathieu

7 years

Re: Help with Jetson TX2 Coresight

by Wojciech Żmuda

Hi Srdjan, > Hello, > > I have a Jetson TX2 board which has dual-core NVIDIA Denver2 + quad-core ARM Cortex-A57. > > nVidia recently released a new SDK package (which they call JetPack, based on Ubuntu and 4.9 Kernel). out of the box it comes with coresight disabled, so I had to recompile the kernel in order to enable it. Coresight kind of works, I'm getting some data out of it, but I'm trying to use Perf in order to do the tracing. > > The issue I'm facing is that when I execute: > > perf record -e cs_etm/(a)8030000.etf/u --per-thread uname > > it works properly, and I'm getting great reports, but if I omit the --per-thread parameter I'm getting the: > failed to mmap with 12 (Cannot allocate memory) Mainline Linux does not yet contain CPU-wide tracing. If you use mainline or older, you can trace only single-thread applications in per-thread mode. Skipping --per-thread flag is equivalent to specifying --all-cpus flag and this mode is not yet supported in mainline. Mathieu and friends are working on CPU-wide tracing and their v2 patch set has just appeared on this list. You can try to cherry-pick their patches on your branch. Then, you will be able to use --cpu <n> and --all-cpus. I did that (with v1) and I can confirm it works well. > > mmap error also happens if I want to record already running process with --pid parameter. I tried that yesterday and it worked for me. Please mind I'm using Linux 5.1-rc1 (cloned about a week ago) with CPU-wide tracing patch set by Linaro. CoreSight development goes rapidly, so it's a good idea to keep up with this list and Linux mainline changelog, because interesting changes may appear any day. > > If I specify the number of the cpu: > perf record -e cs_etm/(a)8030000.etf/u --cpu 0 uname > > then recording works but when I try to do perf report it says: > 0x228 [0x40]: failed to process type: 7 > > What might be interesting to mention is that the processors on this system are arranged in weird combination. cpu 0,3,4,5 are ARM cores which have coresight on them, and cpu 1,2 are Denver cores without coresight. I'm suspecting that this might create some issues. I'm not an expert, but I don't think it would matter. If Denver cores don't have CoreSight, that probably means they don't have ETMs connected, thus they will not generate any trace data. I don't know if Linux can schedule processes on them. If not, I see no harm - your program will be traced no matter what CPU kernel puts it on. If it can, the worst case would be empty trace. You can save yourself from the latter by scheduling your process with taskset to the main cores only, omitting Denvers. But again, it's just my educated guess and I'd wait for the second opinion of the wise people residing here. Regards, Wojciech > > Do you have any ideas on how to proceed to diagnose the issue? > > Thank you.

7 years

[PATCH 00/25] coresight: Support for ACPI bindings

by Suzuki K Poulose

This series adds the support for CoreSight devices on ACPI based platforms. The device connections are encoded as _DSD graph property[0], with CoreSight specific extensions to indicate the direction of data flow as described in [1]. Components attached to CPUs are listed as child devices of the corresponding CPU, removing explicit links to the CPU like we do in the DT. As a prepartion for the ACPI support, we merge the driver for dynamic and non-programmable replicators. We introduce platform independent helpers to parse the platform supplied information. Thus we rename the platform handling code from: of_coresight.c => coresight-platform.c The CoreSight driver creates shadow devices that appear on the Coresight bus, in addition to the real devices (e.g, AMBA bus devices). The name of these devices match the real device. This makes the device name a bit cryptic for ACPI platform. So this series also introduces a generic platform agnostic device naming scheme for the shadow Coresight devices. Towards this we also make changes to the way we lookup devices to resolve the connections, as we can't use the names to identify the devices. So, we use the "fwnode_handle" of the real device for the device lookups. Towards that we clean up the drivers to keep track of the "CoreSight" device rather than the "real" device. However, all real operations, like DMA allocation, Power management etc. must be performed on the real device which is the parent of the shadow device. Finally we add the support for parsing the ACPI platform data. The power management support is missing in the ACPI (and this is not specific to CoreSight). The firmware must ensure that the respective power domains are turned on. Applies on v5.1-rc1 Tested on a Juno-r0 board with ACPI bindings patch (Patch 26/25) added on top of [2]. You would need to make sure that the debug power domain is turned on before the Linux kernel boots. (e.g, connect the DS-5 to the Juno board while at UEFI). arm32 code is only compile tested. [0] ACPI Device Graphs using _DSD (Not available online yet, approved but awaiting publish and eventually should be linked at). https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-to… [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platf… [2] https://github.com/tianocore/edk2-platforms.git Suzuki K Poulose (25): coresight: tmc: Report DMA setup failures coresight: dynamic-replicator: Clean up error handling coresight: replicator: Prepare for merging with dynamic-replicator coresight: dynamic-replicator: Prepare for merging with static replicator coresight: Merge the static and dynamic replicator drivers coresight: funnel: Clean up device book keeping coresight: replicator: Cleanup device tracking coresight: tmc: Clean up device specific data coresight: catu: Cleanup device specific data coresight: tpiu: Clean up device specific data coresight: stm: Cleanup device specific data coresight: etm: Clean up device specific data coresight: etb10: Clean up device specific data coresight: Rename of_coresight to coresight-platform coresight: etm3x: Rearrange cp14 access detection coresight: stm: Rearrange probing the stimulus area coresight: tmc-etr: Rearrange probing default buffer size coresight: Introduce generic platform data helper coresight: Make device to CPU mapping generic coresight: platform: Use fwnode handle for device search coresight: Use fwnode handle instead of device names coresight: Use platform agnostic names coresight: stm: ACPI support for parsing stimulus base coresight: Support for ACPI bindings coresight: acpi: Support for components drivers/acpi/acpi_amba.c | 9 + drivers/hwtracing/coresight/Kconfig | 8 - drivers/hwtracing/coresight/Makefile | 4 +- drivers/hwtracing/coresight/coresight-catu.c | 38 +- drivers/hwtracing/coresight/coresight-catu.h | 1 - drivers/hwtracing/coresight/coresight-cpu-debug.c | 3 +- .../coresight/coresight-dynamic-replicator.c | 255 -------- drivers/hwtracing/coresight/coresight-etb10.c | 23 +- drivers/hwtracing/coresight/coresight-etm3x.c | 23 +- drivers/hwtracing/coresight/coresight-etm4x.c | 19 +- drivers/hwtracing/coresight/coresight-funnel.c | 27 +- drivers/hwtracing/coresight/coresight-platform.c | 723 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-priv.h | 2 + drivers/hwtracing/coresight/coresight-replicator.c | 255 ++++++-- drivers/hwtracing/coresight/coresight-stm.c | 119 +++- drivers/hwtracing/coresight/coresight-tmc-etr.c | 26 +- drivers/hwtracing/coresight/coresight-tmc.c | 71 +- drivers/hwtracing/coresight/coresight-tpiu.c | 29 +- drivers/hwtracing/coresight/coresight.c | 77 ++- drivers/hwtracing/coresight/of_coresight.c | 297 --------- include/linux/coresight.h | 43 +- 21 files changed, 1287 insertions(+), 765 deletions(-) delete mode 100644 drivers/hwtracing/coresight/coresight-dynamic-replicator.c create mode 100644 drivers/hwtracing/coresight/coresight-platform.c delete mode 100644 drivers/hwtracing/coresight/of_coresight.c ACPI bindings for Juno-r0 (applies on [2] above) Suzuki K Poulose (1): edk2-platform: juno: Update ACPI CoreSight Bindings Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl | 241 +++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> -- 2.7.4

7 years

[PATCH v3 0/2] CoreSight: Support static funnel

by Leo Yan

Since before there have no platforms use static funnel in mainline kernel (though maybe some in-house SoC has used it but didn't upstream for mainline kernel yet so we don't be aware for it), when enable CoreSight DT binding for hikey960, we found the SoC uses the static funnel in the link path and but it's not supported in CoreSight funnel driver. So the first patch is to update DT documentation to support static funnel (we call it as non-configurable funnel in documentation); the second patch is to support the static funnel in the CoreSight funnel driver. Credits to Suzuki shared code for CoreSight replicator refactoring, the static funnel related implementation heavily follows up the same fashion in Suzuki's replicator code. This patch set has been rebased on CoreSight next branch [1] with latest commit d5d246a56af0 ("coresight: Merge the static and dynamic replicator drivers") and tested on Hikey960 with perf commands: # perf record -e cs_etm/(a)20010000.etf/ --per-thread ./main # perf report --tui P.s. in this version, Hikey960 CoreSight DT binding has not been included and will be sent out separately. [1] https://git.linaro.org/kernel/coresight.git/log/?h=next Leo Yan (2): dt-bindings: arm: coresight: Support static funnel coresight: funnel: Support static funnel .../devicetree/bindings/arm/coresight.txt | 45 ++++++- .../hwtracing/coresight/coresight-funnel.c | 112 +++++++++++++----- 2 files changed, 127 insertions(+), 30 deletions(-) -- 2.17.1

7 years

Empty trace in TMC-ETR on Xilinx Zynq US+ MPSoC

by Wojciech Żmuda

Hello CoreSight team, I'm trying to bring up TMC-ETR on Xilinx Zynq Ultrascale+ and I ran into some troubles. I hope you may have some ideas on where to look next. Detailed CoreSight topology of Zynq US+ MPSoC may be found in ug1085-zynq-ultrascale-trm.pdf (easy to google), but to make this discussion easier, I'll try to sketch it below: [2x C-R5] [4x C-A53] | | [2x ETMs] [4x ETM] | | [Funnel0] [Funnel1] [STM] | | | | [TMC-ETF 4kB] | | | | [--------------------ATB----------------] | [Funnel2] | [TMC-ETF 8 KB] | [Replicator] | | [TMC-ETR] [TPIU] I can happily use perf to trace Cortex-A53 cores and get trace data from the upmost ETF (the 4kB one). However, I feel like I often get buffer overflows (thanks Mathieu for this hypothesis) overwriting my trace with new data during the session. To overcome this I'd like to use either the second ETF or, preferably, ETR with significantly larger buffer. The problem is, I'm not able to get any trace from ETR. Observations: 1. It is possible to choose ETR as sink in perf - there is no error and the session starts. 2. There are no CoreSight related errors in dmesg. 3. By examining TMC-ETR memory mapped registers (busybox devmem 0x...) I can see that indeed perf sees the device and configures it properly. I've added some prints around struct etr_buf manipulations in TMC drivers and I can actually see that buffer address and size saved into this structure are programmed into TMC, as the same values appear in its registers. I can also see that the enable bit is set high when tracing starts and low when perf returns. 4. There is never any useful data in AUXTRACE sections of perf.data. When tracing with --per-thread I observe that the size of the section grows significantly the longer I trace: ' ... CoreSight ETM Trace data: size xxx bytes' with xxx exceeding kBytes. However, all I get is: 0xd60 [0x8]: event: 68 . . ... raw event: size 8 bytes . 0000: 44 00 00 00 00 00 08 00 D....... 0xd60 [0x8]: PERF_RECORD_FINISHED_ROUND With --all-cpus, I always get ' ... CoreSight ETM Trace data: size 16 bytes' no matter how long the tracing session is. Interestingly, the data part does not change - it's always the same 8 bytes each time I try using ETR as sink, regardless --per-thread or --all-cpus mode. 5. Each time I print etr_buf contents in tmc_etr_sync_flat_buf() or tmc_etr_sync_sg_buf(), I can see that the buffer, no matter how big, gets only 16 bytes of data on each sync. I wonder if this issue may point to SMMU issues. I can see in juno-base.dtsi in Linux mainline that the ETR node (and only this one from the CS family) has iommus=< > property pointing to smmu_etr: etr@20070000 { compatible = "arm,coresight-tmc", "arm,primecell"; reg = <0 0x20070000 0 0x1000>; iommus = <&smmu_etr 0>; ... I tried to mimic this behaviour on my platform by adding similar reference to the only SMMU node defined in xilinx/zynqmp.dtsi. In my case it's iommus = <&smmu 0xc5>; since there is no dedicated SMMU for ETR (and I don't see it in TRM) and 0xc5 is stream ID calculated from the CoreSight master ID (TRM Chapter 16, Table 16-11). I can see in dmesg that SMMU is enabled and ETR is added to iommu group 0, but this does not change the behaviour. I'd appreciate any suggestions if this direction seem worth further debugging. Another interesting observation is that I'm actually unable to access anything below the 4k ETF in the topology I sketched. I can't use ETF2 nor STM via sysfs. I wonder if there is some ATB configuration that may be worth checking as well? I would appreciate any suggestions where to look next. Thanks and best regards, Wojciech

7 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight