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.
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
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
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
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
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
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)
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.
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
Hi,
What's the plan for backporting the CoreSight framework? This work item:
https://projects.linaro.org/browse/BB-62
implies there's a work item for backporting the framework to LSK, but it doesn't
actually link to said work item. It would be useful if we could tell customers which
kernel versions they can get CoreSight framework patches for.
Thanks,
Al
