CoreSight

coresight@lists.linaro.org

6 participants
2467 discussions

Re: segmentation fault happens when reporting the perf.data

by Mathieu Poirier

On 10 October 2016 at 10:52, liubowen (A) <liubowen2(a)huawei.com> wrote: > Hi Mathieu: > > > > I am bob. ^_^ Indeed > > > > I am still stuck in the process of reporting. And I change to version > 4.8 and follow the newest HOWTO.md, but still get the error “Segmentation > fault (core dumped)” when reporting the perf.data. When asking questions like that CC the coresight mailing list (as I did here) - that way other people can help you. So, you've been working on this for weeks now without meaningful progress. This is a user space problem that has nothing to do with the trace acquisition on the target platform. Since you have all the source have you instrumented the code to see where the code dump happens? Knowing exactly where the fault happens will tell you about the nature of the problem and maybe to fix it yourself! Since you can decode the example sample then something is different in the trace data you generate. That doesn't mean it is wrong, it just means it is different. That is why you need to instrument the code to see what is happening. > > > > However the demo offered by you can be reported. It is very strange. And > I cannot find a better solution to solve this problem, > > > > I am eager for your help. > > > > Here, I offer some information about I am working. Firstly, I work based > on such as perf-opencsd-4.7. In order to run well on my platform similar to > D02 made from hisilicon, I change some files under ./drivers/irqchip. Then, > the coresight can work and the trace data can be written into perf.data. > Then, we should install opencsd on x86 machine, here, can we report the > perf.data on aarch64 machine? On the other hand, suppose that I get the > mainline kernel version 4.7, and make a Image which will be used on the > platform, and the coresight should work well, so is it not necessary to make > a Image from such as perf-opencsd-4.7? > > > > If you are convenient, we can offer you a platform I am working on. And > we can work together to make it come true. Of course you are very convenient > on condition. Unfortunately I don't have the bandwidth to work on your board. On the flip side I can try to decode the your trace data in my environment. Send me the files and the perf command line and I'll see what I can do - but again I have very limited bandwidth. Note that I won't try anything until you actually tell me the exact line the code crashes - you have to do the investigation. > > > > Thanks very much for your time as usual! I am appreciated for whatever > you have done. > > > > Best regards > > > > bob > >

8 years, 11 months

[PATCH] howto: update content to work with kernel v4.8

by Mathieu Poirier

Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> --- HOWTO.md | 204 ++++++++++++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 163 insertions(+), 41 deletions(-) diff --git a/HOWTO.md b/HOWTO.md index 3f2a1399be76..aee5ef8b8b6e 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -7,23 +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 branches `opencsd-0v002` and `opencsd-0v003` (decode library only) -and the latest perf branch `perf-opencsd-4.7` (decode library + perf tools) +using library version v0.4.1 and the latest perf branch `perf-opencsd-4.8` on the [OpenCSD github repository][1]. -From v0.4 of the library releases appear as master branch tags. v0.4 requires -a patched version of the `perf-opencsd-4.7` perf tools to use the updated C API. -The unpatched `perf-opencsd-4.7` may be used with v0.4 if the build makefile -for the tools is altered to #define OPENCSD_INC_DEPRECATED_API which will -include the decprecated function call wrappers for the new generic API. 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.7` needs to be downloaded to the target system where -traces are to be collected. This branch is an upstream v4.7 kernel +`perf-opencsd-4.8` needs to be downloaded to the target system where +traces are to be collected. This branch is an upstream v4.8 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. @@ -50,7 +43,7 @@ the sink that will recieve trace data needs to be identified and given as an option on the perf command line. Once a sink has been identify trace collection can start. An easy and yet interesting example is the `uname` command: - linaro@linaro-nano:~/kernel$ ./tools/perf/perf record -e cs_etm/(a)sink=20070000.etr/ --per-thread uname + linaro@linaro-nano:~/kernel$ ./tools/perf/perf record -e cs_etm/(a)20070000.etr/ --per-thread uname This will generate a `perf.data` file where execution has been traced for both user and kernel space. To narrow the field to either user or kernel space the @@ -58,7 +51,7 @@ user and kernel space. To narrow the field to either user or kernel space the traces to user space: - linaro@linaro-nano:~/kernel$ ./tools/perf/perf record -vvv -e cs_etm/(a)sink=20070000.etr/u --per-thread uname + linaro@linaro-nano:~/kernel$ ./tools/perf/perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname Problems setting modules path maps, continuing anyway... ----------------------------------------------------------- perf_event_attr: @@ -121,10 +114,108 @@ traces to user space: drwxr-xr-x 3 linaro linaro 4096 Mar 2 20:40 bin drwxr-xr-x 3 linaro linaro 4096 Mar 2 20:40 lib +Trace data filtering +-------------------- +The amount of traces generated by CoreSight tracers is staggering, event for +the most simple trace scenario. Reducing trace generation to specific areas +of interest is desirable to save trace buffer space and avoid getting lost in +the trace data that isn't relevant. Supplementing the 'k' and 'u' options +described above is the notion of address filters. + +On CoreSight two types of address filter have been implemented - address range +and start/stop filter: + +**Address range filters:** +With address range filters traces are generated if the instruction pointer +falls within the specified range. Any work done by the CPU outside of that +range will not be traced. Address range filters can be specified for both +user and kernel space session: + + perf record -e cs_etm/(a)20070000.etr/k --filter 'filter 0xffffff8008562d0c/0x48' --per-thread uname + + perf record -e cs_etm/(a)20070000.etr/u --filter 'filter 0x72c/0x40(a)/opt/lib/libcstest.so.1.0' --per-thread ./main + +When dealing with kernel space trace addresses are typically taken in the +'System.map' file. In user space addresses are relocatable and can be +extracted from an objdump output: + + $ aarch64-linux-gnu-objdump -d libcstest.so.1.0 + ... + ... + 000000000000072c <coresight_test1>: <------------ Beginning of traces + 72c: d10083ff sub sp, sp, #0x20 + 730: b9000fe0 str w0, [sp,#12] + 734: b9001fff str wzr, [sp,#28] + 738: 14000007 b 754 <coresight_test1+0x28> + 73c: b9400fe0 ldr w0, [sp,#12] + 740: 11000800 add w0, w0, #0x2 + 744: b9000fe0 str w0, [sp,#12] + 748: b9401fe0 ldr w0, [sp,#28] + 74c: 11000400 add w0, w0, #0x1 + 750: b9001fe0 str w0, [sp,#28] + 754: b9401fe0 ldr w0, [sp,#28] + 758: 7100101f cmp w0, #0x4 + 75c: 54ffff0d b.le 73c <coresight_test1+0x10> + 760: b9400fe0 ldr w0, [sp,#12] + 764: 910083ff add sp, sp, #0x20 + 768: d65f03c0 ret + ... + ... + +Following the address the amount of byte is specified and if tracing in user +space, the full path to the binary (or library) being traced. + +**Start/Stop filters:** +With start/stop filters traces are generated when the instruction pointer is +equal to the start address. Incidentally traces stop being generated when the +insruction pointer is equal to the stop address. Anything that happens between +there to events is traced: + + perf record -e cs_etm/(a)20070000.etr/k --filter 'start 0xffffff800856bc50,stop 0xffffff800856bcb0' --per-thread uname + + perf record -vvv -e cs_etm/(a)20070000.etr/u --filter 'start 0x72c(a)/opt/lib/libcstest.so.1.0, \ + stop 0x40082c@/home/linaro/main' \ + --per-thread ./main + +**Limitation on address filters:** +The only limitation on address filters is the amount of address comparator +found on an implementation and the mutual exclusion between range and +start stop filters. As such the following example would _not_ work: + + perf record -e cs_etm/(a)20070000.etr/k --filter 'start 0xffffff800856bc50,stop 0xffffff800856bcb0, \ // start/stop + filter 0x72c/0x40(a)/opt/lib/libcstest.so.1.0' \ // address range + --per-thread uname + On Target Trace Collection -------------------------- The entire program flow will have been recorded in the `perf.data` file. -Information about libraries and executable is stored under `$HOME/.debug` . +Information about libraries and executable is stored under `$HOME/.debug`: + + linaro@linaro-nano:~/kernel$ tree ~/.debug + .debug + ├── [kernel.kallsyms] + │ └── 0542921808098d591a7acba5a1163e8991897669 + │ └── kallsyms + ├── [vdso] + │ └── 551fbbe29579eb63be3178a04c16830b8d449769 + │ └── vdso + ├── bin + │ └── uname + │ └── ed95e81f97c4471fb2ccc21e356b780eb0c92676 + │ └── elf + └── lib + └── aarch64-linux-gnu + ├── ld-2.21.so + │ └── 94912dc5a1dc8c7ef2c4e4649d4b1639b6ebc8b7 + │ └── elf + └── libc-2.21.so + └── 169a143e9c40cfd9d09695333e45fd67743cd2d6 + └── elf + + 13 directories, 5 files + linaro@linaro-nano:~/kernel$ + + All this information needs to be collected in order to successfully decode traces off target: @@ -141,7 +232,7 @@ As of this writing the openCSD library is not part of the perf tools source. It is available on [github][1] and needs to be compiled before perf. Checkout the required branch/tag version into a local directory. - linaro@t430:~/linaro/coresight$ git clone -b opencsd-0v003 https://github.com/Linaro/OpenCSD.git my-opencsd + linaro@t430:~/linaro/coresight$ git clone -b v0.4.1 https://github.com/Linaro/OpenCSD.git my-opencsd Cloning into 'OpenCSD'... remote: Counting objects: 2063, done. remote: Total 2063 (delta 0), reused 0 (delta 0), pack-reused 2063 @@ -166,19 +257,20 @@ the host's (which has nothing to do with the target) architecture: linaro@t430:~/linaro/coresight/my-opencsd/decoder/build/linux$ ls ../../lib/linux64/dbg/ libcstraced.a libcstraced_c_api.a libcstraced_c_api.so libcstraced.so + 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.7` needs to be +get all the components branch `perf-opencsd-4.8` needs to be obtained: - linaro@t430:~/linaro/coresight$ git clone -b perf-opencsd-4.7 https://github.com/Linaro/OpenCSD.git perf-opencsd-4.7 + linaro@t430:~/linaro/coresight$ git clone -b perf-opencsd-4.8 https://github.com/Linaro/OpenCSD.git perf-opencsd-4.8 ... ... - linaro@t430:~/linaro/coresight$ ls perf-opencsd-4.7/ + linaro@t430:~/linaro/coresight$ ls perf-opencsd-4.8/ 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 + block COPYING crypto drivers fs init Kbuild kernel MAINTAINERS mm README samples security tools virt Since the openCSD library is not part of the perf tools, an environment variable telling the build scripts where to find the library is needed. If @@ -187,12 +279,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.7 - linaro@t430:~/linaro/coresight/perf-opencsd-4.7$ export CSTRACE_PATH=~/linaro/coresight/my-opencsd/decoder - linaro@t430:~/linaro/coresight/perf-opencsd-4.7$ make -C tools/perf + linaro@t430:~/linaro/coresight$ cd perf-opencsd-4.8 + linaro@t430:~/linaro/coresight/perf-opencsd-4.8$ export CSTRACE_PATH=~/linaro/coresight/my-opencsd/decoder + linaro@t430:~/linaro/coresight/perf-opencsd-4.8$ make -C tools/perf ... ... - linaro@t430:~/linaro/coresight/perf-opencsd-4.7$ ls -l tools/perf/perf + linaro@t430:~/linaro/coresight/perf-opencsd-4.8$ ls -l tools/perf/perf -rwxrwxr-x 1 linaro linaro 6276360 Mar 3 10:05 tools/perf/perf @@ -205,34 +297,33 @@ At the end of the compilation a new perf binary is available in `tools/perf/` Trace Decoding with Perf Report ------------------------------- - Before working with custom traces it is suggested to use a trace bundle that is known to be working properly. A sample bundle has been made available here [2]. Trace bundles can be extracted anywhere and have no dependencies on where the perf tools and openCSD library have been compiled. - linaro@t430:~/linaro/coresight$ mkdir feb24 - linaro@t430:~/linaro/coresight$ cd feb24 - linaro@t430:~/linaro/coresight/feb24$ wget http://people.linaro.org/~mathieu.poirier/openCSD/uname.v4.user.feb24.tgz - linaro@t430:~/linaro/coresight/feb24$ md5sum uname.v4.user.feb24.tgz - f53f11d687ce72bdbe9de2e67e960ec6 uname.v4.user.feb24.tgz - linaro@t430:~/linaro/coresight/feb24$ tar xf uname.v4.user.feb24.tgz - linaro@t430:~/linaro/coresight/feb24$ ls -la + linaro@t430:~/linaro/coresight$ mkdir sept20 + linaro@t430:~/linaro/coresight$ cd sept20 + linaro@t430:~/linaro/coresight/sept20$ wget http://people.linaro.org/~mathieu.poirier/openCSD/uname.v4.user.sept20.tgz + linaro@t430:~/linaro/coresight/sept20$ md5sum uname.v4.user.sept20.tgz + f53f11d687ce72bdbe9de2e67e960ec6 uname.v4.user.sept20.tgz + linaro@t430:~/linaro/coresight/sept20$ tar xf uname.v4.user.sept20.tgz + linaro@t430:~/linaro/coresight/sept20$ ls -la total 1312 drwxrwxr-x 3 linaro linaro 4096 Mar 3 10:26 . drwxrwxr-x 5 linaro linaro 4096 Mar 3 10:13 .. drwxr-xr-x 7 linaro linaro 4096 Feb 24 12:21 .debug -rw------- 1 linaro linaro 78016 Feb 24 12:21 perf.data - -rw-rw-r-- 1 linaro linaro 1245881 Feb 24 12:25 uname.v4.user.feb24.tgz + -rw-rw-r-- 1 linaro linaro 1245881 Feb 24 12:25 uname.v4.user.sept20.tgz Perf is expecting files related to the trace capture (`perf.data`) to be located under `~/.debug` [3]. This example will remove the current `~/.debug` directory to be sure everything is clean. - linaro@t430:~/linaro/coresight/feb24$ rm -rf ~/.debug - linaro@t430:~/linaro/coresight/feb24$ cp -dpR .debug ~/ - linaro@t430:~/linaro/coresight/feb24$ export LD_LIBRARY_PATH=~/linaro/coresight/my-opencsd/decoder/lib/linux64/dbg/ - linaro@t430:~/linaro/coresight/feb24$ ../perf-opencsd-4.7/tools/perf/perf report --stdio + 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.8/tools/perf/perf report --stdio # To display the perf.data header info, please use --header/--header-only options. # @@ -276,7 +367,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.7/coresight/tools/perf/perf report --stdio --dump + mjl@ubuntu-vbox:./perf-opencsd-4.8/coresight/tools/perf/perf report --stdio --dump resulting a large amount of data, trace looking like:- @@ -325,10 +416,10 @@ Trace Decoding with Perf Script Working with perf scripts needs more command line options but yields interesting results. - linaro@t430:~/linaro/coresight/feb24$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-4.7/tools/perf/ - linaro@t430:~/linaro/coresight/feb24$ export SCRIPT_PATH=$EXEC_PATH/scripts/python/ - linaro@t430:~/linaro/coresight/feb24$ export XTOOL_PATH=/your/aarch64/toolchain/path/bin/ - linaro@t430:~/linaro/coresight/feb24$ ../perf-opencsd-4.7/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$ export EXEC_PATH=/home/linaro/coresight/perf-opencsd-4.8/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.8/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> @@ -354,6 +445,37 @@ interesting results. 7f89f28304: eb01001f cmp x0, x1 7f89f28308: 54ffffc1 b.ne 7f89f28300 <free@plt+0x37c0> +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.8/tools/perf/perf report --stdio --vmlinux=./vmlinux + ... + ... + linaro@t430:~/linaro/coresight/sept20$ ../perf-opencsd-4.8/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.8/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.8/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 \ + -k ./vmlinux + ... + ... + +The option "--vmlinux=./vmlinux" is interpreted by the "perf script" command +the same way it if for "perf report". The option "-k ./vmlinux" is dependant +on the script being executed and has no related to the "--vmlinux", though it +is highly advised to keep them synchronized. + + Perf Test Environment Scripts ----------------------------- @@ -415,6 +537,6 @@ Best regards, -------------------------------------- [1]: https://github.com/Linaro/OpenCSD "OpenCSD Github" -[2]: wget http://people.linaro.org/~mathieu.poirier/openCSD/uname.v4.user.feb24.tgz +[2]: http://people.linaro.org/~mathieu.poirier/openCSD/uname.v4.user.sept20.tgz [3]: Get in touch with us if you know a way to change this. -- 2.7.4

8 years, 11 months

RE: Usage of Coresight

by Kaiyou Wang

Hi Mathieu, Thanks, I don't find CS devices list in the dts file. Hi Suzuki, Could you give me any help? How to add them in dts file, is there any example? I download the code by the instruction of https://community.arm.com/docs/DOC-10804 , build with" ./build-scripts/build-all.sh juno-busybox" Thanks -----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: Wednesday, September 28, 2016 7:27 AM To: Kaiyou Wang Subject: Re: Usage of Coresight If you don't see CS devices under /sys/bus/coresight/devices/ it means that either there is not CS devices listed in the DT or something is wrong with the clock and the blocks aren't discovered during the AMBA probe. Suzuki Poulose can likely help you on that front. Mathieu On 27 September 2016 at 00:03, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: > Hi Mathieu, > > On my Juno-R2 board, there is no device under > /sys/bus/coresight/devices/ How to enable it? > > / # > / # ls /sys/bus/coresight/ > devices drivers_autoprobe uevent > drivers drivers_probe > / # ls /sys/bus/coresight/devices/ > / # > / # > / # ls sys/bus/coresight/drivers > / # > / # cat sys/bus/coresight/drivers_autoprobe > 1 > / # > > -----Original Message----- > From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] > Sent: Tuesday, September 27, 2016 5:54 AM > To: Kaiyou Wang > Cc: coresight(a)lists.linaro.org > Subject: Re: Usage of Coresight > > On 26 September 2016 at 04:12, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: >> Hi Mathieu, >> >> Thanks for your reply, ask a quick question, is there any lock on SOC? > > None > >> I find CPU cannot access the mapped register of ETM after unlock the OSLOCK and software access lock. >> But the coresight driver could access them, could you give me any suggestion? > > What are you looking to do? There is definitely something wrong but it is impossible for me to help you with the information you have provided. The _probe() functions are fairly simple - I suggest using those as a starting example. From there it should be easy to work your way back to your current situation. > > Mathieu > > >> >> -----Original Message----- >> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >> Sent: Wednesday, September 21, 2016 10:27 PM >> To: Kaiyou Wang >> Cc: coresight(a)lists.linaro.org >> Subject: Re: Usage of Coresight >> >> Good day, >> >> There is a lot of documentation around on how to use the CoreSight framework and drivers. In the kernel tree the documentation directory [1] is a good place to start. Regarding the integration with perf and how that works with the rest of the solution you are encouraged to visit the openCSD github site [2]. There the "HOWTO.md" on the master branch has all the details needed to get the solution going. >> >> That being said the release of kernel v4.8 is imminent (Sunday September 25th to be exact) and with it comes a lot of new functionality. I will be rebasing all the out of tree code to v4.8 along with updating the documentation next week - by Friday September 20th everything should be in good standing. >> >> In the mean time you can read the current HOWTO.md to get familiar with the solution, that is probably a good time investment. >> >> Thanks, >> Mathieu >> >> [1]. >> http://lxr.free-electrons.com/source/Documentation/trace/coresight.tx >> t [2]. https://github.com/Linaro/OpenCSD >> >> On 21 September 2016 at 04:27, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: >>> Hi Mathieu, >>> >>> >>> >>> This is Kaiyou from ARM, I find the Coresight drive in Linaro >>> kernel code “kernel-release/drivers/hwtracing/coresight”. >>> >>> Could you give me any documents how to use the Coresight driver in >>> Linaro Kernel? >>> >>> >>> >>> 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. >> >> 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. > > 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. 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, 11 months

Re: Usage of Coresight

by Mathieu Poirier

On 26 September 2016 at 04:12, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: > Hi Mathieu, > > Thanks for your reply, ask a quick question, is there any lock on SOC? None > I find CPU cannot access the mapped register of ETM after unlock the OSLOCK and software access lock. > But the coresight driver could access them, could you give me any suggestion? What are you looking to do? There is definitely something wrong but it is impossible for me to help you with the information you have provided. The _probe() functions are fairly simple - I suggest using those as a starting example. From there it should be easy to work your way back to your current situation. Mathieu > > -----Original Message----- > From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] > Sent: Wednesday, September 21, 2016 10:27 PM > To: Kaiyou Wang > Cc: coresight(a)lists.linaro.org > Subject: Re: Usage of Coresight > > Good day, > > There is a lot of documentation around on how to use the CoreSight framework and drivers. In the kernel tree the documentation directory [1] is a good place to start. Regarding the integration with perf and how that works with the rest of the solution you are encouraged to visit the openCSD github site [2]. There the "HOWTO.md" on the master branch has all the details needed to get the solution going. > > That being said the release of kernel v4.8 is imminent (Sunday September 25th to be exact) and with it comes a lot of new functionality. I will be rebasing all the out of tree code to v4.8 along with updating the documentation next week - by Friday September 20th everything should be in good standing. > > In the mean time you can read the current HOWTO.md to get familiar with the solution, that is probably a good time investment. > > Thanks, > Mathieu > > [1]. http://lxr.free-electrons.com/source/Documentation/trace/coresight.txt > [2]. https://github.com/Linaro/OpenCSD > > On 21 September 2016 at 04:27, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: >> Hi Mathieu, >> >> >> >> This is Kaiyou from ARM, I find the Coresight drive in Linaro kernel >> code “kernel-release/drivers/hwtracing/coresight”. >> >> Could you give me any documents how to use the Coresight driver in >> Linaro Kernel? >> >> >> >> 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. > > 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, 11 months

Re: questions on coresight integrated with perf

by Mathieu Poirier

On 23 September 2016 at 11:30, liubowen (A) <liubowen2(a)huawei.com> wrote: > Hi Mathieu: > > > > I am bob. And I go to bother you again. ^_^ > > > > Now, the trace data can be written into perf.data, just like > that. The cmd is “perf record –C 0 –e cs_etm/(a)sink=44001000.etr/ uname”. > Any particular reason why you want to trace on CPU 0 only? Using the "--per-thread" option will tell Perf to follow execution of your program on any CPU the scheduler choose to put it on. > > > > > However, when I want to report the perf.data, I get the error message just > like that. > > > > > > Have you ever met this problem? > No I haven't. This is a user space problem and has nothing to do with the coresight drivers. > > > I am also working hard to solve this problem by myself. I have spent some > time on studing the coresight drivers code by adding print . When we use > perf to record trace data, it goes like that, from my opinion, > > > > It is only what I think based on the print message added into the kernel > by myself. I am not sure it is true. > This looks about right. > And the perf.data contains two AUXTRACE instance in my case. > Right, those are areas of the file containing CoreSight trace data. > > > > > If true, I have some questions here. Because we want to get the continuous > flow of instructions using coresight, between (1) and (2), the corsight is > in state of stopped or disabled, finally we > > > > will get discontinuous flow of instructions. Do you think so? > The cool thing about Perf is that when a process is scheduled for execution it tells the PMU to start tracing. The same thing happens when the process is taken off a CPU either because it has terminated, it is waiting on some IO to finish or it is preempted. In (1) the process has been scheduled on a CPU and was running until it was scheduled out (for some reason). In (2) the process is ready to run again and as such CS is enabled again. You don't want to know what is happening between (1) and (2) as it is not relevant for that trace session. > > On the other hand, in my test case, only the trace data made from (1) and > (2) are written into perf.data, but the trace data made from (3) does not. > I don’t know why. And I have another question annoyed me, > > > > when (1) is done, which one condition is to trigger (2)? I think it is > something about perf, and I have studied the perf code, and still confused. > There is no need to study the perf code - it is very complex. (2) gets started when the process is scheduled on a CPU again. > > > And everytime the record is done, I will also get the bug info like that. > I am working on version 4.7 from your kernel, I have tried to use version > 4.8 from your kernel, but the same bug info. Have you ever met? > > > > > That is bizarre, especially since you are using the the ETR driver. From what I can tell memory is being freed while a spinlock is held. Did you happen to change the code at all? Kernel version 4.8 will be released on Sunday - I am currently writing the documentation (HOWTO.md) that goes with it. I suggest to move to that version since a lot of code has gone in. Make sure to read the documentation, some of user space has changed. That should all be ready by next Friday (September 30th). > I am sorry to trouble you. And Thanks very much for your time. I am a > beginner, and beg your pardon. And I am interested in your project, I hope > I can make it come true on my platform. > > > > And, as you say, I do not get a good understanding of the coresight. So I > have spent some time on reading the CoreSight_Architecture_Specification > and CoreSight Trace Memory Controller recently. I get a lot. However > > > > I still need your suggestions. Thanks very very much! > There is a lot of concept to master before understanding CoreSight. It might not be obvious now but all that debugging you're doing will definitely help in the future. > > > Best regards. > > > > Bob. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

8 years, 11 months

Re: Usage of Coresight

by Mathieu Poirier

Good day, There is a lot of documentation around on how to use the CoreSight framework and drivers. In the kernel tree the documentation directory [1] is a good place to start. Regarding the integration with perf and how that works with the rest of the solution you are encouraged to visit the openCSD github site [2]. There the "HOWTO.md" on the master branch has all the details needed to get the solution going. That being said the release of kernel v4.8 is imminent (Sunday September 25th to be exact) and with it comes a lot of new functionality. I will be rebasing all the out of tree code to v4.8 along with updating the documentation next week - by Friday September 20th everything should be in good standing. In the mean time you can read the current HOWTO.md to get familiar with the solution, that is probably a good time investment. Thanks, Mathieu [1]. http://lxr.free-electrons.com/source/Documentation/trace/coresight.txt [2]. https://github.com/Linaro/OpenCSD On 21 September 2016 at 04:27, Kaiyou Wang <Kaiyou.Wang(a)arm.com> wrote: > Hi Mathieu, > > > > This is Kaiyou from ARM, I find the Coresight drive in Linaro kernel code > “kernel-release/drivers/hwtracing/coresight”. > > Could you give me any documents how to use the Coresight driver in Linaro > Kernel? > > > > 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, 11 months

【questions on coresight integrated with perf】

by liubowen (A)

Hi Mathieu: I am bob. And thanks for your time as always! In the past for a while, I worked based on our kernel and applied the patches about coresight from “perf-opencsd-4.7”. However, it is not successful. So, I work based on your kernel “perf-opencsd-4.7”, and add some drivers about the board made from Hisilicon. In theory, it should go well. But I get the same error. When I use perf to record data, the record will stop for a long time. And I check the source code and the program will stay in “perf_evlist__poll” and do not return just as follow. [cid:image008.jpg@01D20A2E.C3BE2EC0] So I use “Ctrl + C” to stop record, and I get the bug as follow. [cid:image001.png@01D20A24.E814E6B0] [cid:image002.png@01D20A26.DF7334B0] On the other hand, I do a test as follow. [cid:image009.jpg@01D20A2E.C3BE2EC0] In the source code, when we use the ETR mode, it will allocate 1M space as follow. [cid:image010.jpg@01D20A2E.C3BE2EC0] So, the coresight turns out to work well. Here, I have another question, when I change “SZ_1M” to a value bigger than 1M such as “SZ_2M”, and I try to enable the etr device, I get the error “cannot allocate memory”. And I am sorry to trouble you, can you give me some suggestion? It really take a lot of my time to work on the project, I hope I can success finally. Thanks very much for your time and all your help!! Best regards! Bob

9 years

[PATCH 1/2] perf scripts: Fix binary filename and path

by Mathieu Poirier

Nowadays binary files collected in the .debug directory either have the explicit name of "elf", "kallsyms" and "vdso" rather than the build id: home/mpoirier/.debug/ ├── home │ └── linaro │ └── main │ └── 9a6850fab2ebbe386d3619bce3674a55622f2872 │ └── elf ├── [kernel.kallsyms] │ └── 460b314b8040fb8f3871b67b7ff3d3498e74bc22 │ └── kallsyms ├── lib │ └── aarch64-linux-gnu │ ├── ld-2.21.so │ │ └── 94912dc5a1dc8c7ef2c4e4649d4b1639b6ebc8b7 │ │ └── elf │ └── libc-2.21.so │ └── 169a143e9c40cfd9d09695333e45fd67743cd2d6 │ └── elf ├── opt │ └── lib │ └── libcstest.so.1.0 │ └── 3b3051b8a67f212a66e383fc90db3c2bde8f936f │ └── elf └── [vdso] └── c610c0514acb76a39a3419ff719f80dfea9db5fe └── vdso This patch adds the right filename based on the "buildid_list" output. The directory path is also adjusted to include a forward slash characters ('/') when needed (kallsyms and vsdo). Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> --- tools/perf/scripts/python/cs-trace-disasm.py | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/perf/scripts/python/cs-trace-disasm.py b/tools/perf/scripts/python/cs-trace-disasm.py index 429d0d2d7a23..75f67d314a42 100644 --- a/tools/perf/scripts/python/cs-trace-disasm.py +++ b/tools/perf/scripts/python/cs-trace-disasm.py @@ -48,9 +48,19 @@ def trace_begin(): for line in cmd_output: m = bid_re.search(line) if (m != None) : + if (m.group(2) == "[kernel.kallsyms]") : + append = "/kallsyms" + dirname = "/" + m.group(2) + elif (m.group(2) == "[vdso]") : + append = "/vdso" + dirname = "/" + m.group(2) + else: + append = "/elf" + dirname = m.group(2) + build_ids[m.group(2)] = \ os.environ['PERF_BUILDID_DIR'] + \ - m.group(2) + "/" + m.group(1); + dirname + "/" + m.group(1) + append; if ((options.vmlinux_name != None) and ("[kernel.kallsyms]" in build_ids)): build_ids['[kernel.kallsyms]'] = options.vmlinux_name; -- 2.7.4

9 years

Re: 【questions on coresight integrated with perf】

by Mathieu Poirier

On 23 August 2016 at 10:24, liubowen (A) <liubowen2(a)huawei.com> wrote: > Hi Mathieu, > > I am Bob. > > > > I still get stuck. I feel not good. However, I should move on. > > The reason why I fail is as follows. > > > > > > On current station, I work on the board similar to D02 made from > Hisilicon. And the Image comes from “4.7.0-rc2” into which we have added a > lot drivers related with the board. > > > > From the log from git, the latest change about coresight for “4.7.0-rc2” > is “2016-05-21”. But “perf-opencsd-4.7” has changed a lot after the point > “2016-05-21”. > > > > > > Maybe ,the problem is here. I make a “perf” executable from > “perf-opencsd-4.7”, but the coresight drivers used to generate trace data > aren’t complete. The drivers come from “4.7.0-rc2” not “perf-opencsd-4.7”. > > > > So, I intend to make a Image from the branch “perf-opencsd-4.7”, > but there is a lot of work in adding relational drivers with the board. I > give up this way for the moment. > > > > So, I want to add complete coresight driver from “perf-opencsd-4.7” into > “4.7.0-rc2” which I am working on. Can you help me? Can you offer me the > whole patches about coresight and others necessary? > > I have tried to compare the file from the two branches, and make the > relational files same to the files in “perf-opencsd-4.7” by hand, but it is > not clever. > > > > I am sorry to trouble you. I hope my question is clear for you. Howevew, > thanks very much for your time!! > > > > Best regards! > > > > Bob > You have found the problem - congratulation. I am working very hard on upstreaming all the out-of-tree code available on github (perf-opencsd-4.8-rc1) but it will probably take a few more kernel cycle before everything finds its way mainline. I am not sure how else I can help you, or if I can help you at all. All the code is publicly available and updated with each new kernel cycle. Best regards, Mathieu

9 years

Sharing an article on STM for your review

by Chunyan Zhang

Hi All, The first version of draft [1] just finished on google docs, it will be (I hope) published as the September Core Dump article as we expected. I tried my best to make the words and sentences in this documentation clear and correct though, there must be some mistakes I believe :) Please have a look and any comments and advices would be greatly appreciated. I've added a few person in the can-edit list, but I don't know exactly all email addresses which are in this list, so you may find yourself don't have the edit authority, if that's the case please let me know, or you can simply comment on email. Many thanks, Chunyan [1] https://docs.google.com/document/d/16YICrRW4Tm51uU8bMgtJ2hR_VQyEqiTBd4wlA55…

9 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight