Hi Mike,
Here is the second patchset that adds barrier packets to traces collected
from ETB and ETR devices. It applies cleanly on top of perf-opencsd-master
(4.12-rc1). Let me know how those work out for you.
Thanks,
Mathieu
Mathieu Poirier (6):
coresight: Correct buffer lost increment
coresight: etf: Add barrier packet for synchronisation
coresight: etb10: Remove useless conversion to LE
coresight: etb10: Add barrier packet for synchronisation
coresight: etr: Correct buffer lost increment
coresight: etr: Add barrier packet for synchronisation
drivers/hwtracing/coresight/coresight-etb10.c | 36 ++++++++++++++-----------
drivers/hwtracing/coresight/coresight-priv.h | 2 ++
drivers/hwtracing/coresight/coresight-tmc-etf.c | 15 +++++++++--
drivers/hwtracing/coresight/coresight-tmc-etr.c | 15 +++++++++--
drivers/hwtracing/coresight/coresight.c | 8 ++++++
5 files changed, 57 insertions(+), 19 deletions(-)
--
2.7.4
Hi,
we started looking at how to enable collection of branch traces with
coresight etm on the hikey boards that are the reference platform for
the android linux-4.9 work. Does somebody from Linaro have access
to the description of where the coresight components are located for
the hikey devices? We would appreciate help on enabling linux-perf
collection of traces on the hikey.
Thanks,
Sebastian
[re-adding cc list, assuming didn't hit reply-all?]
On Tue, 14 Mar 2017 19:12:08 +0000
Mike Leach <mike.leach(a)linaro.org> wrote:
> On 14 March 2017 at 16:10, Kim Phillips <kim.phillips(a)arm.com> wrote:
>
> > still results in:
> >
> > util/cs-etm.c:1466:27: error: ‘cs_etm_global_header_fmts’ defined but not
> > used [-Werror=unused-const-variable=]
> > static const char * const cs_etm_global_header_fmts[] = {
> > ^~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > What toolchain and/or version are you using?
> >
> I'm using a linaro build of gcc 4.9.
>
> aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.05) 4.9.3 20150413 (prerelease)
Linaro appear to have removed that release from their repo:
http://releases.linaro.org/components/toolchain/binaries/
So I used this one - which AFAICT is the closest to your version - to
cross-build both the kernel with your config, and perf:
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
Building perf didn't require the patch I sent due to an old gcc bug
that apparently finally got fixed recently:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
I then ran the resulting kernel (which still had the extra patch, so
commit 0d15341 == c50837 + the patch), and perf:
root@juno:~# ./perf --version
perf version 4.11.rc1.gc50837
root@juno:~# strings -a perf | grep "GCC: ("
GCC: (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease)
root@juno:~# dmesg | grep gcc
[ 0.000000] Linux version 4.11.0-rc1-g0d15341 (kim@dupont) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) ) #3 SMP PREEMPT Tue Mar 14 22:41:34 CDT 2017
root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
[ 870.355660] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 870.362736] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 870.369127] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 870.374304] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 870.380698] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
[ 870.387858] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 870.394325] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 870.400806] coresight-tmc 20010000.etf: TMC disabled
[ 870.405722] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 870.412184] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 870.419350] coresight-tmc 20070000.etr: TMC-ETR disabled
[ 870.425083] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 870.432153] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 870.438542] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 870.443718] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 870.450112] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
Linux
[ 870.476156] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 870.482625] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 870.489106] coresight-tmc 20010000.etf: TMC disabled
[ 870.494023] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 870.500485] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 870.507651] coresight-tmc 20070000.etr: TMC-ETR disabled
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.015 MB perf.data ]
which appears to have worked the first time.
Then I tried a second time - literally up-arrow, enter - and got the
same exact hard hang as I get with the modern compilers the first time:
root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
[ 1965.355162] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled
[ 1965.362238] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled
[ 1965.368629] coresight-tmc 20010000.etf: TMC-ETF enabled
[ 1965.373807] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled
[ 1965.380201] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled
Linux
[ 1965.405984] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled
[ 1965.412453] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled
[ 1965.418934] coresight-tmc 20010000.etf: TMC disabled
[ 1965.423850] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled
[ 1965.430312] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled
[ 1965.437478] coresight-tmc 20070000.etr: TMC-ETR disabled
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote
which is along the same instability lines as the other time that
execution behaviour differed depending on whether it executed first or
not...
> > > > $ sudo taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u
> > --per-thread
> > > taskset -c 2 uname
> > > > failed to mmap with 12 (Cannot allocate memory)
> > >
> > > That said I get this too if I do enable sinks. However as you say after
> > the
> > > initial attempt the problem disappears.
> >
> > Right, at least we have one problem reproduced on both sides now.
...here.
> > It hung before completing that last sentence.
> >
> > Perhaps the bug is exasperated by toolchain and/or host and target
> > rootfs distribution differences? My juno target runs debian, and I
> > recently upgraded to stretch in order to get a version of gcc that
> > would support autoFDO.
>
> My juno is has a debian-jessie-developer root-fs from
> http://releases.linaro.org/debian/images/developer-arm64/16.04/
> At present I cannot build autofdo - I still have some package issues, but
> for perf and the kernel I am x-compiling on my ubuntu VM anyway, so the
> installed compilers have no effect on the perf runs,.
OK, can you try a more modern toolchain please? The one you're using
isn't available anymore, AutoFDO requires gcc 5 and higher, and you're
not seeing the build failures others see, but most importantly, it
should make it easier to reproduce the hard lockup: at least that's
the case on the Juno r2.
Thanks,
Kim
Hi,
We are running Coresight testcases in RTL simulation, and intend to decode the trace stored in ETF and Memory(through ETR).
Came across OpenCSD library,
Can this library be used in decoding of trace in RTL simulation? Note that in RTL simulations we don't use Linux and heavy software, we use bare minimum startup code for booting.
If decoding is possible, please let us know procedure and pricing if any.
Regards,
Abhijit
Hi Karim,
The CSAL library contains a number of readme files that should guide you in setting up your system for use with the library, plus a number of example applications. Start with the main README.md file in the root project directory.
Run doxygen on the doxygen-config.txt file to build the library documentation - this will include all the readme files mentioned below.
CSAL uses memory mapped IO to access the CoreSight components in linux, see readme_demos.md for further information. This file also contains instructions for setting up the library for specific platforms and running under linux.
The first task is to create a registration function for your platform - look at the cs_demo_known_boards.c file. From there you should be able build the example programs. Csls is useful to use first as it will simply list the CoreSight components - which will verify if you have configured your system and the library correctly.
Regards
Mike
> -----Original Message-----
> From: Karim Lamouchi [mailto:lamouchi_karim@yahoo.fr]
> Sent: 07 May 2017 11:27
> To: Mike Leach
> Subject: Fr : CSAL library
>
>
> Hello Mike,
>
> I'm trying to test CSAL library(coresight access library) under linux in
> order to access and configure the arm coresight IP block within a new platform
> based on 2 core A7 and 1 cortex M4.
> In fact I want to extract the generated traces (without using an external
> hardware) in order to decode them in the next step using the opencsd library .
>
> Could you please give me more details about how to use the CSAL
> library and the differents steps that allow me to support it with the new
> platform ?
>
> Is it possible to use this library without DS5?
>
> It is helpful to send me if you have any documents about this library.
>
> best regards,
> Karim.
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 Karim,
I haven't worked with the CSAL for very long time and it is not
something I can help you with. Mike may know someone who can...
Thanks,
Mathieu
On 6 May 2017 at 10:33, Karim Lamouchi <lamouchi_karim(a)yahoo.fr> wrote:
> Hello Mathieu,
>
> I'm trying to test CSAL library(coresight access library) under linux in
> order to access and configure the arm coresight IP block within a new
> platform based on 2 core A7 and 1 cortex M4.
> Could you please give me more details about how to use this library and the
> differents steps that allow me to support it with the new platform ?
> It is helpful to send me if you have any documents about this library.
>
> best regards,
> Karim.
Replacing all instances of numerical kernel versions with a
generic 'master' notation.
Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
Changes since v1:
* Following Kim Phillips' advice, moved the latest development to
a 'master' branch, allowing to reference that branch in the
documentation for all future kernel version.
---
HOWTO.md | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/HOWTO.md b/HOWTO.md
index 2a6be3db0164..596efabd797f 100644
--- a/HOWTO.md
+++ b/HOWTO.md
@@ -7,16 +7,16 @@ This HOWTO explains how to use the perf cmd line tools and the openCSD
library to collect and extract program flow traces generated by the
CoreSight IP blocks on a Linux system. The examples have been generated using
an aarch64 Juno-r0 platform. All information is considered accurate and tested
-using library version v0.5 and the latest perf branch `perf-opencsd-4.9`
-on the [OpenCSD github repository][1].
+using library version v0.5 and the `perf-opencsd-master` branch on the
+[OpenCSD github repository][1].
On Target Trace Acquisition - Perf Record
-----------------------------------------
All the enhancement to the Perf tools that support the new `cs_etm` pmu have
not been upstreamed yet. To get the required functionality branch
-`perf-opencsd-4.9` needs to be downloaded to the target system where
-traces are to be collected. This branch is an upstream v4.9 kernel
+`perf-opencsd-master` needs to be downloaded to the target system where
+traces are to be collected. This branch is a vanilla upstream kernel
supplemented with modifications to the CoreSight framework and drivers to be
usable by the Perf core. The remaining out of tree patches are being
upstreamed incrementally.
@@ -277,14 +277,14 @@ the host's (which has nothing to do with the target) architecture:
Off Target Perf Tools Compilation
---------------------------------
As stated above not all the pieces of the solution have been upstreamed. To
-get all the components branch `perf-opencsd-4.9` needs to be
+get all the components the latest `perf-opencsd-master` needs to be
obtained:
- linaro@t430:~/linaro/coresight$ git clone -b perf-opencsd-4.9 https://github.com/Linaro/OpenCSD.git perf-opencsd-4.9
+ linaro@t430:~/linaro/coresight$ git clone -b perf-opencsd-master https://github.com/Linaro/OpenCSD.git perf-opencsd-master
...
...
- linaro@t430:~/linaro/coresight$ ls perf-opencsd-4.9/
+ linaro@t430:~/linaro/coresight$ ls perf-opencsd-master/
arch certs CREDITS Documentation firmware include ipc Kconfig lib Makefile net REPORTING-BUGS scripts sound usr
block COPYING crypto drivers fs init Kbuild kernel MAINTAINERS mm README samples security tools virt
@@ -295,12 +295,12 @@ successful, but handling of CoreSight trace data won't be supported.
**See perf-test-scripts below for assistance in creating a build and test enviroment.**
- linaro@t430:~/linaro/coresight$ cd perf-opencsd-4.9
+ linaro@t430:~/linaro/coresight$ cd perf-opencsd-master
linaro@t430:~/linaro/coresight/perf-opencsd-4.9$ export CSTRACE_PATH=~/linaro/coresight/my-opencsd/decoder
linaro@t430:~/linaro/coresight/perf-opencsd-4.9$ make -C tools/perf
...
...
- linaro@t430:~/linaro/coresight/perf-opencsd-4.9$ ls -l tools/perf/perf
+ linaro@t430:~/linaro/coresight/perf-opencsd-master ls -l tools/perf/perf
-rwxrwxr-x 1 linaro linaro 6276360 Mar 3 10:05 tools/perf/perf
@@ -339,7 +339,7 @@ to be sure everything is clean.
linaro@t430:~/linaro/coresight/sept20$ rm -rf ~/.debug
linaro@t430:~/linaro/coresight/sept20$ cp -dpR .debug ~/
linaro@t430:~/linaro/coresight/sept20$ export LD_LIBRARY_PATH=~/linaro/coresight/my-opencsd/decoder/lib/linux64/dbg/
- linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.9/tools/perf/perf report --stdio
+ linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-master/tools/perf/perf report --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
@@ -383,7 +383,7 @@ to be sure everything is clean.
Additional data can be obtained, which contains a dump of the trace packets received using the command
- mjl@ubuntu-vbox:./perf-opencsd-4.9/coresight/tools/perf/perf report --stdio --dump
+ mjl@ubuntu-vbox:./perf-opencsd-master/coresight/tools/perf/perf report --stdio --dump
resulting a large amount of data, trace looking like:-
@@ -432,10 +432,10 @@ Trace Decoding with Perf Script
Working with perf scripts needs more command line options but yields
interesting results.
- linaro@t430:~/linaro/coresight/sept20$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-4.9/tools/perf/
+ linaro@t430:~/linaro/coresight/sept20$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-master/tools/perf/
linaro@t430:~/linaro/coresight/sept20$ export SCRIPT_PATH=$EXEC_PATH/scripts/python/
linaro@t430:~/linaro/coresight/sept20$ export XTOOL_PATH=/your/aarch64/toolchain/path/bin/
- linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.9/tools/perf/perf --exec-path=${EXEC_PATH} script --script=python:${SCRIPT_PATH}/cs-trace-disasm.py -- -d ${XTOOL_PATH}/aarch64-linux-gnu-objdump
+ linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-master/tools/perf/perf --exec-path=${EXEC_PATH} script --script=python:${SCRIPT_PATH}/cs-trace-disasm.py -- -d ${XTOOL_PATH}/aarch64-linux-gnu-objdump
7f89f24d80: 910003e0 mov x0, sp
7f89f24d84: 94000d53 bl 7f89f282d0 <free@plt+0x3790>
@@ -467,18 +467,18 @@ Kernel Trace Decoding
When dealing with kernel space traces the vmlinux file has to be communicated
explicitely to perf using the "--vmlinux" command line option:
- linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.9/tools/perf/perf report --stdio --vmlinux=./vmlinux
+ linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-master/tools/perf/perf report --stdio --vmlinux=./vmlinux
...
...
- linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.9/tools/perf/perf script --vmlinux=./vmlinux
+ linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-master/tools/perf/perf script --vmlinux=./vmlinux
When using scripts things get a little more convoluted. Using the same example
an above but for traces but for kernel traces, the command line becomes:
- linaro@t430:~/linaro/coresight/sept20$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-4.9/tools/perf/
+ linaro@t430:~/linaro/coresight/sept20$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-master/tools/perf/
linaro@t430:~/linaro/coresight/sept20$ export SCRIPT_PATH=$EXEC_PATH/scripts/python/
linaro@t430:~/linaro/coresight/sept20$ export XTOOL_PATH=/your/aarch64/toolchain/path/bin/
- linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.9/tools/perf/perf --exec-path=${EXEC_PATH} script \
+ linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-master/tools/perf/perf --exec-path=${EXEC_PATH} script \
--vmlinux=./vmlinux \
--script=python:${SCRIPT_PATH}/cs-trace-disasm.py -- \
-d ${XTOOLS_PATH}/aarch64-linux-gnu-objdump \
--
2.7.4
Hello,
I am trying to use Coresight drivers on Juno r0 board with 4.9 Linux
sources (Linaro release 17.01 with 'latest-armlt').
I have tried the configuration with ETM as the source and ETF as the
sink and it is working as expected.
But with ETR as the sink, when stopping the tracing, kernel panic occurs.
The bug can be reproduced with the following steps:
/ # echo 1 > /sys/bus/coresight/devices/20070000.etr/enable_sink
/ # echo 1 > /sys/bus/coresight/devices/22040000.etm/enable_source
/ # echo 0 > /sys/bus/coresight/devices/22040000.etm/enable_source
Sometime the system also hangs without printing panic message.
I am attaching the log file and .config file along with this mail. From
the logs, it looks like an arm SCP firmware problem.
Let me know if I am missing some steps/configuration or If this is a
know hardware/firmware problem with hopefully some workarounds existing.
Thanks and regards,
Don Kuzhiyelil
Good day to all,
A patch sent by Suzuki a few weeks ago [1] unearthed a problem with
how we deal with the "enable_sink" flag in the CS core. So far we
have been concentrating on system-wide trace scenarios [2] but per-CPU
[3] scenarios are also valid. In system-wide mode a single event is
generated by the perf user space and communicated to the kernel. In
per-CPU mode an event is generated for each CPU present in the system
or specified on the cmd line, and that is where our handling of the
"enable_sink" flag fails (get back to me if you want more details on
that).
My solution is to add the sink definition to the perf_event_attr
structure [4] that gets sent down to the kernel from user space. That
way there is no confusion about what sink belongs to what event. To
do that I will need to have a chat with the guys in the #perf IRC
channel, something I expect to be fairly tedious.
But before moving ahead we need to agree on the syntax we want to have
in the future. That way what I do now with the perf folks doesn't
have to be undone in a few months.
For the following I will be using figure 2-9 on page 2-33 in this document [5].
So far we have been using this syntax:
# perf record -e cs_etm/(a)20070000.etr/ --per-thread $COMMAND
This will instruct perf to select the ETR as a sink. Up to now not
specifying a sink is treated as an error condition since perf doesn't
know what sink to select.
The main goal of writing all this is that I am suggesting to revisit that.
What I am proposing is that _if_ a sink is omitted on the perf command
line, the perf infrastructure will pick the _first_ sink it finds when
doing a walk through of the CS topology. This is very advantageous
when thinking about the syntax required to support upcoming systems
where we have a one-to-one mapping between source and sink.
In such a system specifying sinks for each CPU on the perf command
line simply doesn't scale. Even on a small system I don't see users
specifying a sink for each CPU. Since the sink for each CPU will be
the first one found during the walk through, it is implicit that this
sink should be used and doesn't need to be specified explicitly.
It would also allow for the support of topologies like Juno-R1 [5]
where we have a couple of ETF in the middle. Those are perfectly
valid sinks but right now the current scheme doesn't allow us to use
them. If we pick the first sink we find along the way we can
automatically support something like this.
I have reflected quite extensively on this and I think it can work.
The only time it can fail is if at some point we we get more than one
sink associated with each tracer. But how likely is this?
What we decide now will not be undone easily, if at all. Please read
my email a couple of times and give it some consideration. Comment
and ideas are welcomed.
Best regards,
Mathieu
[1]. https://patchwork.kernel.org/patch/9657141/
[2]. perf record -e cs_etm/(a)20070000.etr/u --per-thread $COMMAND
[3]. perf record -e cs_etm/(a)20070000.etr/u --C 0,2-3 $COMMAND
[4]. http://lxr.free-electrons.com/source/include/uapi/linux/perf_event.h#L283
[5]. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515d.b/DDI0515D_b_juno…
