CoreSight

coresight@lists.linaro.org

6 participants
2339 discussions

Re: [PATCH] coresight: etm_perf: Fix using uninitialised work

by Mike Leach

Tested against the 4.11-rc1 OpenCSD perf tree - reproduced the problem and confirmed the patch fixes it on Juno r1. Noted that the command line ./perf record -e cs_etm/(a)20010000.etf/ uname also causes the same problem, Larger question that may need future investigation in the openCSD project is why the sink provided in the perf command line is not being enabled? Regards Mike On 31 March 2017 at 19:18, Suzuki K Poulose <suzuki.poulose(a)arm.com> wrote: > With 4.11-rc4, the following command triggers a WARN_ON, > when a sink is not enabled. > > perf record -e cs_etm/(a)20010000.etf/ > > [88286.547741] ------------[ cut here ]------------ > [88286.552332] WARNING: CPU: 3 PID: 2156 at kernel/workqueue.c:1442 __queue_work+0x29c/0x3b8 > [88286.560427] Modules linked in: > [88286.563451] > [88286.564928] CPU: 3 PID: 2156 Comm: perf_v4.11 Not tainted 4.11.0-rc4 #217 > [88286.573453] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Aug 15 > 2016 > [88286.584128] task: ffff80097597c200 task.stack: ffff8009768b0000 > [88286.589990] PC is at __queue_work+0x29c/0x3b8 > [88286.594303] LR is at __queue_work+0x104/0x3b8 > [88286.598614] pc : [<ffff0000080d8c7c>] lr : [<ffff0000080d8ae4>] pstate: a00001c5 > [88286.605934] sp : ffff8009768b3aa0 > [88286.609212] x29: ffff8009768b3aa0 x28: ffff80097ff3da00 > [88286.614477] x27: ffff80097ff89c00 x26: ffff8009751b0e00 > [88286.619741] x25: ffff000008c9f000 x24: 0000000000000003 > [88286.625004] x23: 0000000000000040 x22: ffff000008d3dab8 > [88286.630268] x21: ffff800977804400 x20: 0000000000000007 > [88286.635532] x19: ffff000008c54000 x18: 0000fffff9185160 > [88286.640795] x17: 0000ffffb33d9a38 x16: ffff000008088270 > [88286.646059] x15: 0000ffffb345b590 x14: 0000000000000000 > [88286.651322] x13: 0000000000000004 x12: 0000000000000040 > [88286.656586] x11: 0000000000000068 x10: 0000000000000000 > [88286.661849] x9 : ffff800977400028 x8 : 0000000000000000 > [88286.667113] x7 : 0000000000000000 x6 : ffff0000080d8ae4 > [88286.672376] x5 : 0000000000000000 x4 : 0000000000000080 > [88286.677639] x3 : 0000000000000000 x2 : 0000000000000000 > [88286.682903] x1 : 0000000000000000 x0 : ffff8009751b0e08 > [88286.688166] > [88286.689638] ---[ end trace 31633f18fd33d4cb ]--- > [88286.694206] Call trace: > [88286.696627] Exception stack(0xffff8009768b38d0 to 0xffff8009768b3a00) > [88286.703004] 38c0: ffff000008c54000 0001000000000000 > [88286.710757] 38e0: ffff8009768b3aa0 ffff0000080d8c7c ffff8009768b3b50 ffff80097ff8a5b0 > [88286.718511] 3900: 0000800977325000 0000000000000000 0000000000000040 ffff80097ffc6180 > [88286.726264] 3920: ffff8009768b3940 ffff0000088a8694 ffff80097ffc5800 0000000000000000 > [88286.734017] 3940: ffff8009768b3960 ffff0000081919c0 ffff80097ffc5280 0000000000000001 > [88286.741771] 3960: ffff8009768b3a50 ffff00000819206c ffff8009751b0e08 0000000000000000 > [88286.749523] 3980: 0000000000000000 0000000000000000 0000000000000080 0000000000000000 > [88286.757277] 39a0: ffff0000080d8ae4 0000000000000000 0000000000000000 ffff800977400028 > [88286.765029] 39c0: 0000000000000000 0000000000000068 0000000000000040 0000000000000004 > [88286.772783] 39e0: 0000000000000000 0000ffffb345b590 ffff000008088270 0000ffffb33d9a38 > [88286.780537] [<ffff0000080d8c7c>] __queue_work+0x29c/0x3b8 > [88286.785883] [<ffff0000080d8df8>] queue_work_on+0x60/0x78 > [88286.791146] [<ffff000008764c68>] etm_setup_aux+0x178/0x238 > [88286.796578] [<ffff000008183600>] rb_alloc_aux+0x228/0x310 > [88286.801925] [<ffff00000817e564>] perf_mmap+0x404/0x5a8 > [88286.807015] [<ffff0000081c60cc>] mmap_region+0x394/0x5c0 > [88286.812276] [<ffff0000081c654c>] do_mmap+0x254/0x388 > [88286.817191] [<ffff0000081a989c>] vm_mmap_pgoff+0xbc/0xe0 > [88286.822452] [<ffff0000081c3ffc>] SyS_mmap_pgoff+0xac/0x228 > [88286.827884] [<ffff000008088288>] sys_mmap+0x18/0x28 > [88286.832714] [<ffff000008082f30>] el0_svc_naked+0x24/0x28 > > The patch makes sure that the event_data->work is initialised > properly before we could possibly use it. > > Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> > Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> > --- > drivers/hwtracing/coresight/coresight-etm-perf.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c > index 26cfac3..df63315 100644 > --- a/drivers/hwtracing/coresight/coresight-etm-perf.c > +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c > @@ -201,6 +201,7 @@ static void *etm_setup_aux(int event_cpu, void **pages, > event_data = alloc_event_data(event_cpu); > if (!event_data) > return NULL; > + INIT_WORK(&event_data->work, free_event_data); > > /* > * In theory nothing prevent tracers in a trace session from being > @@ -217,8 +218,6 @@ static void *etm_setup_aux(int event_cpu, void **pages, > if (!sink) > goto err; > > - INIT_WORK(&event_data->work, free_event_data); > - > mask = &event_data->mask; > > /* Setup the path for each CPU in a trace session */ > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK

8 years

ETM vs PTM

by Muhammad Abdul WAHAB

Hi, I was wondering the reasons ARM decided to move towards PTM source component instead of ETM component. What is the main reason that pushed towards this change ? Thanks for your reply. Best regards, MAW

8 years, 1 month

[PATCH] opencsd: update content to work with any kernel version

by Mathieu Poirier

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

8 years, 1 month

Decoding dynamically loaded and JITted code

by Al Grant

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

8 years, 1 month

Re: Some question about OpenCSD coresight drive usage

by Mathieu Poirier

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.

8 years, 1 month

[PATCH] perf tools: Print auxtrace header information

by Mathieu Poirier

>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

8 years, 1 month

[PATCH] perf tools: fix coresight-trace make config to use correct lib dir.

by Mike Leach

OpenCSD splits libraries into linux64 / linux for x64 / x86 and linux-arm64 / linux-arm for arm targets. This ensures consistency in native and cross compiling. Ensure that if compiling perf with the decoder we follow that convention in linking. Signed-off-by: Mike Leach <mike.leach(a)linaro.org> --- tools/perf/Makefile.config | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index ef83c37..3f811c1 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -556,8 +556,14 @@ strip-libs = $(filter-out -l%,$(1)) ifdef CSTRACE_PATH ifeq (${IS_64_BIT}, 1) CSTRACE_LNX = linux64 + ifeq (${ARCH}, arm64) + CSTRACE_LNX = linux-arm64 + endif else CSTRACE_LNX = linux + ifeq (${ARCH}, arm) + CSTRACE_LNX = linux-arm + endif endif ifeq (${DEBUG}, 1) LIBCSTRACE = -lcstraced_c_api -lcstraced -- 2.7.4

8 years, 1 month

Re: 答复: 答复: 答复: [PATCH] sctrl: coresight test: opening the sctrl atb clock gating

by Mathieu Poirier

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 > > > > > > > > >

8 years, 1 month

Enabling sinks before running perf

by Mike Leach

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

8 years, 1 month

ARM CoreSight SoC-600 is coming

by Chunyan Zhang

Hello All, This may not news now, but I just found it this morning :) https://community.arm.com/soc/b/blog/posts/the-future-of-debug-and-trace-ha… I else noticed that STMicroelectronics is among the first licensees of CoreSight SoC-600, congratulations! Cheers, Chunyan

8 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight