Hi Jeremy,

Please see several quick inline comments.

On Mon, Jun 10, 2019 at 08:49:48AM +0000, Student - Ng Yi Zher Jeremy wrote:

[...]

> ```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
> ```

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

> 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.txt). 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){
}

    while (i <= 20){
    }

}

=======================

this is a snippet of my decoded trace log:
    Address - Instruction address 0x0000005555555cf4, Instruction set Aarch32 (Thumb)
    Address - Instruction address 0x0000005555555d14, Instruction set Aarch32 (Thumb)

compared against GDB:

    |0x5555555cf4 <main+972>         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 ===

trace dump:

Address - Instruction address 0x0000005555555b9c, Instruction set Aarch32 (Thumb)
Commit - 1

gdb log:

|0x5555555b94 <main+620> ldr    x0, [sp,#64]
|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