CoreSight May 2017

coresight@lists.linaro.org

12 participants
8 discussions

[PATCH 1/2] perf inject: correct recording of branch address and destination

by Sebastian Pop

ARM ETM traces contain packets of executed instructions. The addresses recorded in the trace correspond to the beginning and one instruction past the end of the block of executed instructions. In order to record the address and destination of executed branches, keep track of two packets: the jump occurs from the last executed instruction of the previous packet to the address of the first instruction in the current packet. Signed-off-by: Sebastian Pop <s.pop(a)samsung.com> Signed-off-by: Brian Rzycki <b.rzycki(a)samsung.com> --- tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++++ tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 + tools/perf/util/cs-etm.c | 91 +++++++++++++++++-------- 3 files changed, 75 insertions(+), 29 deletions(-) diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c index b4cbf4c..6164bfe 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c @@ -143,6 +143,18 @@ static int cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder, decoder->packet_buffer[et].sample_type = sample_type; decoder->packet_buffer[et].start_addr = elem->st_addr; decoder->packet_buffer[et].end_addr = elem->en_addr; + switch (elem->last_i_type) { + case OCSD_INSTR_BR: + case OCSD_INSTR_BR_INDIRECT: + decoder->packet_buffer[et].last_instruction_is_branch = true; + break; + case OCSD_INSTR_OTHER: + case OCSD_INSTR_ISB: + case OCSD_INSTR_DSB_DMB: + default: + decoder->packet_buffer[et].last_instruction_is_branch = false; + break; + } decoder->packet_buffer[et].exc = false; decoder->packet_buffer[et].exc_ret = false; decoder->packet_buffer[et].cpu = *((int*)inode->priv); diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h index d15a288..4fd5a9b 100644 --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h @@ -49,6 +49,7 @@ struct cs_etm_packet { enum cs_etm_sample_type sample_type; uint64_t start_addr; uint64_t end_addr; + bool last_instruction_is_branch; bool exc; bool exc_ret; int cpu; diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 8270203..c99b728 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -104,6 +104,10 @@ struct cs_etm_queue { * inserted. */ size_t last_branch_pos; + /* + * A pointer to the last and current decoded packets. + */ + struct cs_etm_packet *prev_packet, *packet; }; static int cs_etm__get_trace(struct cs_etm_buffer *buff, struct cs_etm_queue *etmq); @@ -226,6 +230,8 @@ static void cs_etm__free_queue(void *priv) zfree(&etmq->event_buf); zfree(&etmq->last_branch); zfree(&etmq->last_branch_rb); + zfree(&etmq->prev_packet); + zfree(&etmq->packet); zfree(&etmq->chain); free(etmq); } @@ -392,6 +398,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, if (etm->synth_opts.last_branch) { size_t sz = sizeof(struct branch_stack); + size_t szp = sizeof(struct cs_etm_packet); sz += etm->synth_opts.last_branch_sz * sizeof(struct branch_entry); @@ -401,6 +408,12 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, etmq->last_branch_rb = zalloc(sz); if (!etmq->last_branch_rb) goto out_free; + etmq->prev_packet = zalloc(szp); + if (!etmq->prev_packet) + goto out_free; + etmq->packet = zalloc(szp); + if (!etmq->packet) + goto out_free; } etmq->event_buf = malloc(PERF_SAMPLE_MAX_SIZE); @@ -451,6 +464,8 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm, zfree(&etmq->event_buf); zfree(&etmq->last_branch); zfree(&etmq->last_branch_rb); + zfree(&etmq->prev_packet); + zfree(&etmq->packet); zfree(&etmq->chain); free(etmq); return NULL; @@ -594,8 +609,7 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq) etmq->last_branch_rb->nr = 0; } -static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq, - struct cs_etm_packet *packet) +static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq) { struct branch_stack *bs = etmq->last_branch_rb; struct branch_entry *be; @@ -611,10 +625,16 @@ static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq, etmq->last_branch_pos -= 1; - be = &bs->entries[etmq->last_branch_pos]; - be->from = packet->start_addr; - be->to = packet->end_addr; - /* No support for mispredict */ + be = &bs->entries[etmq->last_branch_pos]; + + /* + * The FROM address needs to be the instruction before the end of the + * packet at END_ADDR: substract from END_ADDR the size of the last + * instruction: 4 bytes. + */ + be->from = etmq->prev_packet->end_addr - 4; + be->to = etmq->packet->start_addr; + /* No support for mispredict. */ be->flags.mispred = 0; be->flags.predicted = 1; @@ -721,13 +741,13 @@ static struct cs_etm_cache_entry *cs_etm__cache_lookup(struct dso *dso, } #endif -static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq, - struct cs_etm_packet *packet) +static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq) { int ret = 0; struct cs_etm_auxtrace *etm = etmq->etm; union perf_event *event = etmq->event_buf; struct perf_sample sample = {.ip = 0,}; + struct cs_etm_packet *packet = etmq->packet; uint64_t start_addr = packet->start_addr; uint64_t end_addr = packet->end_addr; @@ -941,17 +961,18 @@ static int cs_etm__synth_events(struct cs_etm_auxtrace *etm, static int cs_etm__sample(struct cs_etm_queue *etmq, int *cpu) { - //const struct cs_etm_state *state = etmq->state; - struct cs_etm_packet packet; - //struct cs_etm_auxtrace *etm = etmq->etm; - int err; + struct cs_etm_auxtrace *etm = etmq->etm; + struct cs_etm_packet *tmp; + int err = cs_etm_decoder__get_packet(etmq->decoder, etmq->packet); - err = cs_etm_decoder__get_packet(etmq->decoder,&packet); - // if there is no sample, it returns err = -1, no real error + /* + * If there is no sample, it returns err = -1, no real error. + */ if (err) return err; - if (etmq->etm->synth_opts.last_branch) { - *cpu = packet.cpu; + + if (etm->synth_opts.last_branch) { + *cpu = etmq->packet->cpu; /* * FIXME: as the trace sampling does not work for now, (for @@ -961,17 +982,30 @@ static int cs_etm__sample(struct cs_etm_queue *etmq, int *cpu) * should be rewritten as "if reached sampling period". */ if (etmq->last_branch_rb->nr == - etmq->etm->synth_opts.last_branch_sz) { - err = cs_etm__synth_instruction_sample(etmq, &packet); + etm->synth_opts.last_branch_sz) { + err = cs_etm__synth_instruction_sample(etmq); if (err) return err; } - cs_etm__update_last_branch_rb(etmq, &packet); - } else if (packet.sample_type & CS_ETM_RANGE) { - err = cs_etm__synth_instruction_sample(etmq,&packet); - if (err) - return err; - } + /* + * Record a branch when the last instruction in PREV_PACKET is a + * branch. + */ + if (etmq->prev_packet->last_instruction_is_branch) + cs_etm__update_last_branch_rb(etmq); + + /* + * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for + * the next incoming packet. + */ + tmp = etmq->packet; + etmq->packet = etmq->prev_packet; + etmq->prev_packet = tmp; + } else if (etmq->packet->sample_type & CS_ETM_RANGE) { + err = cs_etm__synth_instruction_sample(etmq); + if (err) + return err; + } return 0; } @@ -1016,15 +1050,14 @@ static int cs_etm__run_decoder(struct cs_etm_queue *etmq, u64 *timestamp) * buffer at the end of the trace. */ if (etmq->etm->synth_opts.last_branch) { - struct cs_etm_packet packet; struct branch_stack *bs = etmq->last_branch_rb; struct branch_entry *be = &bs->entries[etmq->last_branch_pos]; - packet.cpu = cpu; - packet.start_addr = be->from; - packet.end_addr = be->to; + etmq->packet->cpu = cpu; + etmq->packet->start_addr = be->to; + etmq->packet->end_addr = be->to + 4; - err = cs_etm__synth_instruction_sample(etmq, &packet); + err = cs_etm__synth_instruction_sample(etmq); if (err) return err; } -- 2.7.4

7 years, 3 months

Re: Perf-opencsd-4.9

by Mathieu Poirier

On 14 April 2017 at 16:35, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: > Hello Mathieu > > We have changed the device tree to reflect all CoreSight components on our platform. > Still I do not see any device listed in the following directory > > /sys/bus/coresight/devices > > Am I missing something in Linux 4.9 configuration? I have enabled CONFIG_CORESIGHT in .config. When the system boots AMBA probes for devices connected (and discoverable) on the bus. The first thing to do is make sure the CS devices show up at enumeration time. I suggest instrumenting function amba_device_try_add() [1] to see if CS devices are discovered. If not then it is probably a matter of enabling the debug power domain. While debugging I also suggest to boot with the "nohlt" option or disable CPUidle completely. That way tracers (usually located in the CPU/cluster power domain) are guaranteed to be enabled. If CS devices show up then you will need to instrument the _probe() function of each CS driver to see what makes them unhappy. Mathieu [1]. http://lxr.free-electrons.com/source/drivers/amba/bus.c#L344 > > Regards, Reza > > > -----Original Message----- > From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] > Sent: Friday, March 31, 2017 3:37 PM > To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> > Subject: Re: Perf-opencsd-4.9 > > On 31 March 2017 at 14:32, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >> Thanks Mathieu >> >> I am using Yocto tool chain. So, I have to add --sysroot to both opencsd and tools/perf makefiles. >> If I see more problems, I may have to switch building them on the target. > > Ok, let me know. > > I will be travelling for the next two weeks. As such I may be slow to respond, if at all. While I am away you can always send your questions to "coresight(a)lists.linaro.org". There is a lot of very knowledgeable people on there that can help you. > >> >> Regards, Reza >> >> -----Original Message----- >> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >> Sent: Friday, March 31, 2017 3:27 PM >> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> >> Subject: Re: Perf-opencsd-4.9 >> >> For my own sanity I tried doing the same thing and everything works as advertised. The only difference is that I'm not cross compiling and I have gcc 5.4.0. We know how to fix the gcc 6.2 problem and the cross compilation isn't part of the equation. >> >> For the perf tools I am working with branch perf-openscd-4.9 (b50067a52cf3). On the openCSD side I am using the master branch (054c07caa2eb). >> >> Mathieu >> >> On 31 March 2017 at 13:52, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >>> Thanks Mathieu >>> >>> I am using master branch >>> >>> git clone https://github.com/Linaro/OpenCSD.git my-opencsd >>> git checkout -b master origin/master >>> >>> Is this a correct branch for opencsd? >>> >>> I am cross compiling both opencsd and tools/perf. >>> >>> Regards, Reza >>> >>> -----Original Message----- >>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >>> Sent: Friday, March 31, 2017 2:34 PM >>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> >>> Subject: Re: Perf-opencsd-4.9 >>> >>> On 31 March 2017 at 12:58, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >>>> Hello Mathieu >>>> >>>> >>>> We have taken all the patches. When building tools/perf we get the following compilation errors. >>>> Do you have some ideas if we are missing a patch? >>> >>> The problem comes from mismatches between the kernel and the openCSD version. We try to keep them working for older versions but that can't be guaranteed all the time. >>> >>>> >>>> CC util/parse-events.o >>>> CC util/parse-events-flex.o >>>> CC util/pmu.o >>>> util/cs-etm.c:1282:27: error: ?cs_etm_global_header_fmts? defined >>>> but not used [-Werror=unused-const-variable=] static const char * const cs_etm_global_header_fmts[] = { >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Right, you are building branch 4.9 with a gcc version that is higher than 6.2. We have a patch for that on the 4.11-rc1 branch [1]. >>> >>> [1]. >>> https://github.com/Linaro/OpenCSD/commit/2379238cd554a3445b87ceaa4ef0 >>> 0 >>> 15c5d25c4b3 >>> >>>> CC util/pmu-flex.o >>>> util/cs-etm-decoder/cs-etm-decoder.c: In function ?cs_etm_decoder__gen_trace_elem_printer?: >>>> util/cs-etm-decoder/cs-etm-decoder.c:204:7: error: ?OCSD_GEN_TRC_ELEM_SWTRACE? undeclared (first use in this function) >>>> case OCSD_GEN_TRC_ELEM_SWTRACE: >>>> ^~~~~~~~~~~~~~~~~~~~~~~~~ >>>> util/cs-etm-decoder/cs-etm-decoder.c:204:7: note: each undeclared >>>> identifier is reported only once for each function it appears in >>>> util/cs-etm-decoder/cs-etm-decoder.c:205:7: error: ?OCSD_GEN_TRC_ELEM_CUSTOM? undeclared (first use in this function) >>>> case OCSD_GEN_TRC_ELEM_CUSTOM: >>>> ^~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Those two are related to the openCSD version. What version of the library are you working with? In any case if you stick with the latest revision (0.5.4) or TIP you should be fine. The commits that added these two is here [2]. >>> >>> [2]. >>> https://github.com/Linaro/OpenCSD/commit/885cb935cf04acc3d0afd2bb242b >>> d >>> 9f7328e7104 >>> >>>> mv: cannot stat 'util/cs-etm-decoder/.cs-etm-decoder.o.tmp': No such >>>> file or directory >>>> >>>> Regards, Reza >>>> >>>> >>>> -----Original Message----- >>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >>>> Sent: Thursday, March 30, 2017 10:15 AM >>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> >>>> Subject: Re: Perf-opencsd-4.9 >>>> >>>> On 30 March 2017 at 09:12, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >>>>> Thanks. >>>>> >>>>> Do you have links to these patches? >>>> >>>> It's all there: >>>> https://github.com/Linaro/OpenCSD/commits/perf-opencsd-4.9 >>>> >>>>> >>>>> Regards, Reza >>>>> >>>>> -----Original Message----- >>>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >>>>> Sent: Thursday, March 30, 2017 10:06 AM >>>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> >>>>> Subject: Re: Perf-opencsd-4.9 >>>>> >>>>> On 30 March 2017 at 08:51, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >>>>>> Thanks Mathieu >>>>>> >>>>>> This is an in-house board and we had to do some BSP changes to boot Linux 4.9 on our board. >>>>> >>>>> Ok. >>>>> >>>>>> I just want to make sure that I merge perf-openCSD-4.9 correctly with our source tree. >>>>>> So, are you saying that I only need to replace tool/perf directory? >>>>> >>>>> Simply apply the patches you find on perf-opencsd-4.9, that will make life easier on you. >>>>> >>>>>> >>>>>> Regards, Reza >>>>>> >>>>>> -----Original Message----- >>>>>> From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] >>>>>> Sent: Thursday, March 30, 2017 9:40 AM >>>>>> To: Etemadi, Mohammad <mohammad.etemadi(a)intel.com> >>>>>> Subject: Re: Perf-opencsd-4.9 >>>>>> >>>>>> On 29 March 2017 at 19:47, Etemadi, Mohammad <mohammad.etemadi(a)intel.com> wrote: >>>>>>> Hello Matt >>>>>> >>>>>> Hi there, >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> We have Linux 4.9 running on our ARMv8 platform. I like to try >>>>>>> instruction tracing using perf-opencsd-4.9. >>>>>> >>>>>> Ok, that should be an interesting project. >>>>>> >>>>>>> >>>>>>> I noticed that there is a Linaro Linux source tree for perf-opencsd-4.9. >>>>>>> Looks like this tree consists of base >>>>>>> >>>>>>> Linux kernel 4.9 plus some some additions to support CoreSight >>>>>>> and instruction trace using Perf tool. >>>>>> >>>>>> All the kernel side of the solution is already upstream. What is on gitHub it part of the user space perf tools that haven't been upstreamed yet (we are working on it) and the openCSD decoding library. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> For adding trace functionality, Is it possible to get a patch >>>>>>> that I can apply to my base Linux 4.9? >>>>>> >>>>>> I'm not sure of what you mean by "a patch I can add" - can you rephrase of give me more details? All the patches on top of mainline (on gitHub) should apply cleanly to your tree. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also which files must be changed to reflect specific SOC CoreSight topology? >>>>>> >>>>>> CoreSight is different on every platform, which is why all the platform specific stuff has been pushed to the device tree. Is this a commercial board or something in-house? >>>>>> >>>>>> In the former case support for vexpress[1], juno (R0/1/2)[2] and the dragonboard[3] are already upstream. There is also something for HiKey that I could share with you if need be. If this is an in-house project you will need to make up your own device tree base on the topology you are working with. >>>>>> >>>>>> I'm always interested by what people are doing with CoreSight. Get back to me if you have more questions. >>>>>> >>>>>> Regards, >>>>>> Mathieu >>>>>> >>>>>> [1]. >>>>>> http://lxr.free-electrons.com/source/arch/arm/boot/dts/vexpress-v2 >>>>>> p >>>>>> - >>>>>> c >>>>>> a >>>>>> 15_a7.dts [2]. >>>>>> http://lxr.free-electrons.com/source/arch/arm64/boot/dts/arm/juno- >>>>>> b >>>>>> a >>>>>> s >>>>>> e >>>>>> .dtsi [3]. >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>>> / >>>>>> t >>>>>> r >>>>>> e >>>>>> e/arch/arm64/boot/dts/qcom/msm8916.dtsi?id=refs/tags/v4.11-rc4 >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, Reza

7 years, 5 months

enabling coresight etm on hikey

by Sebastian Pop

Hi, we started looking at how to enable collection of branch traces with coresight etm on the hikey boards that are the reference platform for the android linux-4.9 work. Does somebody from Linaro have access to the description of where the coresight components are located for the hikey devices? We would appreciate help on enabling linux-perf collection of traces on the hikey. Thanks, Sebastian

7 years, 6 months

Re: [PATCH 2/2] perf tools: new inject capabilitity for CoreSight traces

by Kim Phillips

[re-adding cc list, assuming didn't hit reply-all?] On Tue, 14 Mar 2017 19:12:08 +0000 Mike Leach <mike.leach(a)linaro.org> wrote: > On 14 March 2017 at 16:10, Kim Phillips <kim.phillips(a)arm.com> wrote: > > > still results in: > > > > util/cs-etm.c:1466:27: error: ‘cs_etm_global_header_fmts’ defined but not > > used [-Werror=unused-const-variable=] > > static const char * const cs_etm_global_header_fmts[] = { > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > What toolchain and/or version are you using? > > > I'm using a linaro build of gcc 4.9. > > aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.05) 4.9.3 20150413 (prerelease) Linaro appear to have removed that release from their repo: http://releases.linaro.org/components/toolchain/binaries/ So I used this one - which AFAICT is the closest to your version - to cross-build both the kernel with your config, and perf: aarch64-linux-gnu-gcc (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease) Building perf didn't require the patch I sent due to an old gcc bug that apparently finally got fixed recently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 I then ran the resulting kernel (which still had the extra patch, so commit 0d15341 == c50837 + the patch), and perf: root@juno:~# ./perf --version perf version 4.11.rc1.gc50837 root@juno:~# strings -a perf | grep "GCC: (" GCC: (Linaro GCC 4.9-2016.02) 4.9.4 20151028 (prerelease) root@juno:~# dmesg | grep gcc [ 0.000000] Linux version 4.11.0-rc1-g0d15341 (kim@dupont) (gcc version 4.9.4 20151028 (prerelease) (Linaro GCC 4.9-2016.02) ) #3 SMP PREEMPT Tue Mar 14 22:41:34 CDT 2017 root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname [ 870.355660] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 870.362736] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 870.369127] coresight-tmc 20010000.etf: TMC-ETF enabled [ 870.374304] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 870.380698] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled [ 870.387858] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 870.394325] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 870.400806] coresight-tmc 20010000.etf: TMC disabled [ 870.405722] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 870.412184] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 870.419350] coresight-tmc 20070000.etr: TMC-ETR disabled [ 870.425083] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 870.432153] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 870.438542] coresight-tmc 20010000.etf: TMC-ETF enabled [ 870.443718] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 870.450112] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled Linux [ 870.476156] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 870.482625] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 870.489106] coresight-tmc 20010000.etf: TMC disabled [ 870.494023] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 870.500485] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 870.507651] coresight-tmc 20070000.etr: TMC-ETR disabled [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data ] which appears to have worked the first time. Then I tried a second time - literally up-arrow, enter - and got the same exact hard hang as I get with the modern compilers the first time: root@juno:~# taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u --per-thread taskset -c 2 uname [ 1965.355162] coresight-replicator-qcom 20120000.replicator: REPLICATOR enabled [ 1965.362238] coresight-funnel 20150000.funnel: FUNNEL inport 0 enabled [ 1965.368629] coresight-tmc 20010000.etf: TMC-ETF enabled [ 1965.373807] coresight-funnel 20040000.funnel: FUNNEL inport 0 enabled [ 1965.380201] coresight-funnel 220c0000.funnel: FUNNEL inport 1 enabled Linux [ 1965.405984] coresight-funnel 220c0000.funnel: FUNNEL inport 1 disabled [ 1965.412453] coresight-funnel 20040000.funnel: FUNNEL inport 0 disabled [ 1965.418934] coresight-tmc 20010000.etf: TMC disabled [ 1965.423850] coresight-funnel 20150000.funnel: FUNNEL inport 0 disabled [ 1965.430312] coresight-replicator-qcom 20120000.replicator: REPLICATOR disabled [ 1965.437478] coresight-tmc 20070000.etr: TMC-ETR disabled [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote which is along the same instability lines as the other time that execution behaviour differed depending on whether it executed first or not... > > > > $ sudo taskset -c 2 ./perf record -e cs_etm/(a)20070000.etr/u > > --per-thread > > > taskset -c 2 uname > > > > failed to mmap with 12 (Cannot allocate memory) > > > > > > That said I get this too if I do enable sinks. However as you say after > > the > > > initial attempt the problem disappears. > > > > Right, at least we have one problem reproduced on both sides now. ...here. > > It hung before completing that last sentence. > > > > Perhaps the bug is exasperated by toolchain and/or host and target > > rootfs distribution differences? My juno target runs debian, and I > > recently upgraded to stretch in order to get a version of gcc that > > would support autoFDO. > > My juno is has a debian-jessie-developer root-fs from > http://releases.linaro.org/debian/images/developer-arm64/16.04/ > At present I cannot build autofdo - I still have some package issues, but > for perf and the kernel I am x-compiling on my ubuntu VM anyway, so the > installed compilers have no effect on the perf runs,. OK, can you try a more modern toolchain please? The one you're using isn't available anymore, AutoFDO requires gcc 5 and higher, and you're not seeing the build failures others see, but most importantly, it should make it easier to reproduce the hard lockup: at least that's the case on the Juno r2. Thanks, Kim

7 years, 7 months

Coresight ETM/STM trace

by Abhijit Dongre

Hi, We are running Coresight testcases in RTL simulation, and intend to decode the trace stored in ETF and Memory(through ETR). Came across OpenCSD library, Can this library be used in decoding of trace in RTL simulation? Note that in RTL simulations we don't use Linux and heavy software, we use bare minimum startup code for booting. If decoding is possible, please let us know procedure and pricing if any. Regards, Abhijit

7 years, 7 months

RE: Fr : CSAL library

by Mike Leach

Hi Karim, The CSAL library contains a number of readme files that should guide you in setting up your system for use with the library, plus a number of example applications. Start with the main README.md file in the root project directory. Run doxygen on the doxygen-config.txt file to build the library documentation - this will include all the readme files mentioned below. CSAL uses memory mapped IO to access the CoreSight components in linux, see readme_demos.md for further information. This file also contains instructions for setting up the library for specific platforms and running under linux. The first task is to create a registration function for your platform - look at the cs_demo_known_boards.c file. From there you should be able build the example programs. Csls is useful to use first as it will simply list the CoreSight components - which will verify if you have configured your system and the library correctly. Regards Mike > -----Original Message----- > From: Karim Lamouchi [mailto:lamouchi_karim@yahoo.fr] > Sent: 07 May 2017 11:27 > To: Mike Leach > Subject: Fr : CSAL library > > > Hello Mike, > > I'm trying to test CSAL library(coresight access library) under linux in > order to access and configure the arm coresight IP block within a new platform > based on 2 core A7 and 1 cortex M4. > In fact I want to extract the generated traces (without using an external > hardware) in order to decode them in the next step using the opencsd library . > > Could you please give me more details about how to use the CSAL > library and the differents steps that allow me to support it with the new > platform ? > > Is it possible to use this library without DS5? > > It is helpful to send me if you have any documents about this library. > > best regards, > Karim. 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.

7 years, 7 months

Re: CSAL library

by Mathieu Poirier

Hi Karim, I haven't worked with the CSAL for very long time and it is not something I can help you with. Mike may know someone who can... Thanks, Mathieu On 6 May 2017 at 10:33, Karim Lamouchi <lamouchi_karim(a)yahoo.fr> wrote: > Hello Mathieu, > > I'm trying to test CSAL library(coresight access library) under linux in > order to access and configure the arm coresight IP block within a new > platform based on 2 core A7 and 1 cortex M4. > Could you please give me more details about how to use this library and the > differents steps that allow me to support it with the new platform ? > It is helpful to send me if you have any documents about this library. > > best regards, > Karim.

7 years, 7 months

[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

7 years, 7 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight May 2017