Hello.
I provide a pastebin of the command.
Is branch stack nr 0 because the address is Kernel address area?
./perf record -e cpu-clock -e cs_etm/timestamp,cycacc,@1e005000.etf1/ -C 0 --per-thread taskset 1 ./sort_o2_arm64_f
./perf report
# Samples: 20K of event 'cpu-clock'
# Event count (approx.): 5231750000
#
# Children Self Command Shared Object Symbol
# ........ ........ ............... ................ ......................
#
26.07% 26.07% sort_o2_arm64_f sort_o2_arm64_f [.] 0x000000000000084c
16.92% 16.92% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000860
12.81% 12.81% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000848
10.59% 10.59% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000868
9.87% 9.87% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000854
4.63% 4.63% sort_o2_arm64_f [unknown] [k] 0xffffff8008cef5a4
4.12% 4.12% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000844
2.19% 2.19% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000864
2.13% 2.13% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000850
1.97% 1.97% sort_o2_arm64_f sort_o2_arm64_f [.] 0x000000000000085c
1.68% 1.68% swapper [unknown] [k] 0xffffff80088e5028
1.43% 1.43% migration/0 [unknown] [k] 0xffffff8008cef60c
1.14% 1.14% sort_o2_arm64_f sort_o2_arm64_f [.] 0x0000000000000858
0.76% 0.76% sort_o2_arm64_f [unknown] [k] 0xffffff8008cef60c
0.30% 0.30% migration/0 [unknown] [k] 0xffffff8008cef5a4
0.18% 0.18% sort_o2_arm64_f [unknown] [k] 0xffffff80081fdf34
0.14% 0.14% kworker/0:0 [unknown] [k] 0xffffff80080c4254
0.12% 0.12% kworker/0:0 [unknown] [k] 0xffffff8008b18e10
0.11% 0.11% kworker/0:0 [unknown] [k] 0xffffff8008cef60c
0.09% 0.09% kworker/0:0 [unknown] [k] 0xffffff80080c1b18
0.09% 0.09% perf [unknown] [k] 0xffffff8008cef5a4
0.09% 0.09% sort_o2_arm64_f [unknown] [k] 0xffffff80081307e4
0.07% 0.07% sort_o2_arm64_f [unknown] [k] 0xffffff8008130b78
0.06% 0.06% swapper [unknown] [k] 0xffffff8008cef5a4
0.06% 0.06% swapper [unknown] [k] 0xffffff8008cef60c
0.05% 0.05% sort_o2_arm64_f [unknown] [k] 0xffffff80084988c0
0.04% 0.04% swapper [unknown] [k] 0xffffff800814b28c
0.03% 0.03% kworker/0:0 [unknown] [k] 0xffffff8008116424
0.03% 0.03% sort_o2_arm64_f [unknown] [k] 0xffffff8008130900
./perf report --dump
0x200 [0x70]: PERF_RECORD_AUXTRACE_INFO type: 3
Header version 0
PMU type/num cpus 30064771073
Snapshot 0
Magic number 4629771061636907072
CPU 0
TRCCONFIGR 268439552
TRCTRACEIDR 16
TRCIDR0 671092385
TRCIDR1 1090581537
TRCIDR2 536875144
TRCIDR8 0
TRCAUTHSTATUS 204
0x2015f0 [0x30]: PERF_RECORD_AUXTRACE size: 0x1a0 offset: 0 ref: 0x39b8bc316c2bd0ba idx: 0 tid: -1 cpu: 0
. ... CoreSight ETM Trace data: size 416 bytes
0: id[10] I_ASYNC : Alignment Synchronisation.
12: id[10] I_TRACE_INFO : Trace Info.; INFO=0x0
17: id[10] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000;
26: id[10] I_TRACE_ON : Trace On.
27: id[10] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFFFF80089B25F0; Ctxt: AArch64,EL1, NS;
38: id[10] I_ATOM_F1 : Atom format 1.; E
39: id[10] I_TIMESTAMP : Timestamp.; Updated val = 0x3151491ca55
50: id[10] I_ATOM_F1 : Atom format 1.; E
51: id[10] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF80089B58C0;
60: id[10] I_ATOM_F3 : Atom format 3.; EEE
61: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B5F54 ~[0x15F54]
65: id[10] I_ATOM_F2 : Atom format 2.; EE
66: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B29C8 ~[0x129C8]
69: id[10] I_ATOM_F2 : Atom format 2.; NE
70: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B2DE0 ~[0x12DE0]
73: id[10] I_ATOM_F2 : Atom format 2.; EE
74: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A9C4C;
80: id[10] I_ATOM_F3 : Atom format 3.; EEN
81: id[10] I_ATOM_F3 : Atom format 3.; EEE
82: id[10] I_ATOM_F1 : Atom format 1.; E
83: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80083F4D8C;
88: id[10] I_ATOM_F1 : Atom format 1.; E
89: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A9CA0;
94: id[10] I_ATOM_F6 : Atom format 6.; EEEEEN
96: id[10] I_ATOM_F2 : Atom format 2.; EE
97: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80081A9CE4 ~[0xE4]
99: id[10] I_ATOM_F6 : Atom format 6.; EEEEEEE
100: id[10] I_ADDR_MATCH : Exact Address Match., [2]; Addr=0xFFFFFF80083F4D8C;
101: id[10] I_ATOM_F1 : Atom format 1.; E
102: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A596C;
107: id[10] I_ATOM_F2 : Atom format 2.; NE
108: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF800819FD64;
114: id[10] I_ATOM_F1 : Atom format 1.; E
115: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A5994;
120: id[10] I_ATOM_F1 : Atom format 1.; E
121: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80081A9D1C ~[0x9D1C]
124: id[10] I_ATOM_F2 : Atom format 2.; EE
125: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80081A9DA0 ~[0x1A0]
128: id[10] I_ATOM_F3 : Atom format 3.; NEE
129: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF800819FD6C;
134: id[10] I_ATOM_F1 : Atom format 1.; E
135: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A9DE4;
140: id[10] I_ATOM_F3 : Atom format 3.; EEE
141: id[10] I_RESERVED : Reserved Packet Header
144: id[10] I_ATOM_F3 : Atom format 3.; EEE
145: id[10] I_TIMESTAMP : Timestamp.; Updated val = 0x31514968100
149: id[10] I_ATOM_F2 : Atom format 2.; EE
150: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80081A9DC4 ~[0x1C4]
152: id[10] I_TIMESTAMP : Timestamp.; Updated val = 0x31514968d00
176: id[10] I_ASYNC : Alignment Synchronisation.
188: id[10] I_TRACE_INFO : Trace Info.; INFO=0x0
193: id[10] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF80089B59C4;
202: id[10] I_TRACE_ON : Trace On.
203: id[10] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFFFF80089B25F0; Ctxt: AArch64,EL1, NS;
214: id[10] I_ATOM_F1 : Atom format 1.; E
215: id[10] I_TIMESTAMP : Timestamp.; Updated val = 0x31514e93200
226: id[10] I_ATOM_F1 : Atom format 1.; E
227: id[10] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF80089B58C0;
236: id[10] I_ATOM_F3 : Atom format 3.; EEE
237: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B5F54 ~[0x15F54]
241: id[10] I_ATOM_F2 : Atom format 2.; EE
242: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B29C8 ~[0x129C8]
245: id[10] I_ATOM_F2 : Atom format 2.; NE
246: id[10] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFFFF80089B2DE0 ~[0x12DE0]
249: id[10] I_ATOM_F2 : Atom format 2.; EE
250: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A9C4C;
256: id[10] I_ATOM_F3 : Atom format 3.; EEN
257: id[10] I_ATOM_F3 : Atom format 3.; EEE
258: id[10] I_ATOM_F1 : Atom format 1.; E
259: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80083F4D8C;
264: id[10] I_ATOM_F1 : Atom format 1.; E
265: id[10] I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xFFFFFF80081A9CA0;
270: id[10] I_ATOM_F6 : Atom format 6.; EEEEEN
272: id[10] I_ATOM_F2 : Atom format 2.; EE
--------- Original Message ---------
Sender : Mathieu Poirier <mathieu.poirier@linaro.org>
Date : 2017-10-02 23:41 (GMT+9)
Title : Re: Question for openCSD - open soruce Coresight Trace Decode
Hello.
I backported 4.13 coresight driver to my kernel to use the latest CoreSight drivers.
I checked whether issues that I mentioned is resolved or not.
1. ETR issue
>You will have to give us more information than simply it "doesn't work".>There are 2 problems.>First, etr driver don't support 64bit physical address. My model has 64bit physical address.=> This issue was resolved.
2. ETR issue
> I saw auxtrace data area is all 0.
> Maybe I think the problem occured during copying from etr dma buffer area to mmaped memory> 0x29c8b8 [0x30]: PERF_RECORD_AUXTRACE size: 0x122d30 offset: 0x29abe0 ref: 0x68d3ed7647ee5271 idx: 0 tid: 12108 cpu: -1> . ... CoreSight ETM Trace data: size 1191216 bytes=> I execute like below.
./perf record -e cs_etm/timestamp,cycacc,@
1e00a000.etr/u --per-thread taskset 1 unameBut, I got the same result. I saw auxtrace data area is all 0.
3. injection issue
> 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>=> I execute like below.
./perf record -e cs_etm/timestamp,cycacc,@
1e005000.etf1/u -C 0 --per-thread taskset 1 unameI got the same result. I got 0 in branch stack nr.
I debugged it to give information.
Branch stack nr is 0 because decoder->packet_count is 0.
The perf data must include OCSD_GEN_TRC_ELEM_INSTR_RANGE to get packt_count.
But my perf data includes OCSD_GEN_TRC_ELEM_ADDR_NACC.
Can you explain about this situation?
Thank you.
Best Regard
Youngjae
--------- Original Message ---------
Sender : Mathieu Poirier <mathieu.poirier@
linaro.org >Date : 2017-09-23 00:13 (GMT+9)
Title : Re: Re: FW: RE: Re: FW: Re: Question for openCSD - open soruce Coresight Trace Decode
On 22 September 2017 at 03:10, 임영재 <youngjae24.lim@samsung.com> wrote:
Hello .Mathieu Poirier
>You will have to give us more information than simply it "doesn't work".=> There are 2 problems.First, etr driver don't support 64bit physical address. My model has 64bit physical address.Below code, there is problem.writel_relaxed(drvdata->paddr, drvdata->base + TMC_DBALO);
writel_relaxed(0x0, drvdata->base + TMC_DBAHI);Suzuki wrote a patchset to fix that. On github, branch perf-opencsd-4.13:98b62f69c4af coresight: Add support for Coresight SoC 600 componentsc9b590717a3a coresight tmc: Add support for Coresight SoC 600 TMC29f38854110e coresight tmc: Support for save-restore in ETR0863f7b1f278 coresight tmc etr: Setup AXI cache encoding for read transfersf7bab28b7f16 coresight tmc etr: Cleanup AXICTL register handlingd81598f029b5 coresight tmc etr: Detect address width at runtime3c97c4f2566a coresight tmc: Detect support for scatter gatherca684de0ba58 coresight tmc etr: Add capabilitiy informationb8b9228d7160 coresight tmc: Handle configuration types properlycc442642fcf5 coresight replicator: Expose replicator management registers16c65a29684e coresight tmc: Expose DBA and AXICTL560c49a5aa57 coresight tmc: Add helpers for accessing 64bit registersI suggest you backport the relevant bit to your kernel 4.9.Anyway, I fixed it like below.drivers/base/dma-contiguous.c+static phys_addr_t size_cmdline = 0x1400000;
+static phys_addr_t base_cmdline = 0xE8000000;
+static phys_addr_t limit_cmdline = 0xE8000000+0x1400000;I checked rrp of etr. it's ok.And I tried to read etr dma buffer area. Etm information was saved normally.Second, I recorded etm information using perf like below.echo 1 > /sys/devices/platform/1e00a000.etr/1e00a000.etr/enable_sink The above is not required../perf record -e cs_etm/timestamp,cycacc,@1e00a
000.etr/u --per-thread taskset 1 unameI checked the dump like below../perf report --stdio --dumpI saw auxtrace data area is all 0.Things look good - everything seems to be in order. There isn't much else I can do here... Things do work on both reference platform (DB401c and Juno).I always tell people in your situation to get a DB410c and see where the discrepancies are. Clocks could be an issue but I'm just guessing here.Maybe I think the problem occured during copying from etr dma buffer area to mmaped memory0x29c8b8 [0x30]: PERF_RECORD_AUXTRACE size: 0x122d30 offset: 0x29abe0 ref: 0x68d3ed7647ee5271 idx: 0 tid: 12108 cpu: -1. ... CoreSight ETM Trace data: size 1191216 bytes>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.=> 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.
Anyway, I compared my kernel source with opencsd-perf-4.9. It is the same..
b50067a cs-etm: Update to perf cs-etm decoder for OpenCSD v0.5
tools/perf/util/cs-etm-decoder /cs-etm-decoder.c | 2 ++
2308063 cs-etm: fixing map__load() parametertools/perf/util/cs-etm.c | 2 +-
ae6ba28 cs-etm: Update to perf cs-etm decode for OpenCSD v0.4tools/perf/util/cs-etm-decoder /cs-etm-decoder.c | 30 +++++++++++++++++------
29ff0bf perf scripts: Fixing file name extensiontools/perf/scripts/python/cs-t race-disasm.py | 2 +-
9074ff4 perf scripts: Fix binary filename and pathtools/perf/scripts/python/cs-t race-disasm.py | 12 +++++++++++-
5f5c594 cs-etm: Update to cs-etm-decoder to handle new packet type from OpenCSD. tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 6 +-----
a02ed95 cs-etm: associating output packet with CPU they executed ontools/perf/...
9e34dee cs-etm: removing unecessary structure fieldtools/perf/util/cs-etm.c | 10 +---------
677a287 cs-etm: account for each trace buffer in the queuetools/perf/util/cs-etm.c | 17 +++++++++--------
593a948 cs-etm: avoid casting variabletools/perf/util/cs-etm.c | 6 ++++--
26cee10 cs-etm: fixing uninitialised cpumodetools/perf/util/cs-etm.c | 1 +
328948b perf tools: fixing Makefile problemstools/perf/Makefile.config | 4 ++--
73d4294 perf tools: new naming convention for openCSDtools/perf/util/cs-etm-decoder /cs-etm-decoder.c | 138 ++++++++++++-----------
451ca19 perf scripts: Add python scripts for CoreSight tracestools/perf/scripts/python/...
8f510fb perf tools: decoding capabilitity for CoreSight tracestools/perf/ ..
b5d782e perf symbols: Check before overwriting build_idtools/perf/...
dad8531 coresight: updating documentation to reflect integration with perfDocumentation/trace/coresight .txt | 138 ++++++++++++++++++++++++++++++ +++----
ea817df coresight: tmc: implementing TMC-ETR AUX space APIdrivers/hwtracing/coresight/c oresight-tmc-etr.c | 243 +++++++++++++++++++++++
0a189e4 perf tools: Removing miscellaneous debug outputtools/perf/arch/arm/util/cs-e tm.c | 2 --
285fb22 coresight: perf: Add a missing call to etm_free_auxdrivers/hwtracing/coresight/co resight-etm-perf.c | 2 +-
3bfa9ae coresight: Add support for ARM Coresight STM-500drivers/hwtracing/coresight/co resight-stm.c | 5 +++++
8044597 coresight: tmc: Remove duplicate memsetdrivers/hwtracing/coresight/co resight-tmc-etr.c | 2 --
63c0930 coresight: tmc: Get rid of mode parameter for helper routinesdrivers/hwtracing/coresight/. ..
034cd3a coresight: tmc: Cleanup operation mode handlingdrivers/hwtracing/coresight/.. .
2866655 coresight: reset "enable_sink" flag when need bedrivers/hwtracing/coresight/
4cba396 coresight: etm3x: Adding missing features of Coresight PTM components.../hwtracing/coresight/...
6f6514b coresight: etm3x: indentation fix (extra space removed).../hwtracing/coresight/cores ight-etm3x-sysfs.c | 2 +-
d3167d3 coresight: stm: return error code instead of zero in .packet()drivers/hwtracing/coresight/co resight-stm.c | 4 ++--
--------- Original Message ---------
Sender : Mathieu Poirier <mathieu.poirier@linar
o.org >Date : 2017-09-16 01:09 (GMT+9)
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.co
m > 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-erro
r-code-instead-of-zero-in-..pa tch
0002-coresight-etm3x-indentation-fix-extra-space-removed.pat ch
0003-coresight-etm3x-Adding-missing-features-of-Coresight.pa tch
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.pa tch
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 RegardsMike
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::decodePack et() > > (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_SE V_ERROR,OCSD_ERR_BAD_DECODE_PK T,"Unsupported > packet type.")); > break; > > -- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
--
Mike LeachPrincipal Engineer, ARM Ltd.Blackburn Design Centre. UK
|
|