[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
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(a)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 \
--
2.7.4
Hi,
Couple of questions here about perf/OpenCSD and dynamic code.
- what's the status of decode for arbitrarily loaded/unloaded shared objects?
I.e. decode where the code is in an ELF binary and we just need to know which
binaries are at what address and at what time. Can we match up mmap events
with the captured ETM trace to do the decode, even with modules being
unloaded and overwritten by other modules?
- what's the status of decode for JITted code? Here you'd need to capture the
actual contents of the code cache, to be able to decode it.
Are these ready to go or is there still some work to do?
Thanks,
Al
Good day,
First and foremost, for coresight related questions please CC the
coresight mailing list. There is a lot of knowledgeable people on it
that can help with your questions.
On 29 March 2017 at 04:09, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote:
> Hi Mathieu,
>
>
>
> I have find the root cause about the issue, thanks
>
>
>
> Another questions,
>
> 1> I port the coresight dts config from JUNO-busybox to JUNO-android, but
> the cpu hung during the kernel boot stage, do you have any suggestion?
The first thing to do would be to disable coresight. If the board
still hangs there is not much I can do for you. Otherwise there is
either a problem with power domains or the clocks. You will likely
have to instrument the kernel to see where things hang.
>
> 2> I try to use the sysFS attribute of Coresight to trace data, but decode
> the data failed by the OpenCSD,
The interesting question here is how did you try to use the OpenCSD
library to decode traces acquired via sysFS? OpenCSD requires a lot
of trace configuration information that is not present in raw sysFS
traces. The integration between coresight and perf is an example of
how those trace configuration information need to be communicated to
the library.
>
> Is there any introduction of Coresight sysFS usage? And Can perf decode the
> raw trace data?
No - perf can't decode raw traces gathered from sysFS for reasons
mentionned above.
Regards,
Mathieu
>
>
>
> thanks
>
>
>
>
>
> From: Kaiyou Wang
> Sent: Wednesday, March 29, 2017 10:02 AM
> To: 'mathieu.poirier(a)linaro.org'
> Subject: Some question about OpenCSD coresight drive usage
>
>
>
> Hi Mathieu,
>
>
>
> Sorry to disturb, I have some question about the coresight driver usage,
> could you give me some suggestion?
>
>
>
> I try to perf recode the trace event on JUNO busybox platform:
>
>
>
> / # ./perf record -e cs_etm/(a)20010000.etf/ --per-thread uname
>
> map_groups__set_modules_path_dir: cannot open /lib/modules/4.9.0-dirty dir
>
> Problems setting modules path maps, continuing anyway...
>
> path: /sys/bus/coresight/devices/20010000.etf/enable_sink
>
> mmap size 528384B
>
> [ 2257.038441] coresight-funnel 20040000.main-funnel: FUNNEL inport 1
> enabled
>
> [ 2257.045268] coresight-funnel 230c0000.cluster1-funnel: FUNNEL inport 3
> enabled
>
> Linux
>
> [ 2257.055129] coresight-funnel 230c0000.cluster1-funnel: FUNNEL inport 3
> disabled
>
> [ 2257.062376] coresight-funnel 20040000.main-funnel: FUNNEL inport 1
> disabled
>
> [ 2257.069277] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>
> [ perf record: Woken up 1 times to write data ]
>
> failed to write feature 8
>
> failed to write feature 9
>
> failed to write feature 14
>
> [ perf record: Captured and wrote 0.041 MB perf.data ]
>
>
>
> Then try to decode the perf.data on host-linux, but it faild, could you give
> me some suggestion?
>
>
>
>
>
> kaiwan01@sha-swtool:~/code/OpenCSD/trace-data$ cat disasm.sh
>
> #!/bin/bash
>
>
>
> export
> EXEC_PATH=/home/kaiwan01/code/OpenCSD/OpenCSD-perf/perf-opencsd-4.8/tools/perf/
>
> export SCRIPT_PATH=$EXEC_PATH/scripts/python/
>
> export
> XTOOL_PATH=/home/kaiwan01/tools/gcc-linaro-4.9-2015.05-x86_64_aarch64-linux-gnu/aarch64-linux-gnu/bin/
>
>
>
> perf --exec-path=${EXEC_PATH} script
> --script=python:${SCRIPT_PATH}/cs-trace-disasm.py -- -d
> ${XTOOL_PATH}/aarch64-linux-gnu-objdump
>
> kaiwan01@sha-swtool:~/code/OpenCSD/trace-data$ ./disasm.sh
>
> Traceback (most recent call last):
>
> File
> "/home/kaiwan01/code/OpenCSD/OpenCSD-perf/perf-opencsd-4.8/tools/perf//scripts/python//cs-trace-disasm.py",
> line 113, in process_event
>
> disasm_output = check_output(disasm).split('\n')
>
> File "/usr/lib/python2.7/subprocess.py", line 567, in check_output
>
> process = Popen(stdout=PIPE, *popenargs, **kwargs)
>
> File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
>
> errread, errwrite)
>
> File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
>
> raise child_exception
>
> OSError: [Errno 2] No such file or directory
>
> Fatal Python error: problem in Python trace event handler
>
> ./disasm.sh: line 7: 24616 Aborted (core dumped) perf
> --exec-path=${EXEC_PATH} script
> --script=python:${SCRIPT_PATH}/cs-trace-disasm.py -- -d
> ${XTOOL_PATH}/aarch64-linux-gnu-objdump
>
> kaiwan01@sha-swtool:~/code/OpenCSD/trace-data$
>
>
>
>
>
> Thanks and Best Regards,
>
> Kaiyou
>
>
>
> 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.
>From gcc 6.2 and onward, the compiler complains about
‘cs_etm_global_header_fmts’ not being used (and rightly so).
One solution is to remove the declaration but it is a matter
of time before we need to modify the header. Another solution
is to simply print the information conveyed by the header.
There is a few advantages that comes with the latter:
1) We know how many CPUs are part of the session, without having to
count the number of magic numbers.
2) We get to see if the snapshot option was specified.
3) When we change the header we know exactly what kind of header
we are dealing with.
Reported-by: Kim Phillips <kim.phillips(a)arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
tools/perf/util/cs-etm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 0adb8e4aff2f..82702039ab2e 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1494,6 +1494,9 @@ static void cs_etm__print_auxtrace_info(u64 *val, size_t num)
{
unsigned i,j,cpu;
+ for (i = 0; i < CS_HEADER_VERSION_0_MAX; i++)
+ fprintf(stdout, cs_etm_global_header_fmts[i], val[i]);
+
for (i = CS_HEADER_VERSION_0_MAX, cpu = 0; cpu < num; ++cpu) {
if (val[i] == __perf_cs_etmv3_magic) {
--
2.7.4
Hello,
On 17 March 2017 at 03:19, lipengcheng (C) <lipengcheng8(a)huawei.com> wrote:
> Hi Leo and Mathieu.
>
>
>
> Please help to verify the accuracy of the data,thank you very much
>
By accuracy you mean decode the data snapshot you included below?
Unfortunately that is not possible without using the openCSD library,
something that is currently working with the coresight/perf integration.
If you give me a base tree where the dts patch applies, I will be happy to
test the solution.
Thanks,
Mathieu
>
>
> For the detail, you can follow the next test step
>
>
>
> 1、 Merge coresight dts patch.
>
>
>
> 2、enable etr or etf。
>
> echo '1'>/sys/bus/coresight/devices/f6404000.etr/enable_sink
>
> or
>
> echo '1'>/sys/bus/coresight/devices/f6402000.etf/enable_sink
>
>
>
> 3、 enable cpu etm:
>
> example cpu0 etm4x: echo '1'>/sys/bus/coresight/
> devices/f659c000.etm/enable_source
>
> 4、cd dev
>
> dd if=./f6402000.etf of=/tmp/etf
>
>
>
> or
>
> dd if=./f6404000.etr of=/tmp/etr
>
>
> 5、etf or etr data:
>
>
>
> [image: cid:image001.png@01D29F40.B5B27320]
>
> 李鹏程
> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
>
> ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人:* lipengcheng (C)
> *发送时间:* 2017年3月17日 12:13
> *收件人:* 'Guodong Xu' <guodong.xu(a)linaro.org>; Leo Yan <leo.yan(a)linaro.org>
> *抄送:* Suzhuangluan <suzhuangluan(a)hisilicon.com>
> *主题:* 答复: 答复: 答复: [PATCH] sctrl: coresight test: opening the sctrl atb
> clock gating
>
>
>
> Hi Guodong,
>
>
>
> [image: cid:image003.png@01D29F40.B5B27320]
>
>
>
>
>
> 我这边测试单独enable etm 是报building pach 异常,感觉是通路不通。。还是要先将软件流程调通。
>
>
>
> + clk240mhz: clk240mhz {
>
> + #clock-cells = <0>;
>
> + compatible = "fixed-clock";
>
> + clock-frequency = <200000000>;
>
> + };
>
>
>
>
>
> 时钟应用上面的:
>
>
>
> + etr@0,f6404000 {
>
> + compatible = "arm,coresight-tmc", "arm,primecell";
>
> + reg = <0 0xf6404000 0 0x1000>;
>
> +
>
> + coresight-default-sink;
>
> + clocks = <&clk240mhz>;
>
> + clock-names = "apb_pclk";
>
> + port {
>
> + etr_in_port: endpoint@0 {
>
> + slave-mode;
>
> + remote-endpoint =
> <&replicator_out_port0>;
>
> + };
>
> + };
>
> +
>
> + };
>
>
>
>
>
> 李鹏程
> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
>
> ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人:* Guodong Xu [mailto:guodong.xu@linaro.org <guodong.xu(a)linaro.org>]
> *发送时间:* 2017年3月17日 11:36
> *收件人:* Leo Yan <leo.yan(a)linaro.org>
> *抄送:* lipengcheng (C) <lipengcheng8(a)huawei.com>; Suzhuangluan <
> suzhuangluan(a)hisilicon.com>
> *主题:* Re: 答复: 答复: [PATCH] sctrl: coresight test: opening the sctrl atb
> clock gating
>
>
>
> 李鹏程,
>
>
>
> 赞同Leo建议的方式. 你这边应该有hikey吧? 直接把主线代码抓下来编译调试. 这也是Mathieu的环境, 遇到问题大家基准相同好交流.
>
>
>
> -国栋
>
>
>
> 2017-03-16 21:48 GMT+08:00 Leo Yan <leo.yan(a)linaro.org>:
>
> 我和Mathieu讨论过一些,他认为ETB/ETF这一块应该是没有问题的,但是怀疑是ETM这一块没有数据出来。我对coresight
> 不是特别了解,前面在两个板子上做了些实验,DB410c和Hikey。DB410c上比较快就能够enable起来,所以我这边后来就没有花太多的时间在
> Hikey上。这是当前的状态。
>
>
>
> 主要的问题是我们主要在主线kernel上开发,而主线版本上看起来可能时钟还是有些问题。我和Mathieu都
> 认为比较有效率的方式是,海思同事是否能够直接在HIkey上验证内核主线版本,我的理解是最简便的方式是可以在主线内核启动之后,
> 依赖于内核的里面驱动去使能时钟,然后使用调试器(trace32)抓取ETB里面的内容,如果解析里面的跳转指令,
> 就代表硬件的逻辑是可以正常工作的,否则硬件逻辑没有工作。
>
>
>
> 比较复杂的调试方法就是使用Perf+OpenCSD进行调试,这个会增加调试难度的地方就是还需要了解perf+OpenCSD里面的机制。
>
>
>
>
>
>
>
> On 16 March 2017 at 20:39, lipengcheng (C) <lipengcheng8(a)huawei.com>
> wrote:
>
> 合入后,是那部分有问题,现在coresight 代码变化比较大。
>
>
>
> 我这里要看话,会花费很多时间,能不能看看是啥问题?我负责支持解决问题,是否ok?
>
>
>
> 李鹏程
> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
>
> ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人**:* Guodong Xu [mailto:guodong.xu@linaro.org]
> *发送时间**:* 2017年3月16日 17:16
> *收件人**:* lipengcheng (C) <lipengcheng8(a)huawei.com>
> *抄送**:* Leo Yan <leo.yan(a)linaro.org>; Suzhuangluan <
> suzhuangluan(a)hisilicon.com>
> *主题**:* Re: 答复: [PATCH] sctrl: coresight test: opening the sctrl atb
> clock gating
>
>
>
>
>
>
>
> On 16 March 2017 at 17:06, lipengcheng (C) <lipengcheng8(a)huawei.com>
> wrote:
>
> Hi guodong and leo,
>
>
>
> 最新调试是否还有问题?
>
>
>
> 之前mathieu反馈时钟有问题,合入这个patch 时钟是否解决了?
>
>
>
> 合入后, 仍没有解决.
>
>
>
> -国栋
>
>
>
>
>
> 李鹏程
> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
>
> ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人**:* lipengcheng (C)
> *发送时间**:* 2017年3月14日 20:11
> *收件人**:* 'Leo Yan' <leo.yan(a)linaro.org>
> *抄送**:* Suzhuangluan <suzhuangluan(a)hisilicon.com>
> *主题**:* 答复: [PATCH] sctrl: coresight test: opening the sctrl atb clock
> gating
>
>
>
> meot@linaro-developer:~# ./perf record -e cs_etm/(a)f6404000.etr/
> --per-thread una
>
> failed to mmap with 12 (Cannot allocate memory)
>
>
>
> 这个是没有申请到memory ,不是之前时钟不可用的问题。单独测试etm4x,是否有问题。
>
>
>
>
>
> 李鹏程
> ------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> [image: Company_logo]
>
>
> ------------------------------
>
> 本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
> 的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> *发件人**:* Leo Yan [mailto:leo.yan@linaro.org <leo.yan(a)linaro.org>]
> *发送时间**:* 2017年3月7日 16:18
> *收件人**:* lipengcheng (C) <lipengcheng8(a)huawei.com>
> *抄送**:* Guodong Xu <guodong.xu(a)linaro.org>; Mathieu Poirier <
> mathieu.poirier(a)linaro.org>; Liuyongfu <liuyongfu(a)hisilicon.com>; Dan
> zhao <dan.zhao(a)hisilicon.com>; Suzhuangluan <suzhuangluan(a)hisilicon.com>
> *主题**:* Re: [PATCH] sctrl: coresight test: opening the sctrl atb clock
> gating
>
>
>
> Hi Pengcheng,
>
>
>
> I tried your patch with perf command, I still can see the failure:
>
>
>
> [ 1.424133] hi6220_sysconf:before sctrl ACPU_SC_CLK_STAT is 17fd
>
>
>
> [ 1.424138] hi6220_sysconf:after sctrl ACPU_SC_CLK_STAT is 1ffd
>
>
>
> meot@linaro-developer:~# ./perf record -e cs_etm/(a)f6404000.etr/
> --per-thread una
>
> failed to mmap with 12 (Cannot allocate memory)
>
>
>
>
>
> On 6 March 2017 at 17:20, Li Pengcheng <lipengcheng8(a)huawei.com> wrote:
>
> opening the sctrl ACPU_SC_CLKEN register 11 bit atb clock gating.
>
> Signed-off-by: Li Pengcheng <lipengcheng8(a)huawei.com>
> ---
> drivers/misc/Makefile | 1 +
> drivers/misc/hi6220-sysconfig.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
> create mode 100644 drivers/misc/hi6220-sysconfig.c
>
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 3198336..8bf83fe 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_ECHO) += echo/
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE) += cxl/
> obj-$(CONFIG_PANEL) += panel.o
> +obj-y += hi6220-sysconfig.o
>
> lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
> lkdtm-$(CONFIG_LKDTM) += lkdtm_bugs.o
> diff --git a/drivers/misc/hi6220-sysconfig.c b/drivers/misc/hi6220-
> sysconfig.c
> new file mode 100644
> index 0000000..c61bfbb
> --- /dev/null
> +++ b/drivers/misc/hi6220-sysconfig.c
> @@ -0,0 +1,29 @@
> +#include <linux/io.h>
> +
> +#define SOC_HI6220_ACPU_SCTRL_BASE_ADDR 0xF6504000
> +#define ACPU_SC_CLKEN 0x00C
> +#define ACPU_SC_CLK_STAT 0x014
> +
> +static int __init hi6220_sysconf(void)
> +{
> + static void __iomem *base = NULL;
> +
> + base = ioremap(SOC_HI6220_ACPU_SCTRL_BASE_ADDR, SZ_4K);
> + if (base == NULL) {
> + pr_err("hi6220: asctl reg iomap failed!\n");
> + return -ENOMEM;
> + }
> + /* enable coresight */
> + pr_err("%s:before sctrl ACPU_SC_CLK_STAT is %x\n",
> + __func__,
> + readl(base + ACPU_SC_CLK_STAT));
> + writel(BIT(11), base + ACPU_SC_CLKEN);
> + pr_err("%s:after sctrl ACPU_SC_CLK_STAT is %x\n",
> + __func__,
> + readl(base + ACPU_SC_CLK_STAT));
> +
> + iounmap(base);
> +
> + return 0;
> + }
> + postcore_initcall(hi6220_sysconf);
> --
> 2.1.0
>
>
>
>
>
>
>
>
>
Hi Kim,
I've split off this issue from the original thread (keeping the original
audience). A bit more investigation this morning shows that on my juno-r1
the issue only occurs if you enable the TPIU. (couldn't use the r2 but I
don't think the differences are relevant here).
See below for test run info.
As far as I am aware, the TPIU driver is currently a stub driver - granted
it would be better if it failed gracefully and gave a useful error message,
but enabling is not useful without external trace capture (and we might
expect the external device to enable this - bit of a grey area starting
trace by system calls then piping out to external device).
Mike
===All 4 sinks - mmap error ============
mleach@linaro-developer:~/perf-tools$ for i in
/sys/bus/coresight/devices/*/enable_sink; do echo $i; done
/sys/bus/coresight/devices/20010000.etf/enable_sink
/sys/bus/coresight/devices/20030000.tpiu/enable_sink
/sys/bus/coresight/devices/20070000.etr/enable_sink
/sys/bus/coresight/devices/20140000.etf/enable_sink
mleach@linaro-developer:~/perf-tools$ for i in
/sys/bus/coresight/devices/*/enable_sink; do echo 1 | sudo tee $i; done
1
1
1
1
mleach@linaro-developer:~/perf-tools$ 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)
mleach@linaro-developer:~/perf-tools$ sudo taskset -c 2 ./perf record -e
cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
Linux
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.077 MB perf.data ]
=============================
====== etf @ 2001 only - no error ===========
mleach@linaro-developer:~/perf-tools$ echo 1 | sudo tee
/sys/bus/coresight/devices/20010000.etf/enable_sink
1
mleach@linaro-developer:~/perf-tools$ sudo taskset -c 2 ./perf record -e
cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
Linux
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.077 MB perf.data ]
=============================
======etr @ 2007 only - no error ============
mleach@linaro-developer:~/perf-tools$ echo 1 | sudo tee
/sys/bus/coresight/devices/20070000.etr/enable_sink
1
mleach@linaro-developer:~/perf-tools$ sudo taskset -c 2 ./perf record -e
cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.076 MB perf.data ]
=============================
======etf @ 2014 only - no error ============
mleach@linaro-developer:~/perf-tools$ echo 1 | sudo tee
/sys/bus/coresight/devices/20140000.etf/enable_sink
1
mleach@linaro-developer:~/perf-tools$ sudo taskset -c 2 ./perf record -e
cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
Linux
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.077 MB perf.data ]
=============================
=====tpiu @ 2003 only - mmap error =================
mleach@linaro-developer:~/perf-tools$ echo 1 | sudo tee
/sys/bus/coresight/device/20030000.tpiu/enable_sink
1
mleach@linaro-developer:~/perf-tools$ 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)
mleach@linaro-developer:~/perf-tools$
mleach@linaro-developer:~/perf-tools$ sudo taskset -c 2 ./perf record -e
cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname
Linux
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.076 MB perf.data ]
mleach@linaro-developer:~/perf-tools$
=============================
--
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK