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
Hey Mike,
Looking at the branch available on github [1], any issues renaming
your "arm-dev" branch to "opencsd-bkk16" ? That way there is no
ambiguity as to what it is and we can created other branches like
"opencsd-[devel, next, stable]" as we move forward.
Tell me what you think,
Mathieu
[1]. https://github.com/Linaro/OpenCSD
Hi,
STM has 16 channels per 4KB page, (or 256 channels per 64KB page for the biggest page granule in ARMv8). And the STM supports up to 65k channels, so up to 4096 separate pages (AArch32 with 4KB pages) or 256 separate pages (AArch64 with 64KB pages), using 16MB of address space. This allows the STM channel space to be partitioned up between independent software agents. However implementers often want to allocate a smaller amount of physical space to STM.
Mapping just one page of STM is all right when there is just one agent (e.g. low-level firmware) but if there are multiple software agents it creates a problem. Is there now enough documentation on how the Linux STM driver will map pages of STM channel space, for us to use this in setting expectations on how much should be physically mapped in?
In particular, will the driver support mapping parts of STM channel space into userspace processes, allowing userspace to generate STM messages by storing directly into channel space without going via the kernel?
Al
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.
Mike and Tor,
I've added my slides in the presentation and fixed a few things around
it. Please review/modify as you see fit. You may want to take a look
at slide 27 and add what you have in mind for the coming weeks.
Another slide can be added if we're running out of room.
Serge and Chunyan, I intend to use you guys as a barometer. Please
have a thorough review of the presentation - if you still have
questions on the project after reading the presentation, we need to
somehow/somewhere add that information in there.
Thanks,
Mathieu
