CoreSight

coresight@lists.linaro.org

7 participants
2442 discussions

[PATCH 0/4] perf tools: miscellaneous fix related to cs-etm

by Mathieu Poirier

Hello Tor, While ramping up on the "perf report" and "perf script" features I fixed a few things and decided to play a little: 1/4: No influence on the current results but good to fix. 2/4: That changes a lot of things when multiple buffers have been collected. 3/4: No change in functionality, just cleanup. 4/4: Enhancement to make the output easier to read. These changes can be found here[1]. If this is good with you I'll push them to gitHub for the 4.7 cycle. Regards, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/h… Mathieu Poirier (4): cs-etm: avoid casting variable cs-etm: account for each trace buffer in the queue cs-etm: removing unecessary structure field cs-etm: associating output packet with CPU they executed on tools/perf/scripts/python/cs-trace-disasm.py | 2 + tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 15 +++- tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 + tools/perf/util/cs-etm.c | 103 +++++++++++++++++++----- tools/perf/util/cs-etm.h | 7 ++ 5 files changed, 106 insertions(+), 22 deletions(-) -- 2.5.0

9 years, 3 months

PE Context and context packet output in the decoder

by Mike Leach

Hi Tor, Running through the ETMv3 decode is making me think a bit more about the generic output packets. For ETMv4, we output a OCSD_GEN_TRC_ELEM_PE_CONTEXT to indicate context info for the core, then a string of OCSD_GEN_TRC_ELEM_INSTR_RANGE for the instructions executed with the context. This mirrors the way ETMv4 packet streams work. ETMv3 and to a lesser extent PTM handles context differently, meaning we have to work harder to output the a OCSD_GEN_TRC_ELEM_PE_CONTEXT prior to the OCSD_GEN_TRC_ELEM_INSTR_RANGE packets. It occurs to me that the context packet is only really relevant when processing the instruction ranges (and possibly for data tracing later on), so I was considering:- 1) Mandating that the context part of the generic packet structure is valid for the instruction range packet (it happens to be for the current decoder, but that is a consequence of how it is written rather than a deliberate rule). In future it can be mandated for data packets if required. 2) Dropping the OCSD_GEN_TRC_ELEM_PE_CONTEXT packets completely. For the decoders this mandate is not onerous as they have to maintain the current context anyway to do the decode. Dropping a packet could simplify both decoder and library client operation. How would this affect the current perf decode? After the ETMv3 dev (or possibly at the end of it), I am going to expand the docs for the generic packets to set down these rules and dependencies. Regards Mike ---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ---------------------------------------------------------------- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

9 years, 4 months

STM low-level userspace API

by Al Grant

Hi, I'd like to get your thoughts on an appropriate low-level userspace API for STM. The API I'm after would assume the ability to map a range of channels into userspace as detailed in Documentation/trace/stm.txt: "Some STM devices may allow direct mapping of the channel mmio region to userspace for zero-copy writing..." What that doesn't describe is what you do with the region once you've got it. Which suggests a userspace API that can abstract over the way channels are represented in the memory map, i.e. how bits of the address are used to influence the data packets. Given a channel number (or a relative channel number) and some data, it would generate a store to the right address, or an lvalue at the right address. So you could write something like this: STM_TRACE_DATA(p, TIMESTAMP, uint32, 123); or perhaps *STM_TRACE_CHANNEL(p, TIMESTAMP, uint32) = 123; and this would become inline code that would be a single store that would cause a D32 packet. The ARM and Intel implementations would differ in how they calculated the address and perhaps on whether some features were available. 64-bit writes would be unavailable on some ARM systems. Userspace libraries that implemented higher-level messaging formats could then sit on top of this lower-level API. I don't think I've seen this in any of the patches that have come round but is anyone working on anything like this? Al

9 years, 4 months

Tracing summit at ELC-E

by William Mills

Mathieu/All, I heard that there is a "tracing mini-summit" planned for ELC-E this year. This is a "Linux plumbers" like conference. I believe the scope is mostly about the SW trace frameworks (ftrace, LTP etc). IMHO, this group should have some representation. Likewise, since it is plumbers like we don't want to swamp them with a bunch of people. I think 1 or 2 would be ideal. [The RT Collaborative project is also planning a RT/Tracing mini-summit as an add on to the main tracing summit.] BTW: Despite what the ELC-E website says, the dates are not locked yet. Any volunteers? (Mathieu <-- poke poke) Bill ---------------- William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836

9 years, 4 months

TMC-ETF vs TMC-ETB

by Mathieu Poirier

Mike and Al, When working with the TMC IP block and given that it was designed to replace the ETB, how many people choose to set the DEVID::CONFIGTYPE field to 0x0 (ETB)? Do people mostly choose to go with an ETF nowadays? Thanks, Mathieu

9 years, 4 months

[PATCH] opencsd: removing defines when compiling perf

by Mathieu Poirier

When compiling Perf, the ARCH=arm option is not required since all the trace decoding solution is confined to tools/perf/util. Option NO_LIBPERL=1 is also not mandatory but avoiding it can break compilation on systems where some libraries are missing, hence adding a comment on the topic. Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> --- HOWTO.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/HOWTO.md b/HOWTO.md index f46982fafcb4..f828d6a068b7 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -194,7 +194,7 @@ directory. After that a new perf tool binary can be compiled: linaro@t430:~/linaro/coresight/bkk16/$ cd perf-opencsd-4.5-rc6-bkk16 linaro@t430:~/linaro/coresight/bkk16/perf-opencsd-4.5-rc6-bkk16/$ export CSTRACE_PATH=~/linaro/coresight/bkk16/opencsd-bkk16/decoder - linaro@t430:~/linaro/coresight/bkk16/perf-opencsd-4.5-rc6-bkk16/$ make -C tools/perf ARCH=arm DEBUG=1 NO_LIBPERL=1 + linaro@t430:~/linaro/coresight/bkk16/perf-opencsd-4.5-rc6-bkk16/$ make -C tools/perf ... ... linaro@t430:~/linaro/coresight/bkk16/perf-opencsd-4.5-rc6-bkk16/$ ls -l tools/perf/perf @@ -205,6 +205,10 @@ variable telling the build scripts where to find the library is needed. If the `CSTRACE_PATH` variable is not defined the compilation will still be successful, but handling of CoreSight trace data won't be supported. +When compiling Perf, some perl libraries may not be present on the host system. +Adding the "NO_LIBPERL=1" option will prevent the build script from complaining +too much. + At the end of the compilation a new perf binary is available in `tools/perf/` -- 2.1.4

9 years, 5 months

[PATCH 0/2] opencsd: HOWTO related fixes

by Mathieu Poirier

Good morning Mike, Here's a couple patches to apply (since you are the official maintainer of the openCSD project). The first patch should only be applied to "arm-dev" since it is a new development change. The second should go on all the branch we maintain since it is a bug fix. Thanks, Mathieu Mathieu Poirier (2): opencsd: removing text version of the howto opencsd: fixing typos in HOWTO.md HOWTO | 392 --------------------------------------------------------------- HOWTO.md | 10 +- 2 files changed, 5 insertions(+), 397 deletions(-) delete mode 100644 HOWTO -- 2.1.4

9 years, 5 months

Branch cleanup

by Mathieu Poirier

Good morning Tor, As I said yesterday I consolidated the commits on perf-opencsd-4.5-rc6-bkk16. The result can be found here [1]. All the code you had on bkk16 is now found in 3 commits: perf scripts: Add python scripts for CoreSight trace perf tools: decoding capailitity for CoreSight traces perf symbols: Check before overwriting build_id The end result is the same, I haven't modified anything in the code. I also took the liberty to add a "Signed-off-by:" at the end of each of your patches. The next step will be to break down "perf tools: decoding capailitity for CoreSight traces" in small chunks but before doing so I need to understand what you've implemented. I tested both the report and script commands with before and after results (using bundle from feb24) and everything adds up. Have a look and tell me what you think. If you're good with it I'll push it to github under a branch called "perf-opencsd-4.5-devel". Once it is up this is what we should both be using from here on. Thanks, Mathieu [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git (branch perf-opencsd-4.5-tor)

9 years, 5 months

PTM decoder added

by Mike Leach

Hi, PTM decode has now been pushed to the Github site. The branch opencsd-0v002 has been created - this should be a relatively stable version 0.002 of the library. This supercedes the opencsd-bkk version (0.001). Main differences in 0.002 are:- * PTM instruction decode. As discussed @ bkk:- * Include files - C++ common headers now live in ./include/common. Only C compatible _types.h files and the main C++ library include file now appear in ./include. * The 'RCTDL' prefixes that were a result of the code coming from the ARM ref trace decode project have now been replaced with more sensible and consistent ocsd. opencsd.h is now the main header to link the C++ library, opencsd_c_api.h links the C API wrapper. Feature development will continue on arm-dev branch, bugfixes only on opencsd-0v002. Regards Mike ---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ---------------------------------------------------------------- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

9 years, 5 months

ETM data trace

by Chunyan Zhang

Hi All, I remember that Mathieu and Al said that data trace is no longer supported on A profile cores except A7 (i.e. ETMv3). But I noticed that the ETMv3/v4 data trace was mentioned again in README [1] - "Support to be added". What does the "data trace" in [1] refer to. Is it only for the ETMv3/v4 on M / R profile cores? Thanks, Chunyan [1] https://github.com/Linaro/OpenCSD/blob/opencsd-bkk16/README.md

9 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight