On 28 August 2017 at 01:29, 임영재 youngjae24.lim@samsung.com wrote:
Hello.
My name is youngjae
I am enabling coresight to gather perf information through coresight.
I have some techincal problem.
I need a help.
My device has Kernel version - 4.9.39
I did it as below.
I cloned 4.9 version in Linaro opencsd git
git clone https://github.com/Linaro/OpenCSD.git
git checkout origin/perf-opencsd-4.9
I complied perf tool using NDK
After pushing the perf tool into the device, I obtained perf.data
echo 1 > /sys/devices/platform/1e005000.etf1/1e005000.etf1/enable_sink
./perf record -e cs_etm/timestamp,cycacc,@1e005000.etf1/u -C 0-3 -o perf_etf1.data --per-thread taskset f uname
echo 1 > /sys/devices/platform/1e004000.etf0/1e004000.etf0/enable_sink
./perf record -e cs_etm/timestamp,cycacc,@1e004000.etf0/u -C 4-7 -o perf_etf0.data --per-thread taskset f0 uname
I compiled openCSD library and off target perf tool.
I saw CoreSight ETM Trace data using perf report
. ... CoreSight ETM Trace data: size 2560 bytes
0: I_ASYNC : Alignment Synchronisation. 12: I_TRACE_INFO : Trace Info.; INFO=0x0 17: I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF8008961430; 26: I_ASYNC : Alignment Synchronisation. 40: I_TRACE_INFO : Trace Info.; INFO=0x0 43: I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF8008961904;
- I injected it as below
./perf inject --I perf_etf1.data --o inj_etf1.data --itrace=il64 –strip
=> Success. But, after executing perf report, I got below error.
Error: Selected -b but no branch data. Did you call perf record without -b? # To display the perf.data header info, please use --header/--header-only options.
Sebastian, can you help us here?
After compling higher perf tool - v4.12, I checked below fact. It shows nr of branch stack is 0.
0 18446744073709551615 0x99658 [0x38]: PERF_RECORD_SAMPLE(IP, 0x2): -1/-1: 0 period: 0 addr: 0 ... branch stack: nr:0 ... thread: :-1:-1 ...... dso: <not found>
I don't know what the reason is.
Could you help me?
etm configuration problem?
./perf inject --I perf_etf0.data --o inj_etf0.data --itrace=il64 –strip
=> Fail. I checked the problem. TRCIDR8 of ETM of core4 ~ core7 is 6.
This means max speculation depth. OpenCSD doesn't support max speculation depth.
So, we cannot use ETM of core4 ~ core7. Do you know when openCSD support max speculation depth?
If openCSD cannot support max speculation depth, we cannot gather etm information of core4 ~ core7.
My question is two.
What should I do to get nr of branch stack?
Who knows when openCSD will support max speculation depth?
Thank you.
Best Regards
Youngjae.
- etm information
0x1a8 [0x148]: PERF_RECORD_AUXTRACE_INFO type: 3 Header version 0 PMU type/num cpus 30064771076 Snapshot 0 Magic number 4629771061636907072 CPU 0 TRCCONFIGR 268439552 TRCTRACEIDR 16 TRCIDR0 671092385 TRCIDR1 1090581536 TRCIDR2 536875144 TRCIDR8 0 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 1 TRCCONFIGR 268439552 TRCTRACEIDR 18 TRCIDR0 671092385 TRCIDR1 1090581536 TRCIDR2 536875144 TRCIDR8 0 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 2 TRCCONFIGR 268439552 TRCTRACEIDR 20 TRCIDR0 671092385 TRCIDR1 1090581536 TRCIDR2 536875144 TRCIDR8 0 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 3 TRCCONFIGR 268439552 TRCTRACEIDR 22 TRCIDR0 671092385 TRCIDR1 1090581536 TRCIDR2 536875144 TRCIDR8 0 TRCAUTHSTATUS 204 Header version 0 PMU type/num cpus 30064771076 Snapshot 0 Magic number 4629771061636907072 CPU 4 TRCCONFIGR 268439552 TRCTRACEIDR 24 TRCIDR0 134220961 TRCIDR1 1392571392 TRCIDR2 268436616 TRCIDR8 6 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 5 TRCCONFIGR 268439552 TRCTRACEIDR 26 TRCIDR0 134220961 TRCIDR1 1392571392 TRCIDR2 268436616 TRCIDR8 6 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 6 TRCCONFIGR 268439552 TRCTRACEIDR 28 TRCIDR0 134220961 TRCIDR1 1392571392 TRCIDR2 268436616 TRCIDR8 6 TRCAUTHSTATUS 204 Magic number 4629771061636907072 CPU 7 TRCCONFIGR 268439552 TRCTRACEIDR 30 TRCIDR0 134220961 TRCIDR1 1392571392 TRCIDR2 268436616 TRCIDR8 6 TRCAUTHSTATUS 204
perf report --dump --stdio
. ... CoreSight ETM Trace data: size 2560 bytes 0: I_ASYNC : Alignment Synchronisation. 12: I_TRACE_INFO : Trace Info.; INFO=0x0 17: I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF8008961430; 26: I_ASYNC : Alignment Synchronisation. 40: I_TRACE_INFO : Trace Info.; INFO=0x0 43: I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFFF8008961904; 52: I_ATOM_F3 : Atom format 3.; NEN 53: I_ATOM_F3 : Atom format 3.; NNE 54: I_ATOM_F3 : Atom format 3.; NNN 55: I_ATOM_F3 : Atom format 3.; ENN 56: I_ATOM_F5 : Atom format 5.; NENEN 57: I_ATOM_F5 : Atom format 5.; ENENE 58: I_ATOM_F5 : Atom format 5.; NENEN 59: I_ATOM_F5 : Atom format 5.; ENENE 60: I_ATOM_F3 : Atom format 3.; NEN 64: I_ATOM_F3 : Atom format 3.; NNE 65: I_ATOM_F3 : Atom format 3.; NNN 66: I_ATOM_F3 : Atom format 3.; ENN 67: I_ATOM_F3 : Atom format 3.; NEN 68: I_ATOM_F3 : Atom format 3.; NNE 69: I_ATOM_F5 : Atom format 5.; NENEN 70: I_ATOM_F3 : Atom format 3.; NNE 71: I_ATOM_F5 : Atom format 5.; NENEN 72: I_ATOM_F5 : Atom format 5.; ENENE 73: I_ATOM_F5 : Atom format 5.; NENEN 74: I_ATOM_F5 : Atom format 5.; ENENE 75: I_ATOM_F5 : Atom format 5.; NENEN 76: I_ATOM_F5 : Atom format 5.; ENENE 77: I_ATOM_F3 : Atom format 3.; NEN 78: I_ATOM_F3 : Atom format 3.; NNE 80: I_ATOM_F5 : Atom format 5.; NENEN 81: I_ATOM_F5 : Atom format 5.; ENENE 82: I_ATOM_F5 : Atom format 5.; NENEN 83: I_ATOM_F5 : Atom format 5.; ENENE 84: I_ATOM_F5 : Atom format 5.; NENEN 85: I_ATOM_F5 : Atom format 5.; ENENE 86: I_ATOM_F5 : Atom format 5.; NENEN 87: I_ATOM_F3 : Atom format 3.; NNE 88: I_ATOM_F5 : Atom format 5.; NENEN 89: I_ATOM_F5 : Atom format 5.; ENENE 90: I_ATOM_F3 : Atom format 3.; NEN 91: I_ATOM_F3 : Atom format 3.; NNE 92: I_ATOM_F5 : Atom format 5.; NENEN 93: I_ATOM_F5 : Atom format 5.; ENENE 94: I_ATOM_F3 : Atom format 3.; NEN 96: I_ATOM_F3 : Atom format 3.; NNE 97: I_ATOM_F3 : Atom format 3.; NEN 98: I_ATOM_F3 : Atom format 3.; NNE 99: I_ATOM_F3 : Atom format 3.; NEE 100: I_ATOM_F4 : Atom format 4.; NNNN 101: I_ATOM_F6 : Atom format 6.; EEEN 102: I_ATOM_F3 : Atom format 3.; NNE 103: I_ATOM_F1 : Atom format 1.; E 104: I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000076F64A1B50; 114: I_ATOM_F2 : Atom format 2.; EE 115: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF65EE2C0; 120: I_ATOM_F2 : Atom format 2.; NE 121: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF67DD370; 126: I_ATOM_F2 : Atom format 2.; NE 128: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF67DD390 ~[0x190] 130: I_ATOM_F3 : Atom format 3.; ENN 131: I_ATOM_F2 : Atom format 2.; NE 132: I_TIMESTAMP : Timestamp.; Updated val = 0xf6000 136: I_ATOM_F1 : Atom format 1.; E 137: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF64A1B94; 142: I_ATOM_F2 : Atom format 2.; EE 144: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF66430C0; 149: I_ATOM_F2 : Atom format 2.; EE 150: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF663F5A0; 155: I_ATOM_F3 : Atom format 3.; NNN 156: I_ATOM_F1 : Atom format 1.; E 157: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF66430E4; 163: I_ATOM_F3 : Atom format 3.; EEE 164: I_ATOM_F1 : Atom format 1.; E 165: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF663BE00; 170: I_ATOM_F3 : Atom format 3.; EEN 171: I_ATOM_F3 : Atom format 3.; EEN 172: I_ATOM_F4 : Atom format 4.; NNNN 173: I_ATOM_F3 : Atom format 3.; EEN 174: I_ATOM_F3 : Atom format 3.; NEE 176: I_ATOM_F3 : Atom format 3.; NNE 177: I_ATOM_F3 : Atom format 3.; ENN 178: I_ATOM_F3 : Atom format 3.; EEN 179: I_ATOM_F3 : Atom format 3.; NEE 180: I_ATOM_F3 : Atom format 3.; NNE 181: I_ATOM_F3 : Atom format 3.; ENN 182: I_ATOM_F3 : Atom format 3.; EEN 183: I_ATOM_F3 : Atom format 3.; NEE 184: I_ATOM_F3 : Atom format 3.; NNE 185: I_ATOM_F3 : Atom format 3.; ENN 186: I_ATOM_F3 : Atom format 3.; EEN 187: I_ATOM_F3 : Atom format 3.; NEE 188: I_ATOM_F3 : Atom format 3.; NNE 189: I_ATOM_F3 : Atom format 3.; ENN 192: I_ATOM_F3 : Atom format 3.; EEN 193: I_ATOM_F3 : Atom format 3.; NEE 194: I_ATOM_F3 : Atom format 3.; NNE 195: I_ATOM_F3 : Atom format 3.; ENN 196: I_ATOM_F3 : Atom format 3.; ENE 197: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF6642AF8; 202: I_ATOM_F3 : Atom format 3.; EEE 203: I_ATOM_F1 : Atom format 1.; E 204: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF65FFA40; 210: I_ATOM_F2 : Atom format 2.; EE 211: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF6642B58; 216: I_ATOM_F3 : Atom format 3.; ENE 217: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF6643100 ~[0x3100] 220: I_ATOM_F3 : Atom format 3.; ENE 221: I_ATOM_F5 : Atom format 5.; ENENE 222: I_ATOM_F3 : Atom format 3.; EEN 224: I_ATOM_F3 : Atom format 3.; EEN 225: I_ATOM_F6 : Atom format 6.; EEEEN 226: I_ATOM_F3 : Atom format 3.; ENN 227: I_ATOM_F3 : Atom format 3.; NEE 228: I_ATOM_F2 : Atom format 2.; NE 229: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF66456D4 ~[0x56D4] 232: I_ATOM_F3 : Atom format 3.; ENE 233: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF66456E0 ~[0xE0] 235: I_ATOM_F3 : Atom format 3.; NEN 236: I_ATOM_F3 : Atom format 3.; NNE 237: I_ATOM_F3 : Atom format 3.; ENE 238: I_ADDR_MATCH : Exact Address Match., [1] 240: I_ATOM_F3 : Atom format 3.; ENE 241: I_ADDR_MATCH : Exact Address Match., [1] 242: I_ATOM_F3 : Atom format 3.; NNE 243: I_ATOM_F5 : Atom format 5.; ENENE 244: I_ATOM_F3 : Atom format 3.; ENE 245: I_ATOM_F3 : Atom format 3.; ENN 246: I_ATOM_F3 : Atom format 3.; EEN 247: I_ATOM_F1 : Atom format 1.; E 248: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF6645B40 ~[0x5B40] 251: I_ATOM_F5 : Atom format 5.; NEEEE 252: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF6642F84 ~[0x2F84] 256: I_ATOM_F4 : Atom format 4.; NNNN 257: I_ATOM_F1 : Atom format 1.; E 258: I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xF6643118 ~[0x3118] 261: I_ATOM_F2 : Atom format 2.; EE 262: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF663F960; 267: I_ATOM_F3 : Atom format 3.; NNE 268: I_ATOM_F1 : Atom format 1.; E 269: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF6643128; 275: I_ATOM_F1 : Atom format 1.; E 276: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF64A1BB8; 281: I_ATOM_F2 : Atom format 2.; EE 282: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF65EF290; 288: I_ATOM_F3 : Atom format 3.; NNE 289: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF64A1BC4; 294: I_ATOM_F2 : Atom format 2.; EE 295: I_ADDR_L_32IS0 : Address, Long, 32 bit, IS0.; Addr=0xF65EF164;
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Hi Mathieu and Youngjae,
Yes, I can try to help to debug this. I was in contact earlier last week with Youngjae about enabling collection of ETM traces on their device, and I asked them to send a message to the list.
I got their perf.data and it seems like there are no ETM events when they record with perf from the 4.9 branch. On the other hand the perf.data collected with the 4.12 branch seems to contain ETM trace events and the decoder seems to die on initialization when injecting. I'm not sure whether that is related to support in the coresight decoder for ETM v4.2. I will need to dig a little more with gdb.
Sebastian
Hi,
with the perf.data from Youngjae (perf_etf1_v4_12.data) I get the following error (using the latest CoreSight decoder from commit a466eb8dc3ac2bb6d60f058464e13b006717a977 Author: Mike Leach mike.leach@linaro.org Date: Fri Aug 18 14:30:57 2017 +0100
and linux perf from commit e565ad632331f42059a14d486cd4d27477b8d20d Author: Stephen Boyd sboyd@codeaurora.org Date: Fri Jul 28 13:31:11 2017 -0700 )
(gdb) run inject -f -i perf_etf1_v4_12.data -o inj --itrace=i100usl --strip
Program received signal SIGSEGV, Segmentation fault. 0x0000ffffb73841e0 in EtmV4IPktProcImpl::processData (this=0xffffffff4ec0, index=0, dataBlockSize=1, pDataBlock=0x474e5543432b2b00 <error: Cannot access memory at address 0x474e5543432b2b00>, numBytesProcessed=0xffffb7384168 <EtmV4IPktProcImpl::processData(unsigned int, unsigned int, unsigned char const*, unsigned int*)+576>) at /root/etm/decoder-may/decoder/source/etmv4/trc_pkt_proc_etmv4i_impl.cpp:155
This problem was an exception throwBadSequenceError from the following code in EtmV4IPktProcImpl::extractCondResult
unsigned EtmV4IPktProcImpl::extractCondResult(const std::vector<uint8_t> &buffer, const unsigned st_idx, uint32_t& key, uint8_t &result) { unsigned idx = 0; bool lastByte = false; int incr = 0;
key = 0;
while(!lastByte && (idx < 6)) // cannot be more than 6 bytes for res + 32 bit key { if(buffer.size() > (st_idx + idx)) { if(idx == 0) { result = buffer[st_idx+idx]; key = (buffer[st_idx+idx] >> 4) & 0x7; incr+=3; } else { key |= ((uint32_t)(buffer[st_idx+idx] & 0x7F)) << incr; incr+=7; } idx++; lastByte = (bool)((buffer[st_idx+idx] & 0x80) == 0); } else { throwBadSequenceError("Invalid continuation fields in packet"); } } return idx; }
This function gets called with the following arguments: (gdb) p buffer $156 = std::vector of length 6, capacity 16 = {107 'k', 72 'H', 252 '\374', 247 '\367', 154 '\232', 79 'O'} (gdb) p st_idx $157 = 5
and remark that if we go and execute the code that computes lastByte, we access outside the allocated buffer, as idx is incremented from 0 before the access of buffer[st_idx+idx], so we try to access buffer[6] which is not allocated.
I would recommend changing this code like this:
--- a/decoder/source/etmv4/trc_pkt_proc_etmv4i_impl.cpp +++ b/decoder/source/etmv4/trc_pkt_proc_etmv4i_impl.cpp @@ -1521,8 +1521,8 @@ unsigned EtmV4IPktProcImpl::extractContField64(const std::vector<uint8_t> &buffe key |= ((uint32_t)(buffer[st_idx+idx] & 0x7F)) << incr; incr+=7; } - idx++; lastByte = (bool)((buffer[st_idx+idx] & 0x80) == 0); + idx++; } else {
which makes the decoder pass further without the segfault. Mike, do you think this is a good change to the decoder?
Thanks, Sebastian
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;
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;
On Mon, Sep 4, 2017 at 11:14 AM, Mike Leach mike.leach@linaro.org wrote:
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.
Attached.
Thanks, Sebastian
Applied thanks.
OpenCSD v0.7.2 now available on github
On 5 September 2017 at 14:33, Sebastian Pop sebpop@gmail.com wrote:
On Mon, Sep 4, 2017 at 11:14 AM, Mike Leach mike.leach@linaro.org wrote:
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.
Attached.
Thanks, Sebastian
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
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
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 components c9b590717a3a coresight tmc: Add support for Coresight SoC 600 TMC 29f38854110e coresight tmc: Support for save-restore in ETR 0863f7b1f278 coresight tmc etr: Setup AXI cache encoding for read transfers f7bab28b7f16 coresight tmc etr: Cleanup AXICTL register handling d81598f029b5 coresight tmc etr: Detect address width at runtime 3c97c4f2566a coresight tmc: Detect support for scatter gather ca684de0ba58 coresight tmc etr: Add capabilitiy information b8b9228d7160 coresight tmc: Handle configuration types properly cc442642fcf5 coresight replicator: Expose replicator management registers 16c65a29684e coresight tmc: Expose DBA and AXICTL 560c49a5aa57 coresight tmc: Add helpers for accessing 64bit registers
I 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,@1e00a000.etr/u --per-thread taskset 1 uname
I checked the dump like below. ./perf report --stdio --dump
I 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 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
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 thesame..
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() parameter
tools/perf/util/cs-etm.c | 2 +- ae6ba28 cs-etm: Update to perf cs-etm decode for OpenCSD v0.4 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 30 +++++++++++++++++------ 29ff0bf perf scripts: Fixing file name extension
tools/perf/scripts/python/cs-trace-disasm.py | 2 +- 9074ff4 perf scripts: Fix binary filename and path tools/perf/scripts/python/cs-trace-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 on tools/perf/... 9e34dee cs-etm: removing unecessary structure field tools/perf/util/cs-etm.c | 10 +--------- 677a287 cs-etm: account for each trace buffer in the queue tools/perf/util/cs-etm.c | 17 +++++++++-------- 593a948 cs-etm: avoid casting variable
tools/perf/util/cs-etm.c | 6 ++++-- 26cee10 cs-etm: fixing uninitialised cpumode
tools/perf/util/cs-etm.c | 1 + 328948b perf tools: fixing Makefile problems
tools/perf/Makefile.config | 4 ++-- 73d4294 perf tools: new naming convention for openCSD tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 138 ++++++++++++----------- 451ca19 perf scripts: Add python scripts for CoreSight traces tools/perf/scripts/python/... 8f510fb perf tools: decoding capabilitity for CoreSight traces tools/perf/ .. b5d782e perf symbols: Check before overwriting build_id tools/perf/... dad8531 coresight: updating documentation to reflect integration with perf Documentation/trace/coresight.txt | 138 +++++++++++++++++++++++++++++++++---- ea817df coresight: tmc: implementing TMC-ETR AUX space API drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++++++++++ 0a189e4 perf tools: Removing miscellaneous debug output tools/perf/arch/arm/util/cs-etm.c | 2 -- 285fb22 coresight: perf: Add a missing call to etm_free_aux drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +- 3bfa9ae coresight: Add support for ARM Coresight STM-500 drivers/hwtracing/coresight/coresight-stm.c | 5 +++++ 8044597 coresight: tmc: Remove duplicate memset drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 -- 63c0930 coresight: tmc: Get rid of mode parameter for helper routines drivers/hwtracing/coresight/... 034cd3a coresight: tmc: Cleanup operation mode handling drivers/hwtracing/coresight/... 2866655 coresight: reset "enable_sink" flag when need be drivers/hwtracing/coresight/ 4cba396 coresight: etm3x: Adding missing features of Coresight PTM components .../hwtracing/coresight/... 6f6514b coresight: etm3x: indentation fix (extra space removed) .../hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +- d3167d3 coresight: stm: return error code instead of zero in .packet() drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
--------- *Original Message* ---------
*Sender* : Mathieu Poirier mathieu.poirier@linaro.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.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
Before going any further please provide a pastebin of the command:
$ "perf report --dump"
On 27 September 2017 at 19:27, 임영재 youngjae24.lim@samsung.com wrote:
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.
- 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.
- 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-threadtaskset 1 uname
But, I got the same result. I saw auxtrace data area is all 0.
- 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 uname
I 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 getpackt_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 components c9b590717a3a coresight tmc: Add support for Coresight SoC 600 TMC 29f38854110e coresight tmc: Support for save-restore in ETR 0863f7b1f278 coresight tmc etr: Setup AXI cache encoding for read transfers f7bab28b7f16 coresight tmc etr: Cleanup AXICTL register handling d81598f029b5 coresight tmc etr: Detect address width at runtime 3c97c4f2566a coresight tmc: Detect support for scatter gather ca684de0ba58 coresight tmc etr: Add capabilitiy information b8b9228d7160 coresight tmc: Handle configuration types properly cc442642fcf5 coresight replicator: Expose replicator management registers 16c65a29684e coresight tmc: Expose DBA and AXICTL 560c49a5aa57 coresight tmc: Add helpers for accessing 64bit registers
I 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,@1e00a000.etr/u --per-thread taskset 1 uname
I checked the dump like below. ./perf report --stdio --dump
I 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 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
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 thesame..
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() parameter
tools/perf/util/cs-etm.c | 2 +- ae6ba28 cs-etm: Update to perf cs-etm decode for OpenCSD v0.4 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 30 +++++++++++++++++------ 29ff0bf perf scripts: Fixing file name extension
tools/perf/scripts/python/cs-trace-disasm.py | 2 +- 9074ff4 perf scripts: Fix binary filename and path tools/perf/scripts/python/cs-trace-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 on tools/perf/... 9e34dee cs-etm: removing unecessary structure field tools/perf/util/cs-etm.c | 10 +--------- 677a287 cs-etm: account for each trace buffer in the queue tools/perf/util/cs-etm.c | 17 +++++++++-------- 593a948 cs-etm: avoid casting variable
tools/perf/util/cs-etm.c | 6 ++++-- 26cee10 cs-etm: fixing uninitialised cpumode
tools/perf/util/cs-etm.c | 1 + 328948b perf tools: fixing Makefile problems
tools/perf/Makefile.config | 4 ++-- 73d4294 perf tools: new naming convention for openCSD tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 138 ++++++++++++----------- 451ca19 perf scripts: Add python scripts for CoreSight traces tools/perf/scripts/python/... 8f510fb perf tools: decoding capabilitity for CoreSight traces tools/perf/ .. b5d782e perf symbols: Check before overwriting build_id tools/perf/... dad8531 coresight: updating documentation to reflect integration with perf Documentation/trace/coresight.txt | 138 +++++++++++++++++++++++++++++++++---- ea817df coresight: tmc: implementing TMC-ETR AUX space API drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++++++++++ 0a189e4 perf tools: Removing miscellaneous debug output tools/perf/arch/arm/util/cs-etm.c | 2 -- 285fb22 coresight: perf: Add a missing call to etm_free_aux drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +- 3bfa9ae coresight: Add support for ARM Coresight STM-500 drivers/hwtracing/coresight/coresight-stm.c | 5 +++++ 8044597 coresight: tmc: Remove duplicate memset drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 -- 63c0930 coresight: tmc: Get rid of mode parameter for helper routines drivers/hwtracing/coresight/... 034cd3a coresight: tmc: Cleanup operation mode handling drivers/hwtracing/coresight/... 2866655 coresight: reset "enable_sink" flag when need be drivers/hwtracing/coresight/ 4cba396 coresight: etm3x: Adding missing features of Coresight PTM components .../hwtracing/coresight/... 6f6514b coresight: etm3x: indentation fix (extra space removed) .../hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +- d3167d3 coresight: stm: return error code instead of zero in .packet() drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
--------- *Original Message* ---------
*Sender* : Mathieu Poirier mathieu.poirier@linaro.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.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
On 11 October 2017 at 23:49, 임영재 youngjae24.lim@samsung.com wrote:
Hello.
I provide a pastebin of the command.
Is branch stack nr 0 because the address is Kernel address area?
What are you trying to accomplish here? To me everything you have below looks good.
Going forward, it might be a good idea for you to join one of us on IRC where we will be able to get more details on what you are trying to do, and you may be able to ask questions. We are in the #linaro-coresight channel on the freenode server. If you are in Korea it will be easier for Mike to help you - his handle is "mikelbbn". You can also reach me using the "mpoirier" handle but that will be more difficult as I am in North America.
Thanks, Mathieu
./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
This looks good to me...
*./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
Before going any further please provide a pastebin of the command:
$ "perf report --dump"
On 27 September 2017 at 19:27, 임영재 youngjae24.lim@samsung.com wrote:
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.
- 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.
- 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-threadtaskset 1 uname
But, I got the same result. I saw auxtrace data area is all 0.
- 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 uname
I 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 getpackt_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 components c9b590717a3a coresight tmc: Add support for Coresight SoC 600 TMC 29f38854110e coresight tmc: Support for save-restore in ETR 0863f7b1f278 coresight tmc etr: Setup AXI cache encoding for read transfers f7bab28b7f16 coresight tmc etr: Cleanup AXICTL register handling d81598f029b5 coresight tmc etr: Detect address width at runtime 3c97c4f2566a coresight tmc: Detect support for scatter gather ca684de0ba58 coresight tmc etr: Add capabilitiy information b8b9228d7160 coresight tmc: Handle configuration types properly cc442642fcf5 coresight replicator: Expose replicator management registers 16c65a29684e coresight tmc: Expose DBA and AXICTL 560c49a5aa57 coresight tmc: Add helpers for accessing 64bit registers
I 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,@1e00a000.etr/u --per-thread taskset 1 uname
I checked the dump like below. ./perf report --stdio --dump
I 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 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
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 thesame..
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() parameter
tools/perf/util/cs-etm.c | 2 +- ae6ba28 cs-etm: Update to perf cs-etm decode for OpenCSD v0.4 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 30 +++++++++++++++++------ 29ff0bf perf scripts: Fixing file name extension
tools/perf/scripts/python/cs-trace-disasm.py | 2 +- 9074ff4 perf scripts: Fix binary filename and path tools/perf/scripts/python/cs-trace-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 on tools/perf/... 9e34dee cs-etm: removing unecessary structure field tools/perf/util/cs-etm.c | 10 +--------- 677a287 cs-etm: account for each trace buffer in the queue tools/perf/util/cs-etm.c | 17 +++++++++-------- 593a948 cs-etm: avoid casting variable
tools/perf/util/cs-etm.c | 6 ++++-- 26cee10 cs-etm: fixing uninitialised cpumode
tools/perf/util/cs-etm.c | 1 + 328948b perf tools: fixing Makefile problems
tools/perf/Makefile.config | 4 ++-- 73d4294 perf tools: new naming convention for openCSD tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 138 ++++++++++++----------- 451ca19 perf scripts: Add python scripts for CoreSight traces tools/perf/scripts/python/... 8f510fb perf tools: decoding capabilitity for CoreSight traces tools/perf/ .. b5d782e perf symbols: Check before overwriting build_id tools/perf/... dad8531 coresight: updating documentation to reflect integration with perf Documentation/trace/coresight.txt | 138 +++++++++++++++++++++++++++++++++---- ea817df coresight: tmc: implementing TMC-ETR AUX space API drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++++++++++ 0a189e4 perf tools: Removing miscellaneous debug output tools/perf/arch/arm/util/cs-etm.c | 2 -- 285fb22 coresight: perf: Add a missing call to etm_free_aux drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +- 3bfa9ae coresight: Add support for ARM Coresight STM-500 drivers/hwtracing/coresight/coresight-stm.c | 5 +++++ 8044597 coresight: tmc: Remove duplicate memset
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 -- 63c0930 coresight: tmc: Get rid of mode parameter for helper routines drivers/hwtracing/coresight/... 034cd3a coresight: tmc: Cleanup operation mode handling drivers/hwtracing/coresight/... 2866655 coresight: reset "enable_sink" flag when need be drivers/hwtracing/coresight/ 4cba396 coresight: etm3x: Adding missing features of Coresight PTM components .../hwtracing/coresight/... 6f6514b coresight: etm3x: indentation fix (extra space removed) .../hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +- d3167d3 coresight: stm: return error code instead of zero in .packet() drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
--------- *Original Message* ---------
*Sender* : Mathieu Poirier mathieu.poirier@linaro.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.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
Hi,
I cannot address directly the "branch stack nr 0" but I have the following comments based on the data above.
1) You have requested cycacc tracing. There are no cycle count packets in the trace data, and the TRACE_INFO value (0x0) indicates that cycle accurate tracing has not been programmed. Please check that all the relevant patches have been applied.
I also see that the CONFIGR value is reported in the perf dump is 0x10001000 -> this is correct for ETMv3, illegal for ETMv4. I believe you are missing the patch "perf: cs-etm: Fix ETMv4 CONFIGR entry in perf.data file"
2) The trace dump is showing a reserved packet header [ 141: id[10] I_RESERVED : Reserved Packet Header ]. This should not appear in your trace data. Please use the CSTRACE_RAW environment variable to build a version of perf that will dump the raw binary trace packets. (There is a patch that enables this functionality in the makefile and cs-etm-decoder.c). We can then investigate further.
3) In previous e-mails you mention OCSD_GEN_TRC_ELEM_ADDR_NACC packets. These occur if the decoder cannot access the code image at the given address. The .debug directory contains all the executable and .so files used during the trace session, which perf uses to provide code images to the decoder. The kernel image is not included in this database. This must be provided to the decoder to trace through kernel image areas. I do not know how to do this as part of the perf inject command, though others may be able to help here.
Best Regards
Mike
On 12 October 2017 at 15:45, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 11 October 2017 at 23:49, 임영재 youngjae24.lim@samsung.com wrote:
Hello.
I provide a pastebin of the command.
Is branch stack nr 0 because the address is Kernel address area?
What are you trying to accomplish here? To me everything you have below looks good.
Going forward, it might be a good idea for you to join one of us on IRC where we will be able to get more details on what you are trying to do, and you may be able to ask questions. We are in the #linaro-coresight channel on the freenode server. If you are in Korea it will be easier for Mike to help you - his handle is "mikelbbn". You can also reach me using the "mpoirier" handle but that will be more difficult as I am in North America.
Thanks, Mathieu
./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
This looks good to me...
*./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
Before going any further please provide a pastebin of the command:
$ "perf report --dump"
On 27 September 2017 at 19:27, 임영재 youngjae24.lim@samsung.com wrote:
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.
- 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.
- 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-threadtaskset 1 uname
But, I got the same result. I saw auxtrace data area is all 0.
- 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 uname
I 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 getpackt_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 components c9b590717a3a coresight tmc: Add support for Coresight SoC 600 TMC 29f38854110e coresight tmc: Support for save-restore in ETR 0863f7b1f278 coresight tmc etr: Setup AXI cache encoding for read transfers f7bab28b7f16 coresight tmc etr: Cleanup AXICTL register handling d81598f029b5 coresight tmc etr: Detect address width at runtime 3c97c4f2566a coresight tmc: Detect support for scatter gather ca684de0ba58 coresight tmc etr: Add capabilitiy information b8b9228d7160 coresight tmc: Handle configuration types properly cc442642fcf5 coresight replicator: Expose replicator management registers 16c65a29684e coresight tmc: Expose DBA and AXICTL 560c49a5aa57 coresight tmc: Add helpers for accessing 64bit registers
I 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,@1e00a000.etr/u --per-thread taskset 1 uname
I checked the dump like below. ./perf report --stdio --dump
I 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 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
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 isthe 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() parameter
tools/perf/util/cs-etm.c | 2 +- ae6ba28 cs-etm: Update to perf cs-etm decode for OpenCSD v0.4 tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 30 +++++++++++++++++------ 29ff0bf perf scripts: Fixing file name extension
tools/perf/scripts/python/cs-trace-disasm.py | 2 +- 9074ff4 perf scripts: Fix binary filename and path tools/perf/scripts/python/cs-trace-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 on tools/perf/... 9e34dee cs-etm: removing unecessary structure field tools/perf/util/cs-etm.c | 10 +--------- 677a287 cs-etm: account for each trace buffer in the queue tools/perf/util/cs-etm.c | 17 +++++++++-------- 593a948 cs-etm: avoid casting variable
tools/perf/util/cs-etm.c | 6 ++++-- 26cee10 cs-etm: fixing uninitialised cpumode
tools/perf/util/cs-etm.c | 1 + 328948b perf tools: fixing Makefile problems
tools/perf/Makefile.config | 4 ++-- 73d4294 perf tools: new naming convention for openCSD tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 138 ++++++++++++----------- 451ca19 perf scripts: Add python scripts for CoreSight traces tools/perf/scripts/python/... 8f510fb perf tools: decoding capabilitity for CoreSight traces tools/perf/ .. b5d782e perf symbols: Check before overwriting build_id tools/perf/... dad8531 coresight: updating documentation to reflect integration with perf Documentation/trace/coresight.txt | 138 +++++++++++++++++++++++++++++++++---- ea817df coresight: tmc: implementing TMC-ETR AUX space API drivers/hwtracing/coresight/coresight-tmc-etr.c | 243 +++++++++++++++++++++++ 0a189e4 perf tools: Removing miscellaneous debug output tools/perf/arch/arm/util/cs-etm.c | 2 -- 285fb22 coresight: perf: Add a missing call to etm_free_aux drivers/hwtracing/coresight/coresight-etm-perf.c | 2 +- 3bfa9ae coresight: Add support for ARM Coresight STM-500 drivers/hwtracing/coresight/coresight-stm.c | 5 +++++ 8044597 coresight: tmc: Remove duplicate memset
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 -- 63c0930 coresight: tmc: Get rid of mode parameter for helper routines drivers/hwtracing/coresight/... 034cd3a coresight: tmc: Cleanup operation mode handling drivers/hwtracing/coresight/... 2866655 coresight: reset "enable_sink" flag when need be drivers/hwtracing/coresight/ 4cba396 coresight: etm3x: Adding missing features of Coresight PTM components .../hwtracing/coresight/... 6f6514b coresight: etm3x: indentation fix (extra space removed) .../hwtracing/coresight/coresight-etm3x-sysfs.c | 2 +- d3167d3 coresight: stm: return error code instead of zero in .packet() drivers/hwtracing/coresight/coresight-stm.c | 4 ++--
--------- *Original Message* ---------
*Sender* : Mathieu Poirier mathieu.poirier@linaro.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.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
-
Mathieu Poirier -
Mike Leach -
Sebastian Pop -
임영재