CoreSight

coresight@lists.linaro.org

2 participants
2384 discussions

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

by Mathieu Poirier

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

8 years, 2 months

kernel panic on stopping tracing with ETR as trace sink on Juno r0

by Don Kuzhiyelil

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

8 years, 2 months

Perf command line syntax

by Mathieu Poirier

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…

8 years, 2 months

Re: Request to review notes of coresight we discussed in bud17

by Mathieu Poirier

On 17 April 2017 at 10:45, Bamvor Zhang Jian <bamvor.zhangjian(a)linaro.org> wrote: > Hi, > > On 17 April 2017 at 21:21, Mathieu Poirier <mathieu.poirier(a)linaro.org> wrote: >> [snip] >> >> I have been travelling for the last two weeks and don't remember if I >> have answered this already. >> >>>> >>>> The wrapping around is normal and can't be avoided. Problems happens >>>> when we get a wrap around and Perf decides to concatenate buffers in a >>>> single notification to user space. When that happens there is no way >>>> for the decoding library to know the boundaries of individual packets, >>>> resulting in a lost of synchronisation and proper decoding of traces. >>>> >>>> This is very difficult to duplicate, hence taking a long time to deal >>>> with. I am still not sure about the conditions needed for Perf to >>>> concatenate buffers together. >>> Thanks for your expaination. So, will it be exist in the any senario? >> >> Yes, this can happen in any scenario. >> >>> If so, I think we need this patch too. >>> We encouter the wrong package recently and we have already use >>> filter. How could we know if it is the same issue? >> >> Sorry, I don't understand what you mean here by "wrong package" and >> the correlation is has on filters. Please explain further if you >> still need input on this. > 'Wrong packages' seem a little bit misleading. "packet" is the word you are looking for. > I would say there are some > unexpected packages. Maybe I could send you the full log of packages > tomorrow. I won't be able to look at it. >In summary, we found the following issues respectively: > 1. We found that if we start etm in the start/stop range, sometimes the > first address package(a jump or an instruction after isb) may be lost. > If we do a 100 times loop after the coresight timeout of etm enable. > It will not lost the package. I suspect there are some configuration issues > in our etm. But I do not find a clue right now. Is there some suggestion > from your side? I strongly suggest you purchase a dragonboard. That way you can reproduce the problems you are seeing on your platform on the dragonboard. That way it is much easier for us to work on issues you may encounter. This will be money well invested (they are very cheap). Beleive me, I wish we could use the HiKey but CS support on that platform isn't very encouraging at this time (not for the lack of trying). > 2. We found that there are some full zero(64bit) packages. Is it usual? It isn't no. Once again if you can reproduce this on a dragonboard I'd be happy to look at it. Otherwise it is impossible for me to help. > > Therea are probably some other questions. But it is too late for me(midnight > in beijing time). I could not recall the details. If I found other issues, > I will send to you later. Very well. Mathieu > > Thanks. > > Bamvor >> >> >>> I saw the description >>> of overflow. Could it monitor by CTI? >> >> CTIs would indeed prevent this from happening. >> >>> >>> Regards >>> >>> Bamvor >>> >>>> >>>>> >>>>> Regards >>>>> >>>>> Bamvor >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Bamvor >>>>>>>> After that I may be >>>>>>>> able to look at it if nothing else gets in the way.

8 years, 2 months

using trace under linux

by Karim Lamouchi

Hi, I have a question about tracing on cortex A.I have a plateform based on 2 cortex A7,and I need to trace the executed application. How can I activate the trace under linux (without using external hardware) to access to coresight components (STM,ETM,PTM,CTI,ETF...) and configure them as well as the extraction of the datas trace ?Could you please describe the differents steps that allow me to trace my application and what is the librairie should be used for the trace? Best regards Karim.

8 years, 2 months

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, 2 months

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, 2 months

[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, 3 months

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, 3 months

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, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight