CoreSight

coresight@lists.linaro.org

6 participants
2435 discussions

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

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

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

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

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

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

[PATCH] perf tool: cs-etm: fix build error by removing unused cs_etm_global_header_fmts array

by Kim Phillips

Needed to build arm64 perf with at least gcc 6.2, otherwise get: util/cs-etm.c:1466:27: error: ‘cs_etm_global_header_fmts’ defined but not used [-Werror=unused-const-variable=] static const char * const cs_etm_global_header_fmts[] = { ^~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Kim Phillips <kim.phillips(a)arm.com> --- tools/perf/util/cs-etm.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 70825e7..5ff3c3e 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1463,12 +1463,6 @@ static int cs_etm__process_auxtrace_event(struct perf_session *session, } -static const char * const cs_etm_global_header_fmts[] = { - [CS_HEADER_VERSION_0] = " Header version %"PRIx64"\n", - [CS_PMU_TYPE_CPUS] = " PMU type/num cpus %"PRIx64"\n", - [CS_ETM_SNAPSHOT] = " Snapshot %"PRIx64"\n", -}; - static const char * const cs_etm_priv_fmts[] = { [CS_ETM_MAGIC] = " Magic number %"PRIx64"\n", [CS_ETM_CPU] = " CPU %"PRIx64"\n", -- 2.10.2

8 years, 5 months

CoreSight components benchmarking/overhead evaluation

by Muhammad Abdul WAHAB

Hello, I have a couple of questions regarding CoreSight components. How can I evaluate the bandwidth of CS components ? How to evaluate energy overhead introduced by activating CS components ? What would be the best metrics to evaluate CS components or similar debug components ? Besides, I tried evaluating CS components overhead and I did not really see any change in execution time overhead. I understand that this is because the PTM is non-intrusive debug component and that it has a copy of cpu instructions and it operates in parallel. Am I right about this ? Thank you very much for your help and time. Best Regards, M.Abdul WAHAB

8 years, 5 months

Debugging via STM

by lamouchi_KARIM

Hi all, I want to use STM to debug a platform based on cortex a7 under linux and windows. I want to decode all the packet generated by this component within ETB buffer ,then desplay them in a readebal file. Could you help please? Best regards, Karim.

8 years, 5 months

Re: CoreSight components benchmarking/overhead evaluation

by Muhammad Abdul WAHAB

Hi Mathieu, Le 15/03/2017 à 18:00, Mathieu Poirier a écrit : > What do you mean by "bandwidth"? Please give us a little more details. I am using PTM component to trace a program on Linux. I recover the trace on FPGA using TPIU. I was wondering what types of program will generate so much trace that the PTM's internal FIFO will overflow and I won't be able to get the trace for my program. To evaluate this, I thought about benchmarking CoreSight with MiBench programs but I did not see any overflow (by having a look at decoded trace and having a look at I-Sync packet). > That won't be easy as it is HW dependent. Energy probes that tap > directly into the CPU cores would be best but again, the probe points > need to be present in HW. That's only one part of the equation - the > debug power domain also has to be measured. I don't have any measurement tools. I was thinking more about a simulator or something that would allow me to do it from Zynq SoC. I think I might be able to get more details on this one from Xilinx as I am using Xilinx Zynq SoC. > Again, you will have to give me a little more details on what you need to do. The idea is to find suitable metrics to evaluate debug components. Depending on the type of trace source and trace sink, there will be differences. My trace source will be PTM and I was thinking about first using ETB as trace sink to evaluate the maximum trace bandwidth. Then, do the same evaluation with TPIU. I was wondering what will be the suitable metrics to evaluate CS components efficiency. Is it enough to benchmark the CS Debug components with MiBench Benchmark and evaluate execution time overhead. > I hope this helps Of course, it helped. Thank you so much for your quick reply. Best Regards, M.Abdul WAHAB

8 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight