=> Of course, there are 30 patches on top of kernel 4.9. 20 patches is relative to tools/perf. Because I use perf in opencsd-4.9, I don't need to apply it.

Title : Re: FW: RE: Re: FW: Re: Question for openCSD - open soruce Coresight Trace Decode

On 15 September 2017 at 00:22, 임영재 <youngjae24.lim@samsung.com> wrote:

Hello Mike.

I wonder whether opencsd-perf-4.9 supports injection of branch stack or not.

Thank you.

--------- Original Message ---------

Sender : 임영재 <youngjae24.lim@samsung.com> Senior Engineer/System S/W개발2그룹(무선)/삼성전자

Date : 2017-09-15 14:32 (GMT+9)

Title : RE: Re: FW: Re: Question for openCSD - open soruce Coresight Trace Decode

Hello Mike,

I cannot build a kernel using opencsd-perf-4.13.

My project has kernel version 4.9.

I don't want to change kernel version.

So, I just want to apply patches of coresight drvier in opencsd-perf-4.9.

I applyed pathes of coresight like below.

But, ETR didn't have normal operation.

You will have to give us more information than simply it "doesn't work".

Also, on gitHub I see close to 30 patches on top of kernel 4.9, where below you have only 10. Please add all the patches so that your environment is as close to ours.

0001-coresight-stm-return-error-code-instead-of-zero-in-..patch
0002-coresight-etm3x-indentation-fix-extra-space-removed.patch
0003-coresight-etm3x-Adding-missing-features-of-Coresight.patch
0004-coresight-reset-enable_sink-flag-when-need-be.patch
0005-coresight-tmc-Cleanup-operation-mode-handling.patch
0006-coresight-tmc-Get-rid-of-mode-parameter-for-helper-r.patch
0007-coresight-tmc-Remove-duplicate-memset.patch
0008-coresight-Add-support-for-ARM-Coresight-STM-500.patch
0009-coresight-perf-Add-a-missing-call-to-etm_free_aux.patch
0010-coresight-tmc-implementing-TMC-ETR-AUX-space-API.patch

--------- Original Message ---------

Sender : Mike Leach <mike.leach@linaro.org>

Date : 2017-09-13 19:37 (GMT+9)

Title : Re: FW: Re: Question for openCSD - open soruce Coresight Trace Decode

Hello Youngkae Lim,

V8A cores should not be producing the conditional packets mentioned earlier in this e-mail. Please build a kernel using the opencsd-perf-4.13 or opencsd-perf-master branches which contain the latest CoreSight drivers.

I cannot comment on the inject issue - Sebastian may be of more help here. There are two additional patches submitted to this list which are not integrated into the opencsd-perf branches. Please add these patches before building perf because they correct some issues.

Best Regards

Mike
On 13 September 2017 at 08:38, 임영재 <youngjae24.lim@samsung.com> wrote:
Dear. Mike Leach.

My cores are v8-a cores.

Perf datas that I gathered don't include unsupported packet.

But, injection is failed below.

0 0 0x1158 [0x40]: PERF_RECORD_FORK(2:2):(0:0)

0x1198 [0x40]: event: 3
.
. ... raw event: size 64 bytes
...skipping...
... branch stack: nr:0
... thread: :-1:-1
...... dso: <not found>

Best regards.

Youngjae Lim

--------- Original Message ---------

Sender : Mike Leach <mike.leach@linaro.org>

Date : 2017-09-05 01:14 (GMT+9)

Title : Re: Question for openCSD - open soruce Coresight Trace Decode
Hi Sebastian and Youngjae.


The decoder does not support at present the packet types for tracing
of Conditional non-branches (i.e. the /* conditional instruction
tracing */ block above).
Looking at the TRCIDR0 for each core from the perf dump above, the
cores in this system do not support conditional instruction tracing,
so these packets should never be seen.
Architecturally it is not permitted in ETMv4 for A class cores to
trace conditional none branch instructions, so these values should
never be seen on any A class trace output.

Can you confirm that these cores are in fact v7-A or v8-A cores?

These unsupported packets can be due to perf concatenating wrapped
trace data into a single buffer which throws out the decoder. The
latest drivers in the opencsd-perf-master branch insert barrier
packets to overcome this issue. Can you confirm that the kernel you
are using uses the latest driver set?

Conditional instruction trace of none-branches is associated with data
trace - this is only permitted on R and M class cores, if implemented
at all.

Regarding the change above - I agree this is a good change. I can make
it myself or you can send a patch - either works for me.

Regards

Mike


On 1 September 2017 at 15:23, Sebastian Pop <sebpop@gmail.com> wrote:
> The next problem that I see is an unhandled packet in
> decoder/source/etmv4/trc_pkt_decode_etmv4i.cpp:
> TrcPktDecodeEtmV4I::decodePacket()
>
> (gdb) p m_curr_packet_in->getType()
> $267 = ETM4_PKT_I_COND_RES_F1
>
>     /*** presently unsupported packets ***/
>     /* conditional instruction tracing */
>     case ETM4_PKT_I_COND_FLUSH:
>     case ETM4_PKT_I_COND_I_F1:
>     case ETM4_PKT_I_COND_I_F2:
>     case ETM4_PKT_I_COND_I_F3:
>     case ETM4_PKT_I_COND_RES_F1:
>     case ETM4_PKT_I_COND_RES_F2:
>     case ETM4_PKT_I_COND_RES_F3:
>     case ETM4_PKT_I_COND_RES_F4:
>     // speculation
>     case ETM4_PKT_I_CANCEL_F1:
>     case ETM4_PKT_I_CANCEL_F2:
>     case ETM4_PKT_I_CANCEL_F3:
>     case ETM4_PKT_I_COMMIT:
>     case ETM4_PKT_I_MISPREDICT:
>     case ETM4_PKT_I_DISCARD:
>     // data synchronisation markers
>     case ETM4_PKT_I_NUM_DS_MKR:
>     case ETM4_PKT_I_UNNUM_DS_MKR:
>     /* Q packets */
>     case ETM4_PKT_I_Q:
>         resp = OCSD_RESP_FATAL_INVALID_DATA;
>
> LogError(ocsdError(OCSD_ERR_SEV_ERROR,OCSD_ERR_BAD_DECODE_PKT,"Unsupported
> packet type."));
>         break;
>
>



-- 
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK
--

Mike Leach

Principal Engineer, ARM Ltd.

Blackburn Design Centre. UK