Adding information on kernel versioning at the top of the file and replacing all instances of numerical kernel versions with a generic notation.
Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org --- HOWTO.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/HOWTO.md b/HOWTO.md index 2a6be3db0164..71b228c8f5f7 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -7,16 +7,18 @@ 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 latest coresight/perf integration branch on +on the [OpenCSD github repository][1]. That branch is labelled +`perf-opencsd-($VERSION)`, where ($VERSION) carries the latest kernel version +number.
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-($VERSION)` 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 +279,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-($VERSION)` 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-($VERSION) https://github.com/Linaro/OpenCSD.git perf-opencsd-($VERSION) ... ...
- linaro@t430:~/linaro/coresight$ ls perf-opencsd-4.9/ + linaro@t430:~/linaro/coresight$ ls perf-opencsd-($VERSION)/ 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 +297,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-($VERSION) 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-($VERSION)$ ls -l tools/perf/perf -rwxrwxr-x 1 linaro linaro 6276360 Mar 3 10:05 tools/perf/perf
@@ -339,7 +341,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-($VERSION)/tools/perf/perf report --stdio
# To display the perf.data header info, please use --header/--header-only options. # @@ -383,7 +385,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-($VERSION)/coresight/tools/perf/perf report --stdio --dump
resulting a large amount of data, trace looking like:-
@@ -432,10 +434,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-($VERSION)/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-($VERSION)/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 +469,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-($VERSION)/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-($VERSION)/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-($VERSION)/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-($VERSION)/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 \
On Wed, 29 Mar 2017 11:43:56 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
Adding information on kernel versioning at the top of the file and replacing all instances of numerical kernel versions with a generic notation.
Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org
HOWTO.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/HOWTO.md b/HOWTO.md index 2a6be3db0164..71b228c8f5f7 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -7,16 +7,18 @@ 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 latest coresight/perf integration branch on +on the [OpenCSD github repository][1]. That branch is labelled +`perf-opencsd-($VERSION)`, where ($VERSION) carries the latest kernel version +number.
Wouldn't it be easier to just have a fixed-name 'perf-opencsd' branch contain always the 'latest' development code, even if it gets rebased? This is how the upstream acme 'perf/core' branch works. It should be obvious to users that older versions can always be referred to by their 'perf-opencsd-x.y' style names, just by those branches being present (assuming you want to keep them present for some reason?).
Kim
On 31 March 2017 at 04:24, Kim Phillips kim.phillips@arm.com wrote:
On Wed, 29 Mar 2017 11:43:56 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
Adding information on kernel versioning at the top of the file and replacing all instances of numerical kernel versions with a generic notation.
Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org
HOWTO.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/HOWTO.md b/HOWTO.md index 2a6be3db0164..71b228c8f5f7 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -7,16 +7,18 @@ 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 latest coresight/perf integration branch on +on the [OpenCSD github repository][1]. That branch is labelled +`perf-opencsd-($VERSION)`, where ($VERSION) carries the latest kernel version +number.
Wouldn't it be easier to just have a fixed-name 'perf-opencsd' branch contain always the 'latest' development code, even if it gets rebased? This is how the upstream acme 'perf/core' branch works. It should be obvious to users that older versions can always be referred to by their 'perf-opencsd-x.y' style names, just by those branches being present
That's a very good idea - I will start doing that for the 4.12 cycle that will start sometime around the beginning of May.
(assuming you want to keep them present for some reason?).
I keep the older branches around so that we can go back if something is not working properly. On the flip side it is probably time to start deleting the older ones.
Mathieu
Kim