Dear Sir,
My apologies for spamming you with more, perhaps ridiculous, questions...
I have been struggling to understand the systematic approach to conduct system traces with sysFS. I have asked similar question to hwangcc23, but I feel this question is suited more for the Linaro team.
I am having trouble choosing the options for the coresight drivers in my Hikey960 device with Cortex A53 and A73 processors, 4 CPUs each. I have created a simple program that is a quick implementation of a link list in C program. The following is the objdump of the main object:
```bash ... ... 00000000000009e8 <main>: 9e8: d10583ff sub sp, sp, #0x160 9ec: f900a3fc str x28, [sp,#320] 9f0: a9157bfd stp x29, x30, [sp,#336] 9f4: 910543fd add x29, sp, #0x150 9f8: 321e03e8 orr w8, wzr, #0x4 9fc: 52800009 mov w9, #0x0 // #0 a00: b27903e2 orr x2, xzr, #0x80 a04: d280000a mov x10, #0x0 // #0 a08: b000008b adrp x11, 11000 <init+0x100f4> a0c: f947e96b ldr x11, [x11,#4048] a10: d280260c mov x12, #0x130 // #304 a14: 8b0c016c add x12, x11, x12 a18: 9000000d adrp x13, 0 <note_android_ident-0x218> a1c: 913f21ad add x13, x13, #0xfc8 a20: d280130e mov x14, #0x98 // #152 a24: 8b0e016b add x11, x11, x14 a28: 9000000e adrp x14, 0 <note_android_ident-0x218> a2c: 913e41ce add x14, x14, #0xf90 a30: 9000000f adrp x15, 0 <note_android_ident-0x218> a34: 913f09ef add x15, x15, #0xfc2 a38: 90000010 adrp x16, 0 <note_android_ident-0x218> a3c: 913dfa10 add x16, x16, #0xf7e a40: 90000011 adrp x17, 0 <note_android_ident-0x218> a44: 913db231 add x17, x17, #0xf6c a48: 9102a3f2 add x18, sp, #0xa8 a4c: b81ec3bf stur wzr, [x29,#-20] a50: b81e83a0 stur w0, [x29,#-24] a54: f81e03a1 stur x1, [x29,#-32] a58: b81dc3a8 stur w8, [x29,#-36] a5c: f9003bf2 str x18, [sp,#112] a60: f90037f1 str x17, [sp,#104] a64: f90033f0 str x16, [sp,#96] a68: b9005fe9 str w9, [sp,#92] a6c: f9002be2 str x2, [sp,#80] a70: f90027ea str x10, [sp,#72] a74: f90023ed str x13, [sp,#64] a78: f9001fec str x12, [sp,#56] a7c: f9001beb str x11, [sp,#48] a80: f90017ee str x14, [sp,#40] a84: f90013ef str x15, [sp,#32] a88: 97ffff8e bl 8c0 getpid@plt a8c: b81d83a0 stur w0, [x29,#-40] a90: f9403be0 ldr x0, [sp,#112] a94: b9405fe8 ldr w8, [sp,#92] a98: 2a0803e1 mov w1, w8 a9c: f9402be2 ldr x2, [sp,#80] aa0: 97ffffa4 bl 930 memset@plt aa4: b27603e8 orr x8, xzr, #0x400 aa8: b27e03e9 orr x9, xzr, #0x4 aac: f90053e9 str x9, [sp,#160] ab0: f94053e9 ldr x9, [sp,#160] ab4: eb08013f cmp x9, x8 ab8: 1a9f27ea cset w10, cc abc: 3700004a tbnz w10, #0, ac4 <main+0xdc> ac0: 14000010 b b00 <main+0x118> ac4: 9102a3e8 add x8, sp, #0xa8 ac8: b27d03e9 orr x9, xzr, #0x8 acc: b27a03ea orr x10, xzr, #0x40 ad0: b24003eb orr x11, xzr, #0x1 ad4: b24017ec orr x12, xzr, #0x3f ad8: f94053ed ldr x13, [sp,#160] adc: 8a0c01ac and x12, x13, x12 ae0: 9acc216b lsl x11, x11, x12 ae4: f94053ec ldr x12, [sp,#160] ae8: 9aca098a udiv x10, x12, x10 aec: 9b0a7d29 mul x9, x9, x10 af0: 8b090108 add x8, x8, x9 af4: f9400109 ldr x9, [x8] af8: aa0b0129 orr x9, x9, x11 afc: f9000109 str x9, [x8] b00: 9102a3e2 add x2, sp, #0xa8 b04: b27903e1 orr x1, xzr, #0x80 b08: b85d83a0 ldur w0, [x29,#-40] b0c: 97ffff79 bl 8f0 sched_setaffinity@plt b10: b9009fe0 str w0, [sp,#156] b14: b9409fe0 ldr w0, [sp,#156] b18: 35000040 cbnz w0, b20 <main+0x138> b1c: 1400000c b b4c <main+0x164> b20: 320003e0 orr w0, wzr, #0x1 b24: b9409fe8 ldr w8, [sp,#156] b28: b9001fe0 str w0, [sp,#28] b2c: b9001be8 str w8, [sp,#24] b30: 97ffff60 bl 8b0 __errno@plt b34: b9401be8 ldr w8, [sp,#24] b38: b9000008 str w8, [x0] b3c: f94037e0 ldr x0, [sp,#104] b40: 97ffff64 bl 8d0 perror@plt b44: b9401fe0 ldr w0, [sp,#28] b48: 97ffff6e bl 900 exit@plt b4c: 9102a3e2 add x2, sp, #0xa8 b50: b27903e1 orr x1, xzr, #0x80 b54: b85d83a0 ldur w0, [x29,#-40] b58: 97ffff62 bl 8e0 sched_getaffinity@plt b5c: b9009be0 str w0, [sp,#152] b60: b9409be0 ldr w0, [sp,#152] b64: 35000040 cbnz w0, b6c <main+0x184> b68: 1400000c b b98 <main+0x1b0> b6c: 320003e0 orr w0, wzr, #0x1 b70: b9409be8 ldr w8, [sp,#152] b74: b90017e0 str w0, [sp,#20] b78: b90013e8 str w8, [sp,#16] b7c: 97ffff4d bl 8b0 __errno@plt b80: b94013e8 ldr w8, [sp,#16] b84: b9000008 str w8, [x0] b88: f94033e0 ldr x0, [sp,#96] b8c: 97ffff51 bl 8d0 perror@plt b90: b94017e0 ldr w0, [sp,#20] b94: 97ffff5b bl 900 exit@plt b98: b27603e8 orr x8, xzr, #0x400 b9c: b27e03e9 orr x9, xzr, #0x4 ba0: f9004be9 str x9, [sp,#144] ba4: f9404be9 ldr x9, [sp,#144] ba8: eb08013f cmp x9, x8 bac: 1a9f27ea cset w10, cc bb0: 3700004a tbnz w10, #0, bb8 <main+0x1d0> bb4: 14000016 b c0c <main+0x224> bb8: 9102a3e8 add x8, sp, #0xa8 bbc: d2800009 mov x9, #0x0 // #0 bc0: b27d03ea orr x10, xzr, #0x8 bc4: b27a03eb orr x11, xzr, #0x40 bc8: b24003ec orr x12, xzr, #0x1 bcc: b24017ed orr x13, xzr, #0x3f bd0: f9404bee ldr x14, [sp,#144] bd4: 9acb09cb udiv x11, x14, x11 bd8: 9b0b7d4a mul x10, x10, x11 bdc: 8b0a0108 add x8, x8, x10 be0: f9400108 ldr x8, [x8] be4: f9404bea ldr x10, [sp,#144] be8: 8a0d014a and x10, x10, x13 bec: 9aca218a lsl x10, x12, x10 bf0: 8a0a0108 and x8, x8, x10 bf4: eb09011f cmp x8, x9 bf8: 1a9f07ef cset w15, ne bfc: 320003f0 orr w16, wzr, #0x1 c00: 0a1001ef and w15, w15, w16 c04: b9000fef str w15, [sp,#12] c08: 14000003 b c14 <main+0x22c> c0c: 52800008 mov w8, #0x0 // #0 c10: b9000fe8 str w8, [sp,#12] c14: b9400fe8 ldr w8, [sp,#12] c18: b9008fe8 str w8, [sp,#140] c1c: b9408fe8 ldr w8, [sp,#140] c20: 35000048 cbnz w8, c28 <main+0x240> c24: 14000028 b cc4 <main+0x2dc> c28: b27c03e0 orr x0, xzr, #0x10 c2c: 321e03e3 orr w3, wzr, #0x4 c30: b85d83a2 ldur w2, [x29,#-40] c34: f9401be8 ldr x8, [sp,#48] c38: f90003e0 str x0, [sp] c3c: aa0803e0 mov x0, x8 c40: f94017e1 ldr x1, [sp,#40] c44: 97ffff33 bl 910 fprintf@plt c48: f94027e8 ldr x8, [sp,#72] c4c: f90043e8 str x8, [sp,#128] c50: f94003e1 ldr x1, [sp] c54: aa0103e0 mov x0, x1 c58: 97ffff32 bl 920 malloc@plt c5c: f90043e0 str x0, [sp,#128] c60: f94043e0 ldr x0, [sp,#128] c64: 940000aa bl f0c <init> c68: b9007fff str wzr, [sp,#124] c6c: 52849f08 mov w8, #0x24f8 // #9464 c70: 72a00028 movk w8, #0x1, lsl #16 c74: b9407fe9 ldr w9, [sp,#124] c78: 6b08013f cmp w9, w8 c7c: 1a9fa7e8 cset w8, lt c80: 37000048 tbnz w8, #0, c88 <main+0x2a0> c84: 14000009 b ca8 <main+0x2c0> c88: 52800c28 mov w8, #0x61 // #97 c8c: f94043e0 ldr x0, [sp,#128] c90: 2a0803e1 mov w1, w8 c94: 94000016 bl cec <push> c98: b9407fe8 ldr w8, [sp,#124] c9c: 11000508 add w8, w8, #0x1 ca0: b9007fe8 str w8, [sp,#124] ca4: 17fffff2 b c6c <main+0x284> ca8: f94013e0 ldr x0, [sp,#32] cac: 97fffefd bl 8a0 printf@plt cb0: f94043e8 ldr x8, [sp,#128] cb4: aa0803e0 mov x0, x8 cb8: 94000065 bl e4c <print_list> cbc: b81ec3bf stur wzr, [x29,#-20] cc0: 14000006 b cd8 <main+0x2f0> cc4: 321e03e3 orr w3, wzr, #0x4 cc8: b85d83a2 ldur w2, [x29,#-40] ccc: f9401fe0 ldr x0, [sp,#56] cd0: f94023e1 ldr x1, [sp,#64] cd4: 97ffff0f bl 910 fprintf@plt cd8: b85ec3a0 ldur w0, [x29,#-20] cdc: a9557bfd ldp x29, x30, [sp,#336] ce0: f940a3fc ldr x28, [sp,#320] ce4: 910583ff add sp, sp, #0x160 ce8: d65f03c0 ret ... ... ```
What i did was look at the start address (d10583ff) of the main object and echo it into /sys/bus/coresight/devices/<memory_map>.etm/addr_start. Even though I was able to write into addr_start in sysfs, I was unable to read the value back despite it being readable. This can be seen in the following output:
```bash -rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted ```
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
More info about my device: `# uname -a` yields `Linux localhost 4.9.176-12953-g7c09ed7b46a4-dirty #13 SMP PREEMPT Tue Jun 4 10:16:26 +08 2019 aarch64`
hi3660-coresight.dtsi yields the following device tree: ```bash /* * Copyright (C) 2016-2017 Hisilicon Ltd. * Author: shiwanglai shiwanglai@hisilicon.com * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * publishhed by the Free Software Foundation. */ / { amba { #address-cells = <2>; #size-cells = <2>; compatible = "arm,amba-bus"; ranges;
/* A53 cluster internal coresight */ etm@0,ecc40000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xecc40000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu0>; port { etm0_out_port: endpoint { remote-endpoint = <&funnel0_in_port0>; }; }; };
etm@1,ecd40000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xecd40000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu1>; port { etm1_out_port: endpoint { remote-endpoint = <&funnel0_in_port1>; }; }; };
etm@2,ece40000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xece40000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu2>; port { etm2_out_port: endpoint { remote-endpoint = <&funnel0_in_port2>; }; }; };
etm@3,ecf40000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xecf40000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu3>; port { etm3_out_port: endpoint { remote-endpoint = <&funnel0_in_port3>; }; }; };
funnel0:funnel@0,ec801000 { compatible = "arm,coresight-funnel","arm,primecell"; reg = <0 0xec801000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>;
/* funnel output port */ port@0 { reg = <0>; funnel0_out_port: endpoint { remote-endpoint = <&etf0_in_port>; }; };
/* funnel input ports */ port@1 { reg = <0>; funnel0_in_port0: endpoint { slave-mode; remote-endpoint = <&etm0_out_port>; }; };
port@2 { reg = <1>; funnel0_in_port1: endpoint { slave-mode; remote-endpoint = <&etm1_out_port>; }; };
port@3 { reg = <2>; funnel0_in_port2: endpoint { slave-mode; remote-endpoint = <&etm2_out_port>; }; };
port@4 { reg = <3>; funnel0_in_port3: endpoint { slave-mode; remote-endpoint = <&etm3_out_port>; }; }; }; };
etf0:etf@0,ec802000 { compatible = "arm,coresight-tmc","arm,primecell"; reg = <0 0xec802000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>; /* input port */ port@0 { reg = <0>; etf0_in_port: endpoint { slave-mode; remote-endpoint = <&funnel0_out_port>; }; };
/* output port */ port@1 { reg = <0>; etf0_out_port: endpoint { remote-endpoint = <&funnel2_in_port0>; }; }; }; };
/* A73 cluster internal coresight */ etm@4,ed440000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xed440000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu4>; port { etm4_out_port: endpoint { remote-endpoint = <&funnel1_in_port0>; }; }; };
etm@5,ed540000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xed540000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu5>; port { etm5_out_port: endpoint { remote-endpoint = <&funnel1_in_port1>; }; }; };
etm@6,ed640000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xed640000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu6>; port { etm6_out_port: endpoint { remote-endpoint = <&funnel1_in_port2>; }; }; };
etm@7,ed740000 { compatible = "arm,coresight-etm4x","arm,primecell"; reg = <0 0xed740000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; cpu = <&cpu7>; port { etm7_out_port: endpoint { remote-endpoint = <&funnel1_in_port3>; }; }; };
funnel1:funnel@1,ed001000 { compatible = "arm,coresight-funnel","arm,primecell"; reg = <0 0xed001000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>;
/* funnel output port */ port@0 { reg = <0>; funnel1_out_port: endpoint { remote-endpoint = <&etf1_in_port>; }; };
/* funnel input ports */ port@1 { reg = <0>; funnel1_in_port0: endpoint { slave-mode; remote-endpoint = <&etm4_out_port>; }; };
port@2 { reg = <1>; funnel1_in_port1: endpoint { slave-mode; remote-endpoint = <&etm5_out_port>; }; };
port@3 { reg = <2>; funnel1_in_port2: endpoint { slave-mode; remote-endpoint = <&etm6_out_port>; }; };
port@4 { reg = <3>; funnel1_in_port3: endpoint { slave-mode; remote-endpoint = <&etm7_out_port>; }; }; }; };
etf1:etf@1,ed002000 { compatible = "arm,coresight-tmc","arm,primecell"; reg = <0 0xed002000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>; /* input port */ port@0 { reg = <0>; etf1_in_port: endpoint { slave-mode; remote-endpoint = <&funnel1_out_port>; }; };
/* output port */ port@1 { reg = <0>; etf1_out_port: endpoint { remote-endpoint = <&funnel2_in_port0>; }; }; }; };
/* Top coresight config */ funnel@2,ec031000 { compatible = "arm,coresight-funnel","arm,primecell"; reg = <0 0xec031000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>;
/* funnel output port */ port@0 { reg = <0>; funnel2_out_port: endpoint { remote-endpoint = <&etf2_in_port>; }; };
/* funnel input ports */ /* - both cluster ETFs go to port 0 - there may be another (hidden) funnel between these */ port@1 { reg = <0>; funnel2_in_port0: endpoint { slave-mode; remote-endpoint = <&etf0_out_port>; }; }; }; };
etf@2,ec036000 { compatible = "arm,coresight-tmc","arm,primecell"; reg = <0 0xec036000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>; /* input port */ port@0 { reg = <0>; etf2_in_port: endpoint { slave-mode; remote-endpoint = <&funnel2_out_port>; }; };
/* output port */ port@1 { reg = <0>; etf2_out_port: endpoint { remote-endpoint = <&replicator0_in_port>; }; }; }; };
replicator { compatible = "arm,coresight-replicator";
ports { #address-cells = <1>; #size-cells = <0>;
/* etr out port */ port@0 { reg = <0>; replicator0_out_port0: endpoint { remote-endpoint = <&etr_in_port>; }; }; /* TPIU out port */ port@1 { reg = <1>; replicator0_out_port1: endpoint { remote-endpoint = <&tpiu_in_port>; }; }; /* input port */ port@2 { reg = <0>; replicator0_in_port: endpoint { slave-mode; remote-endpoint = <&etf2_out_port>; }; }; }; };
etr@0,ec033000 { compatible = "arm,coresight-tmc","arm,primecell"; reg = <0 0xec033000 0 0x1000>; clocks = <&pclk>; clock-names = "apb_pclk"; ports { #address-cells = <1>; #size-cells = <0>;
/* etr input port */ port@0 { reg = <0>; etr_in_port: endpoint { slave-mode; remote-endpoint = <&replicator0_out_port0>; }; }; }; };
tpiu@ec032000 { compatible = "arm,coresight-tpiu", "arm,primecell"; reg = <0 0xec032000 0 0x1000>;
clocks = <&pclk>; clock-names = "apb_pclk"; port { tpiu_in_port: endpoint { slave-mode; remote-endpoint = <&replicator0_out_port1>; }; }; }; }; }; ```
On occasions when the trace succeeded (which i could not fathom when it will work and when it will crash), I used ptm2human to acquire the following decoded log: ```bash Reading cs.bin Decode trace stream of ID 0 Syncing the trace stream... Decode trace stream of ID 1 Syncing the trace stream... Decode trace stream of ID 2 Syncing the trace stream... Decode trace stream of ID 3 Syncing the trace stream... Decode trace stream of ID 4 Syncing the trace stream... Decode trace stream of ID 5 Syncing the trace stream... Decode trace stream of ID 6 Syncing the trace stream... Decode trace stream of ID 7 Syncing the trace stream... Decode trace stream of ID 8 Syncing the trace stream... Decode trace stream of ID 9 Syncing the trace stream... Decode trace stream of ID 10 Syncing the trace stream... Decode trace stream of ID 11 Syncing the trace stream... Decode trace stream of ID 12 Syncing the trace stream... Decode trace stream of ID 13 Syncing the trace stream... Decode trace stream of ID 14 Syncing the trace stream... Decode trace stream of ID 15 Syncing the trace stream... Decode trace stream of ID 16 Syncing the trace stream... Decode trace stream of ID 17 Syncing the trace stream... Decode trace stream of ID 18 Syncing the trace stream... Decode trace stream of ID 19 Syncing the trace stream... Decode trace stream of ID 20 Syncing the trace stream... Decode trace stream of ID 21 Syncing the trace stream... Decode trace stream of ID 22 Syncing the trace stream... Decode trace stream of ID 23 Syncing the trace stream... Decoding the trace stream... TraceInfo - Cycle count disabled, Tracing of conditional non-branch instruction disabled, No explicit tracing of load instructions, No explicit tracing of store instructions, p0_key = 0x0, curr_spec_depth = 0, cc_threshold = 0x0 Context - Context ID = 0x0, VMID = 0x0, Exception level = EL0, Security = NS, 32-bit instruction Address - Instruction address 0x0000005edb77ed10, Instruction set Aarch32 (Thumb) Mispredict ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - N Commit - 1 Address - Instruction address 0x0000007c010c9388, Instruction set Aarch32 (Thumb) ATOM - N Commit - 1 ATOM - E Commit - 1 ATOM - N Commit - 1 ATOM - E Commit - 1 ATOM - N Commit - 1 ATOM - E Commit - 1 Address - Instruction address 0x0000007c01167c70, Instruction set Aarch32 (Thumb) ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - E Commit - 1 Address - Instruction address 0x0000007c010ccf68, Instruction set Aarch32 (Thumb) ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - N Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 Address - Instruction address 0x0000007c010c93b0, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 ATOM - E Commit - 1 Address - Instruction address 0x0000005edb77ed44, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005edb77ec98, Instruction set Aarch32 (Thumb) Complete decode of the trace stream ```
Once again, I am awfully sorry for the abnormally long post. However, I have been trying to work on this for the past 6 weeks and I have not been able to understand the entire framework and hence I am getting desperate to seek professional help.
I have attached the source code and the log file to this email to hopefully help you understand my problems better.
Yours Sincerely, Jeremy
This email may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are notified that any use, dissemination, distribution, or copying of this email, or any attachment, is strictly prohibited. Please delete the email immediately and inform the sender. Thank You
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
``` hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s ```
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly. I thought i should detail the entire process for your expertise advise:
``` root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e ```
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan Thank you very much for your kind responses and patience!
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Hi Jeremy,
On Tue, 11 Jun 2019 at 04:36, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
0xd10583ff does not look like a valid address - the bottom bit / two bits must be 0 for a Thumb2 / AArch32/64 address. Looking at the previous objdump you did, I think you are misreading it...
... 00000000000009e8 <main>: 9e8: d10583ff sub sp, sp, #0x160 9ec: f900a3fc str x28, [sp,#320]
here 0000000009e8 is the relative address for the symbol 'main'
the line:
9e8: d10583ff sub sp, sp, #0x160 is in order <relative address>: <op_code> <disassembly> So the value d10583ff represents the opcode, not the address of the instruction. This can only be discovered by determining the program load address and adding in the offset to <main>
Regards
Mike
I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I thought i should detail the entire process for your expertise advise:
root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kind responses and patience!
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
Hi Mike,
From: Mike Leach Sent: Tuesday, 11 June, 8:39 PM Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73) To: Student - Ng Yi Zher Jeremy Cc: Leo Yan, Coresight ML
Hi Jeremy,
On Tue, 11 Jun 2019 at 04:36, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
0xd10583ff does not look like a valid address - the bottom bit / two bits must be 0 for a Thumb2 / AArch32/64 address. Looking at the previous objdump you did, I think you are misreading it...
... 00000000000009e8 <main>: 9e8: d10583ff sub sp, sp, #0x160 9ec: f900a3fc str x28, [sp,#320]
here 0000000009e8 is the relative address for the symbol 'main'
the line:
9e8: d10583ff sub sp, sp, #0x160 is in order <relative address>: <op_code> <disassembly> So the value d10583ff represents the opcode, not the address of the instruction. This can only be discovered by determining the program load address and adding in the offset to <main>
Regards
Mike
This is embarrassing. Thank you very much for pointing that out! That could be the reason. I will give it a try tomorrow and update here.
I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I thought i should detail the entire process for your expertise advise:
root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kind responses and patience!
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK Cheers, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
On Mon, 10 Jun 2019 at 21:35, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I thought i should detail the entire process for your expertise advise:
root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e
The ptm2human tools is for PTM tracers while your trancers are ETMv4, as such you will never get anything sane out of it. Also note that CPUidle needs to be disabled if you want CS to work properly on the HiKey960. I am working on that problem.
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960. Thanks, Leo Yan Thank you very much for your kind responses and patience! The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Hi Mike,
Get Outlook for Androidhttps://aka.ms/ghei36
________________________________ From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Tuesday, June 11, 2019 10:34:49 PM To: Student - Ng Yi Zher Jeremy Cc: Leo Yan; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
On Mon, 10 Jun 2019 at 21:35, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I thought i should detail the entire process for your expertise advise:
root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e
The ptm2human tools is for PTM tracers while your trancers are ETMv4, as such you will never get anything sane out of it. Also note that CPUidle needs to be disabled if you want CS to work properly on the HiKey960. I am working on that problem. I was actually under the impression that ptm2human can perform etm decoding by specifying the -e option.
I have extracted parts of the README in ptm2human's repo below:
------- ETMv4 ------- 1. Save the ETMv4 trace stream into a file. 2. Give the trace file to ptm2human: $ ptm2human -e -i /path/to/trace/file The result is printed to the stdout. Redirect it to a output file: $ ptm2human -e -i /path/to/trace/file 1> /path/to/output/file 3. Read traces in a human-readable format: $ less output.log Reading TraceDataArmv8_dualcore.dat Decode trace stream of ID 0 Syncing the trace stream... Decoding the trace stream... TraceInfo - Cycle count enabled, Tracing of conditional non-branch instruction disabled, No explicit tracing of load instructions, No explicit tracing of store instructions, p0_key = 0x0, curr_spec_depth = 0, cc_threshold = 0xFF TraceOn - A discontinuity in the trace stream Context - Context ID = 0x56AC1F3E, VMID = 0x2E, Exception level = EL2, Security = NS, 64-bit instruction Address - Instruction address 0x0000000000400954, Instruction set Aarch64
Also, thanks for pointing out the options of disabling CPUidle.
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960. Thanks, Leo Yan Thank you very much for your kind responses and patience! The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Cheers, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
On Tue, 11 Jun 2019 at 20:02, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Hi Mike,
Get Outlook for Android
From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Tuesday, June 11, 2019 10:34:49 PM To: Student - Ng Yi Zher Jeremy Cc: Leo Yan; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
On Mon, 10 Jun 2019 at 21:35, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Leo Yan Sir,
Thank you for your message. Please look at inline comments for reply. ________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did this as per instructed here and I was able to now read the `addr_start` file. However, there is still no trace found when I run the program.
I will like to clarify that addr_start is referring to the instruction address and not the PC counter.
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
I did this command as per usual. I even tried enabling different ETFs and alternating enable ETR to see if there are any difference. There is still no movement in my `rwp`. Even if it did (at the start), when i perform `dd` command, it reads:
hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 32 bytes (32 B) copied, 0.000517 s, 60 K/s
I have attached the encoded trace file (cs.bin), decoded trace file (cs.log_e) and the decoded min trace file (just the addresses line: addr_e.log) in this mail. I used ptm2human API for decoding (link here: https://github.com/hwangcc23/ptm2human).
What puzzled me, furthermore, is that it seems i can never perform `dd` on ec80200.etf. Performing that command on that memory address tends to crash the AOSP in Hikey960.
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I thought i should detail the entire process for your expertise advise:
root@intern-nzyj:/data/cstrace# adb shell hikey960:/ # cd sys/bus/coresight/devices/ hikey960:/sys/bus/coresight/devices # echo 3 > ecc40000.etm/addr_idx hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d65f03c0 > ecc40000.etm/addr_stop 1|hikey960:/sys/bus/coresight/devices # echo 0 ffffffffffffffffff > ecc40000.etm/addr_range 1|hikey960:/sys/bus/coresight/devices # echo 1 > ec036000.etf/enable_sink hikey960:/sys/bus/coresight/devices # echo 1 > ecc40000.etm/enable_source hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/sts 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/ctl 0x1 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # taskset -p 8577 pid 8577's current affinity mask: 1 hikey960:/sys/bus/coresight/devices # taskset -p 8577 taskset: failed to get 8577's affinity: No such process 1|hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rwp 0x7b0 hikey960:/sys/bus/coresight/devices # cat ec036000.etf/mgmt/rrp 0x7b0 hikey960:/sys/bus/coresight/devices # dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M 0+1 records in 0+1 records out 4096 bytes (4.0 K) copied, 0.001610 s, 2.4 M/s hikey960:/sys/bus/coresight/devices # exit root@intern-nzyj:/data/cstrace# adb pull /data/cs.bin /data/cs.bin: 1 file pulled. 0.1 MB/s (4096 bytes in 0.046s) root@intern-nzyj:/data/cstrace# /src/ptm2human/ptm2human -e -i cs.bin > cs.log_e
The ptm2human tools is for PTM tracers while your trancers are ETMv4, as such you will never get anything sane out of it. Also note that CPUidle needs to be disabled if you want CS to work properly on the HiKey960. I am working on that problem.
I was actually under the impression that ptm2human can perform etm decoding by specifying the -e option.
I have extracted parts of the README in ptm2human's repo below:
ETMv4
- Save the ETMv4 trace stream into a file.
- Give the trace file to ptm2human: $ ptm2human -e -i /path/to/trace/file The result is printed to the stdout. Redirect it to a output file: $ ptm2human -e -i /path/to/trace/file 1> /path/to/output/file
- Read traces in a human-readable format: $ less output.log Reading TraceDataArmv8_dualcore.dat Decode trace stream of ID 0 Syncing the trace stream... Decoding the trace stream... TraceInfo - Cycle count enabled, Tracing of conditional non-branch instruction disabled, No explicit tracing of load instructions, No explicit tracing of store instructions, p0_key = 0x0, curr_spec_depth = 0, cc_threshold = 0xFF TraceOn - A discontinuity in the trace stream Context - Context ID = 0x56AC1F3E, VMID = 0x2E, Exception level = EL2, Security = NS, 64-bit instruction Address - Instruction address 0x0000000000400954, Instruction set Aarch64
Interesting - I wonder who added the support for ETMv4. When I looked at it years back it was ETMv3/PTM only. Nevertheless, ptm2human will need to know about the tracer's configuration to properly decode traces. How to do that is something I can't help you with. It will be a real feat (and a very interesting one at that) if you do make it work.
Also, thanks for pointing out the options of disabling CPUidle.
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960. Thanks, Leo Yan Thank you very much for your kind responses and patience! The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Cheers, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Dear Sir,
Please look at inline comments for my reply.
My apologies for such a late reply.
________________________________ From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start I did as per your instruction. I was wondering if it is normal that once I specified a value for addr_start, I am unable to insert a value into addr_stop.
An example of the snippet is found here:
hikey960: # echo 3 > addr_idx hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: 0x0 addr_start: 0x0 addr_stop: 0x0
hikey960: # echo 0x55555557b0 > addr_start hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: Operation not permitted addr_start: 0x55555557b0 addr_stop: Operation not permitted
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly. I have also tried your above suggestion. Currently, I find addr_start and addr_stop traces to better fit what I want rather than addr_range. addr_start and addr_stop will be able to capture traces of what the system perform in terms of context switches, what syscalls it makes, etc.
Regardless, I have tried addr_range and I was able to acquire some traces from my program. I will like to share with you some of my findings because I find the result of the traces to be peculiar in what it has chosen to trace and ignore.
I have switched off ASLR, so I am under the assumption that the instruction address from trace dumps should be similar to that of GDB
=== simple_math_function1.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // many function calls, loop once while (i <= 20){ math(&i); math(&i); math(&i); math(&i); math(&i); printf("%d\n",i); } } =======================
this is a snippet of my decoded trace log: Address - Instruction address 0x0000005555555cf4, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555cfc, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d04, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d0c, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d14, Instruction set Aarch32 (Thumb)
compared against GDB: |0x5555555cf4 <main+972> ldr x0, [sp,#64] |0x5555555cf8 <main+976> bl 0x55555558d8 <math> |0x5555555cfc <main+980> ldr x0, [sp,#64] |0x5555555d00 <main+984> bl 0x55555558d8 <math> |0x5555555d04 <main+988> ldr x0, [sp,#64] |0x5555555d08 <main+992> bl 0x55555558d8 <math> |0x5555555d0c <main+996> ldr x0, [sp,#64] |0x5555555d10 <main+1000> bl 0x55555558d8 <math> |0x5555555d14 <main+1004> ldr x0, [sp,#64]
comparing the gdb and trace dumps, it seems to only trace ldr and ignore bl instructions.
this is the 2nd program, just a slight tweak from the above program:
=== simple_math_function2.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // 1 function call, looped many times while (i <= 20){ math(&i); printf("%d\n",i); } } ======================= trace dump:
Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1
gdb log:
|0x5555555b94 <main+620> ldr x0, [sp,#64] |0x5555555b98 <main+624> bl 0x55555558d8 <math> |0x5555555b9c <main+628> b 0x5555555b78 <main+592> |0x5555555ba0 <main+632> ldr x8, [sp,#64]
This time, i notice that the etm only trace the `b` instructions but not the `ldr` instructions.
I am rather puzzled by the outcome of the traces as I could not understand why the result might be different for a somewhat similar code...
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan Thank you very much for your kindness and assistance the last time!
Also, one last question: I will like to ask how I might be able to activate global timestamp for instruction trace? i noticed trcidr0 supports timestamp (tssize of 64 bits). However, trcconfigr have disabled all my options. Is there a workaround this?
Since perf is still not supported in android, i have been using ptm2human to decode etm dumps. I am also wondering if there are other decoders that I have not explored? From what I have seen, DS-5 seems to request DSTREAM to activate ETM trace and decode the trace dumps. I tried to do it without the DSTREAM and DS-5 was unable to recognise the trace dumps.
Any help will be greatly appreciated!
Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
retHello Jeremy,
On Wed, 10 Jul 2019 at 10:06, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Sir,
Please look at inline comments for my reply.
My apologies for such a late reply.
From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did as per your instruction. I was wondering if it is normal that once I specified a value for addr_start, I am unable to insert a value into addr_stop.
An example of the snippet is found here:
hikey960: # echo 3 > addr_idx hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: 0x0 addr_start: 0x0 addr_stop: 0x0
hikey960: # echo 0x55555557b0 > addr_start hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: Operation not permitted addr_start: 0x55555557b0 addr_stop: Operation not permitted
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I have also tried your above suggestion. Currently, I find addr_start and addr_stop traces to better fit what I want rather than addr_range. addr_start and addr_stop will be able to capture traces of what the system perform in terms of context switches, what syscalls it makes, etc.
Regardless, I have tried addr_range and I was able to acquire some traces from my program. I will like to share with you some of my findings because I find the result of the traces to be peculiar in what it has chosen to trace and ignore.
I have switched off ASLR, so I am under the assumption that the instruction address from trace dumps should be similar to that of GDB
=== simple_math_function1.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // many function calls, loop once while (i <= 20){ math(&i); math(&i); math(&i); math(&i); math(&i); printf("%d\n",i); } } =======================
this is a snippet of my decoded trace log: Address - Instruction address 0x0000005555555cf4, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555cfc, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d04, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d0c, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d14, Instruction set Aarch32 (Thumb)
compared against GDB: |0x5555555cf4 <main+972> ldr x0, [sp,#64] |0x5555555cf8 <main+976> bl 0x55555558d8 <math> |0x5555555cfc <main+980> ldr x0, [sp,#64] |0x5555555d00 <main+984> bl 0x55555558d8 <math> |0x5555555d04 <main+988> ldr x0, [sp,#64] |0x5555555d08 <main+992> bl 0x55555558d8 <math> |0x5555555d0c <main+996> ldr x0, [sp,#64] |0x5555555d10 <main+1000> bl 0x55555558d8 <math> |0x5555555d14 <main+1004> ldr x0, [sp,#64]
Please remember that the decode you are seeing is the decode of trace packets, not full trace decode. Addresses that appear in the packets represent addresses that cannot be deduced otherwise from analysing the program image. No other addresses will appear as part of the trace. Therefore the series of addresses that appear to refer to the LDR instructions above, tell the trace decoder where execution resumes after the return from the "math" routine. The BL instruction requires no address element in the trace as the branch target can be deduced directly from the instructions.
comparing the gdb and trace dumps, it seems to only trace ldr and ignore bl instructions.
this is the 2nd program, just a slight tweak from the above program:
=== simple_math_function2.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // 1 function call, looped many times while (i <= 20){ math(&i); printf("%d\n",i); } } ======================= trace dump:
Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1
gdb log:
|0x5555555b94 <main+620> ldr x0, [sp,#64] |0x5555555b98 <main+624> bl 0x55555558d8 <math> |0x5555555b9c <main+628> b 0x5555555b78 <main+592> |0x5555555ba0 <main+632> ldr x8, [sp,#64]
Again the 0x0000005555555b9c addresses represent the return from the math routine, and not trace for the b 0x5555555b78 <main+592> instruction This b 0x0x5555555b78 is likely represented by the E atom
There is some concern regarding the classification of the AArch32 code as thumb - it would seem from the assembly code that the
These relationships are explained in the ETMv4 TRM - Appendix A, examples of trace.
Regards
Mike
This time, i notice that the etm only trace the `b` instructions but not the `ldr` instructions.
I am rather puzzled by the outcome of the traces as I could not understand why the result might be different for a somewhat similar code...
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kindness and assistance the last time!
Also, one last question: I will like to ask how I might be able to activate global timestamp for instruction trace? i noticed trcidr0 supports timestamp (tssize of 64 bits). However, trcconfigr have disabled all my options. Is there a workaround this?
Since perf is still not supported in android, i have been using ptm2human to decode etm dumps. I am also wondering if there are other decoders that I have not explored? From what I have seen, DS-5 seems to request DSTREAM to activate ETM trace and decode the trace dumps. I tried to do it without the DSTREAM and DS-5 was unable to recognise the trace dumps.
Any help will be greatly appreciated!
Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
Hi Jeremy,
Unfortunately my previous mail appears to have been affected by some formatting problems by my webmail client, so is incomplete.
On Wed, 10 Jul 2019 at 16:07, Mike Leach mike.leach@linaro.org wrote:
retHello Jeremy,
On Wed, 10 Jul 2019 at 10:06, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Sir,
Please look at inline comments for my reply.
My apologies for such a late reply.
From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did as per your instruction. I was wondering if it is normal that once I specified a value for addr_start, I am unable to insert a value into addr_stop.
An example of the snippet is found here:
hikey960: # echo 3 > addr_idx hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: 0x0 addr_start: 0x0 addr_stop: 0x0
hikey960: # echo 0x55555557b0 > addr_start hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: Operation not permitted addr_start: 0x55555557b0 addr_stop: Operation not permitted
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I have also tried your above suggestion. Currently, I find addr_start and addr_stop traces to better fit what I want rather than addr_range. addr_start and addr_stop will be able to capture traces of what the system perform in terms of context switches, what syscalls it makes, etc.
Regardless, I have tried addr_range and I was able to acquire some traces from my program. I will like to share with you some of my findings because I find the result of the traces to be peculiar in what it has chosen to trace and ignore.
I have switched off ASLR, so I am under the assumption that the instruction address from trace dumps should be similar to that of GDB
=== simple_math_function1.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // many function calls, loop once while (i <= 20){ math(&i); math(&i); math(&i); math(&i); math(&i); printf("%d\n",i); } } =======================
this is a snippet of my decoded trace log: Address - Instruction address 0x0000005555555cf4, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555cfc, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d04, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d0c, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d14, Instruction set Aarch32 (Thumb)
compared against GDB: |0x5555555cf4 <main+972> ldr x0, [sp,#64] |0x5555555cf8 <main+976> bl 0x55555558d8 <math> |0x5555555cfc <main+980> ldr x0, [sp,#64] |0x5555555d00 <main+984> bl 0x55555558d8 <math> |0x5555555d04 <main+988> ldr x0, [sp,#64] |0x5555555d08 <main+992> bl 0x55555558d8 <math> |0x5555555d0c <main+996> ldr x0, [sp,#64] |0x5555555d10 <main+1000> bl 0x55555558d8 <math> |0x5555555d14 <main+1004> ldr x0, [sp,#64]
Please remember that the decode you are seeing is the decode of trace packets, not full trace decode. Addresses that appear in the packets represent addresses that cannot be deduced otherwise from analysing the program image. No other addresses will appear as part of the trace. Therefore the series of addresses that appear to refer to the LDR instructions above, tell the trace decoder where execution resumes after the return from the "math" routine. The BL instruction requires no address element in the trace as the branch target can be deduced directly from the instructions.
comparing the gdb and trace dumps, it seems to only trace ldr and ignore bl instructions.
this is the 2nd program, just a slight tweak from the above program:
=== simple_math_function2.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // 1 function call, looped many times while (i <= 20){ math(&i); printf("%d\n",i); } } ======================= trace dump:
Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1
gdb log:
|0x5555555b94 <main+620> ldr x0, [sp,#64] |0x5555555b98 <main+624> bl 0x55555558d8 <math> |0x5555555b9c <main+628> b 0x5555555b78 <main+592> |0x5555555ba0 <main+632> ldr x8, [sp,#64]
Again the 0x0000005555555b9c addresses represent the return from the math routine, and not trace for the b 0x5555555b78 <main+592> instruction This b 0x0x5555555b78 is likely represented by the E atom
There is some concern regarding the classification of the AArch32 code as thumb - it would seem from the assembly code that the
What this should have said was that the assembly code appears to be AArch64 code - registers Xn are an indicator of this. However the decoder you are using appears to be classifying that addresses as AArch32 & Thumb. This could be an issue with the decoder - how are you compiling the code? Is it AArch64?
These relationships are explained in the ETMv4 TRM - Appendix A, examples of trace.
Regards
Mike
This time, i notice that the etm only trace the `b` instructions but not the `ldr` instructions.
I am rather puzzled by the outcome of the traces as I could not understand why the result might be different for a somewhat similar code...
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kindness and assistance the last time!
Also, one last question: I will like to ask how I might be able to activate global timestamp for instruction trace? i noticed trcidr0 supports timestamp (tssize of 64 bits). However, trcconfigr have disabled all my options. Is there a workaround this?
Since perf is still not supported in android, i have been using ptm2human to decode etm dumps. I am also wondering if there are other decoders that I have not explored? From what I have seen, DS-5 seems to request DSTREAM to activate ETM trace and decode the trace dumps. I tried to do it without the DSTREAM and DS-5 was unable to recognise the trace dumps.
Have you looked at OpenCSD (https://github.com/Linaro/OpenCSD) ? This is a trace decode library that will do full decode as well as the packet decode provided by ptm2human.
Regards
Mike
Any help will be greatly appreciated!
Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
Hi Mike,
Thanks for your patience and exceptional response!
________________________________ From: Mike Leach mike.leach@linaro.org Sent: 11 July 2019 17:04 To: Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg Cc: Leo Yan leo.yan@linaro.org; Coresight ML coresight@lists.linaro.org Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Unfortunately my previous mail appears to have been affected by some formatting problems by my webmail client, so is incomplete. Thank you for getting back to me! 🙂
On Wed, 10 Jul 2019 at 16:07, Mike Leach mike.leach@linaro.org wrote:
retHello Jeremy,
On Wed, 10 Jul 2019 at 10:06, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Sir,
Please look at inline comments for my reply.
My apologies for such a late reply.
From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff > ecc40000.etm/addr_start 1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did as per your instruction. I was wondering if it is normal that once I specified a value for addr_start, I am unable to insert a value into addr_stop.
An example of the snippet is found here:
hikey960: # echo 3 > addr_idx hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: 0x0 addr_start: 0x0 addr_stop: 0x0
hikey960: # echo 0x55555557b0 > addr_start hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: Operation not permitted addr_start: 0x55555557b0 addr_stop: Operation not permitted
I thought it was not important that the Operation was 'not permitted'. Nonetheless, I continued with the tutorial as depicted [here](https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I have also tried your above suggestion. Currently, I find addr_start and addr_stop traces to better fit what I want rather than addr_range. addr_start and addr_stop will be able to capture traces of what the system perform in terms of context switches, what syscalls it makes, etc.
Regardless, I have tried addr_range and I was able to acquire some traces from my program. I will like to share with you some of my findings because I find the result of the traces to be peculiar in what it has chosen to trace and ignore.
I have switched off ASLR, so I am under the assumption that the instruction address from trace dumps should be similar to that of GDB
=== simple_math_function1.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // many function calls, loop once while (i <= 20){ math(&i); math(&i); math(&i); math(&i); math(&i); printf("%d\n",i); } } =======================
this is a snippet of my decoded trace log: Address - Instruction address 0x0000005555555cf4, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555cfc, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d04, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d0c, Instruction set Aarch32 (Thumb) Address - Instruction address 0x0000005555555d14, Instruction set Aarch32 (Thumb)
compared against GDB: |0x5555555cf4 <main+972> ldr x0, [sp,#64] |0x5555555cf8 <main+976> bl 0x55555558d8 <math> |0x5555555cfc <main+980> ldr x0, [sp,#64] |0x5555555d00 <main+984> bl 0x55555558d8 <math> |0x5555555d04 <main+988> ldr x0, [sp,#64] |0x5555555d08 <main+992> bl 0x55555558d8 <math> |0x5555555d0c <main+996> ldr x0, [sp,#64] |0x5555555d10 <main+1000> bl 0x55555558d8 <math> |0x5555555d14 <main+1004> ldr x0, [sp,#64]
Please remember that the decode you are seeing is the decode of trace packets, not full trace decode. Addresses that appear in the packets represent addresses that cannot be deduced otherwise from analysing the program image. No other addresses will appear as part of the trace. Therefore the series of addresses that appear to refer to the LDR instructions above, tell the trace decoder where execution resumes after the return from the "math" routine. The BL instruction requires no address element in the trace as the branch target can be deduced directly from the instructions.
Thank you for explaining this to me. I thought it was rather peculiar and I have been reading the ETMv4 TRM over and over again but I could not understand how the ETM was choosing what instructions to trace.
Unfortunately, I have never done tracing before this and the learning curve might have been extraordinary for me at this stage.
comparing the gdb and trace dumps, it seems to only trace ldr and ignore bl instructions.
this is the 2nd program, just a slight tweak from the above program:
=== simple_math_function2.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // 1 function call, looped many times while (i <= 20){ math(&i); printf("%d\n",i); } } ======================= trace dump:
Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb) ATOM - E Commit - 1
gdb log:
|0x5555555b94 <main+620> ldr x0, [sp,#64] |0x5555555b98 <main+624> bl 0x55555558d8 <math> |0x5555555b9c <main+628> b 0x5555555b78 <main+592> |0x5555555ba0 <main+632> ldr x8, [sp,#64]
Again the 0x0000005555555b9c addresses represent the return from the math routine, and not trace for the b 0x5555555b78 <main+592> instruction This b 0x0x5555555b78 is likely represented by the E atom
There is some concern regarding the classification of the AArch32 code as thumb - it would seem from the assembly code that the
What this should have said was that the assembly code appears to be AArch64 code - registers Xn are an indicator of this. However the decoder you are using appears to be classifying that addresses as AArch32 & Thumb. This could be an issue with the decoder - how are you compiling the code? Is it AArch64? Yes, it is actually AArch64. I cross-compiled my programs with android-ndk-20r. I was puzzled with the decoder and I have had my suspicions on the decoding tool as well. I am recently looking closer at the source code of ptm2human in case it might have wrongly classified my trace packets.
These relationships are explained in the ETMv4 TRM - Appendix A, examples of trace.
Regards
Mike
This time, i notice that the etm only trace the `b` instructions but not the `ldr` instructions.
I am rather puzzled by the outcome of the traces as I could not understand why the result might be different for a somewhat similar code...
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kindness and assistance the last time!
Also, one last question: I will like to ask how I might be able to activate global timestamp for instruction trace? i noticed trcidr0 supports timestamp (tssize of 64 bits). However, trcconfigr have disabled all my options. Is there a workaround this?
Since perf is still not supported in android, i have been using ptm2human to decode etm dumps. I am also wondering if there are other decoders that I have not explored? From what I have seen, DS-5 seems to request DSTREAM to activate ETM trace and decode the trace dumps. I tried to do it without the DSTREAM and DS-5 was unable to recognise the trace dumps.
Have you looked at OpenCSD (https://github.com/Linaro/OpenCSD) ? This is a trace decode library that will do full decode as well as the packet decode provided by ptm2human.
Regards
Mike I have taken a peek at OpenCSD previously. But there seems to be more documentations on using OpenCSD integrated with perf than using the libraries standalone.
I might also have confused myself when I saw that the trace decoder will not work if OpenCSD is not integrated with perf from a conference slide made by Mathieu Poirier.
I have attached an image grab from the slide with the line highlighted for easy reference.
[cid:209fcf2f-9674-44ce-b668-42c0203a6c20] reference: https://elinux.org/images/b/b3/Hardware_Assisted_Tracing_on_ARM.pdf
I will love to explore OpenCSD as well. I tinkered it slightly this morning and it seems that a snapshot of the device is required. I am still trying to understand how I might be able to trace and decode with OpenCSD and also how I might be able to obtain a snapshot of my device.
With ptm2human, I am merely extracting the etm dumps from the sinks by using the dd command, extract the trace dump from target device (hikey960 - android) to host device (linux-x86_64) and decode the binary files into a decoded trace file.
Any help will be greatly appreciated!
Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
I will like to also ask how I might be able to change some trcconfig settings. it is found in *.etm/mgmt/trcconfig and it is a read-only file.
I have tried to change the settings through memory mapping and searched for other ways through tweaking with the driver files in drivers/hwtracing/coresight/coresight-etm4x.c
I have been wanting to activate timestamps and/or branch broadcast. In all honesty, I am still trying to understand what exactly branch broadcast is as well.
Really sorry to have bothered you with mediocre and amateurish questions.
Yours Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
HI Jeremy,
On Thu, 11 Jul 2019 at 16:44, Student - Ng Yi Zher Jeremy < jeremy_ng@mymail.sutd.edu.sg> wrote:
Hi Mike,
Thanks for your patience and exceptional response!
*From:* Mike Leach mike.leach@linaro.org *Sent:* 11 July 2019 17:04 *To:* Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg Cc: Leo Yan leo.yan@linaro.org; Coresight ML <coresight@lists.linaro.org
Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi Jeremy,
Unfortunately my previous mail appears to have been affected by some formatting problems by my webmail client, so is incomplete.
Thank you for getting back to me! 🙂
On Wed, 10 Jul 2019 at 16:07, Mike Leach mike.leach@linaro.org wrote:
retHello Jeremy,
On Wed, 10 Jul 2019 at 10:06, Student - Ng Yi Zher Jeremy jeremy_ng@mymail.sutd.edu.sg wrote:
Dear Sir,
Please look at inline comments for my reply.
My apologies for such a late reply.
From: Leo Yan leo.yan@linaro.org Sent: 10 June 2019 17:32 To: Student - Ng Yi Zher Jeremy Cc: Mathieu Poirier; Suzuki K Poulose; Coresight ML Subject: Re: Request for Guidance in Using sysFS for Coresight in
HiKey960 (Cortex A53/A73)
Hi Jeremy,
Please see several quick inline comments.
On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy
wrote:
[...]
-rw-r--r-- 1 root root 4096 1970-01-01 00:11 ecc40000.etm/addr_start hikey960:/sys/bus/coresight/devices # echo d10583ff >
ecc40000.etm/addr_start
1|hikey960:/sys/bus/coresight/devices # cat ecc40000.etm/addr_start cat: ecc40000.etm/addr_start: Operation not permitted
After read the code, I think you need firstly to specify addr_idx:
echo 3 > ecc40000.etm/addr_idx echo d10583ff > ecc40000.etm/addr_start cat ecc40000.etm/addr_start
I did as per your instruction. I was wondering if it is normal that
once I
specified a value for addr_start, I am unable to insert a value into
addr_stop.
An example of the snippet is found here:
hikey960: # echo 3 > addr_idx hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: 0x0 addr_start: 0x0 addr_stop: 0x0
hikey960: # echo 0x55555557b0 > addr_start hikey960: # cat addr* addr_context: 0x0 addr_ctxtype: none addr_idx: 0x3 addr_instdatatype: instr cat: addr_range: Operation not permitted addr_single: Operation not permitted addr_start: 0x55555557b0 addr_stop: Operation not permitted
I thought it was not important that the Operation was 'not
permitted'. Nonetheless, I continued with the tutorial as depicted [here]( https://github.com/torvalds/linux/blob/master/Documentation/trace/coresight....). One thing I will like to note is that my `rwp` did move when i initially activated the sink and source. However, the 2nd time i checked the `rwp`, it went back `0x0`, the same position as that of my `rrp`.
Regardless, I run the program in another kernel, performed CPU
affinity to the program to point at the CPU in which the ETM is activated (in this case, CPU0). While the program is running, i looked at the `rwp/rrp` and see that neither of the pointers are moving. I thought perhaps if i perform `dd` operation, I might be able to get something.
I performed `dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M` but my
device crashed and reboot itself without saving any files.
Could you try below commands before dd command?
echo 1 > /sys/bus/coresight/devices/ec036000.etf # Enable ETM for CPU0 echo 1 > /sys/bus/coresight/devices/ecc40000.etm/enable_source dd if=/dev/ec036000.etf of=/data/cs.bin bs=1M
Please note, you need firstly configure the address range, and then enable the ETM and sink. If afterwards change the address range again, you need disable etf/etm and re-enable etf/etm so can set address range configuration into registers properly.
I have also tried your above suggestion. Currently, I find addr_start and addr_stop traces to better fit what I want rather than addr_range. addr_start and addr_stop will be able to capture traces of what the system perform in terms of context switches, what syscalls it makes, etc.
Regardless, I have tried addr_range and I was able to acquire some traces from my program. I will like to share with you some of my findings because I find the result of the traces to be peculiar in what it has chosen to trace and ignore.
I have switched off ASLR, so I am under the assumption that the instruction address from trace dumps should be similar to that of GDB
=== simple_math_function1.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // many function calls, loop once while (i <= 20){ math(&i); math(&i); math(&i); math(&i); math(&i); printf("%d\n",i); } } =======================
this is a snippet of my decoded trace log: Address - Instruction address 0x0000005555555cf4, Instruction set
Aarch32 (Thumb)
Address - Instruction address 0x0000005555555cfc, Instruction set
Aarch32 (Thumb)
Address - Instruction address 0x0000005555555d04, Instruction set
Aarch32 (Thumb)
Address - Instruction address 0x0000005555555d0c, Instruction set
Aarch32 (Thumb)
Address - Instruction address 0x0000005555555d14, Instruction set
Aarch32 (Thumb)
compared against GDB: |0x5555555cf4 <main+972> ldr x0, [sp,#64] |0x5555555cf8 <main+976> bl 0x55555558d8 <math> |0x5555555cfc <main+980> ldr x0, [sp,#64] |0x5555555d00 <main+984> bl 0x55555558d8 <math> |0x5555555d04 <main+988> ldr x0, [sp,#64] |0x5555555d08 <main+992> bl 0x55555558d8 <math> |0x5555555d0c <main+996> ldr x0, [sp,#64] |0x5555555d10 <main+1000> bl 0x55555558d8 <math> |0x5555555d14 <main+1004> ldr x0, [sp,#64]
Please remember that the decode you are seeing is the decode of trace packets, not full trace decode. Addresses that appear in the packets represent addresses that cannot be deduced otherwise from analysing the program image. No other addresses will appear as part of the trace. Therefore the series of addresses that appear to refer to the LDR instructions above, tell the trace decoder where execution resumes after the return from the "math" routine. The BL instruction requires no address element in the trace as the branch target can be deduced directly from the instructions.
Thank you for explaining this to me. I thought it was rather peculiar and I have been reading the ETMv4 TRM over and over again but I could not understand how the ETM was choosing what instructions to trace.
Unfortunately, I have never done tracing before this and the learning curve might have been extraordinary for me at this stage.
comparing the gdb and trace dumps, it seems to only trace ldr and
ignore bl instructions.
this is the 2nd program, just a slight tweak from the above program:
=== simple_math_function2.c === void math(int *i){ (*i)++; (*i)++; (*i)++; (*i)++; }
main(int i){ // 1 function call, looped many times while (i <= 20){ math(&i); printf("%d\n",i); } } ======================= trace dump:
Address - Instruction address 0x0000005555555b9c, Instruction set
Aarch32 (Thumb)
ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set
Aarch32 (Thumb)
ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set
Aarch32 (Thumb)
ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set
Aarch32 (Thumb)
ATOM - E Commit - 1 Address - Instruction address 0x0000005555555b9c, Instruction set
Aarch32 (Thumb)
ATOM - E Commit - 1
gdb log:
|0x5555555b94 <main+620> ldr x0, [sp,#64] |0x5555555b98 <main+624> bl 0x55555558d8 <math> |0x5555555b9c <main+628> b 0x5555555b78 <main+592> |0x5555555ba0 <main+632> ldr x8, [sp,#64]
Again the 0x0000005555555b9c addresses represent the return from the math routine, and not trace for the b 0x5555555b78 <main+592> instruction This b 0x0x5555555b78 is likely represented by the E atom
There is some concern regarding the classification of the AArch32 code as thumb - it would seem from the assembly code that the
What this should have said was that the assembly code appears to be AArch64 code - registers Xn are an indicator of this. However the decoder you are using appears to be classifying that addresses as AArch32 & Thumb. This could be an issue with the decoder - how are you compiling the code? Is it AArch64?
Yes, it is actually AArch64. I cross-compiled my programs with android-ndk-20r. I was puzzled with the decoder and I have had my suspicions on the decoding tool as well. I am recently looking closer at the source code of ptm2human in case it might have wrongly classified my trace packets.
These relationships are explained in the ETMv4 TRM - Appendix A, examples of trace.
Regards
Mike
This time, i notice that the etm only trace the `b` instructions but not the `ldr` instructions.
I am rather puzzled by the outcome of the traces as I could not
understand why the result might be different for a somewhat similar code...
I don't try at my side, if have any question or issue, please report back so I can test on Hikey960.
Thanks, Leo Yan
Thank you very much for your kindness and assistance the last time!
Also, one last question: I will like to ask how I might be able to activate global timestamp for instruction trace? i noticed trcidr0 supports timestamp (tssize of 64 bits). However, trcconfigr have disabled all my options. Is there a workaround this?
Since perf is still not supported in android, i have been using ptm2human to decode etm dumps. I am also wondering if there are other decoders that I have not explored? From what I have seen, DS-5 seems to request DSTREAM to activate ETM trace and decode the trace dumps. I tried to do it without the DSTREAM and DS-5 was unable to recognise the trace dumps.
Have you looked at OpenCSD (https://github.com/Linaro/OpenCSD) ? This is a trace decode library that will do full decode as well as the packet decode provided by ptm2human.
Regards
Mike
I have taken a peek at OpenCSD previously. But there seems to be more documentations on using OpenCSD integrated with perf than using the libraries standalone.
I might also have confused myself when I saw that the trace decoder will not work if OpenCSD is not integrated with perf from a conference slide made by Mathieu Poirier.
I have attached an image grab from the slide with the line highlighted for easy reference.
*reference*: https://elinux.org/images/b/b3/Hardware_Assisted_Tracing_on_ARM.pdf
This means that the perf trace decode will not work without the OpenCSD
library compiled in.
I will love to explore OpenCSD as well. I tinkered it slightly this morning and it seems that a snapshot of the device is required. I am still trying to understand how I might be able to trace and decode with OpenCSD and also how I might be able to obtain a snapshot of my device.
The snapshot format is defined in the OpenCSD documentation -
./decoder/docs/specs. There are example snapshots included in the decoder/tests directory. Documentation on how to use the library and test programs is available if you compile the documentation into .html format using doxygen.
With ptm2human, I am merely extracting the etm dumps from the sinks by using the dd command, extract the trace dump from target device (hikey960 - android) to host device (linux-x86_64) and decode the binary files into a decoded trace file.
The library will decode trace into executed trace ranges - e..g address 0x1000 to 0x1030. Additional processing is required to further understand the trace - e.g. produce a disassembly of that trace range. This functionality must be provided by the client of the library.
Regards
Mike
Any help will be greatly appreciated!
Sincerely, Jeremy
The above message may contain confidential and/or proprietary
information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
I will like to also ask how I might be able to change some trcconfig settings. it is found in *.etm/mgmt/trcconfig and it is a read-only file.
I have tried to change the settings through memory mapping and searched for other ways through tweaking with the driver files in drivers/hwtracing/coresight/coresight-etm4x.c
I have been wanting to activate timestamps and/or branch broadcast. In all honesty, I am still trying to understand what exactly branch broadcast is as well.
Really sorry to have bothered you with mediocre and amateurish questions.
Yours Sincerely, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.
Hi,
On 10/06/2019 09:49, Student - Ng Yi Zher Jeremy wrote:
Dear Sir,
My apologies for spamming you with more, perhaps ridiculous, questions...
I have been struggling to understand the systematic approach to conduct system traces with sysFS. I have asked similar question to hwangcc23, but I feel this question is suited more for the Linaro team.
I am having trouble choosing the options for the coresight drivers in my Hikey960 device with Cortex A53 and A73 processors, 4 CPUs each. I have created a simple program that is a quick implementation of a link list in C program. The following is the objdump of the main object:
Is there any reason, why you wouldn't use the perf tool ? The perf tool will automatically trace your application as it gets scheduled in/out on the CPU. Using sysfs mode is not ideal for tracing a process.
You may try:
perf record -e cs_etm/@ec033000.etr/ --per-thread <your-application>
Please note that, if your application is multi-threaded, you may need to use the latest version of the kernel/perf tools.
Cheers Suzuki
Dear Suzuki,
________________________________ From: Suzuki K Poulose suzuki.poulose@arm.com Sent: 10 June 2019 18:15 To: Student - Ng Yi Zher Jeremy; mathieu.poirier@linaro.org Cc: coresight@lists.linaro.org Subject: Re: Request for Guidance in Using sysFS for Coresight in HiKey960 (Cortex A53/A73)
Hi,
On 10/06/2019 09:49, Student - Ng Yi Zher Jeremy wrote:
Dear Sir,
My apologies for spamming you with more, perhaps ridiculous, questions...
I have been struggling to understand the systematic approach to conduct system traces with sysFS. I have asked similar question to hwangcc23, but I feel this question is suited more for the Linaro team.
I am having trouble choosing the options for the coresight drivers in my Hikey960 device with Cortex A53 and A73 processors, 4 CPUs each. I have created a simple program that is a quick implementation of a link list in C program. The following is the objdump of the main object:
Is there any reason, why you wouldn't use the perf tool ? The perf tool will automatically trace your application as it gets scheduled in/out on the CPU. Using sysfs mode is not ideal for tracing a process. My apologies for not using perf tool, however I was unable to find a tutorial or source code that allows me to cross-compile perf for Android use.
Android's simpleperf is not able to hook/trace ETM processes.
Nonetheless, I am aware of the existence of perf but not able to implement it in this mini-project of mine due to incompatibility.
You may try:
perf record -e cs_etm/@ec033000.etr/ --per-thread <your-application>
Please note that, if your application is multi-threaded, you may need to use the latest version of the kernel/perf tools.
Cheers Suzuki Thank you very much for your expertise advise! I appreciate it very much.
Cheers, Jeremy
The above message may contain confidential and/or proprietary information that is exempt from disclosure under applicable law and is intended for receipt and use solely by the addressee(s) named above. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this email in error, please inform the sender immediately by reply e-mail or telephone, reversing the charge if necessary. Please delete the message thereafter. Thank you.