Hi Joey

I do not understand what you mean by "triggering BB".

BB - branch broadcast is generally only used in cases of self modifying code - as it increases the amount of addresses appearing in the trace data and thus the amount of trace generated for a given program traced. This will fill up any trace buffer far more quickly than normal and may cause issues with overflows. The address range that BB is used over can be constrained using TRCBBCTRL

Regards

Mike

On Wed, 11 Dec 2019 at 06:23, Joey Jiao joeyjiaojg@163.com wrote:

One of my collegue points me that ETM BB cannot give me the branch address if the BB triggered, is that true?

I will continue to investigate OpenCSD, but above query will be important to my investigation.

At 2019-12-11 00:54:45, "Mathieu Poirier" mathieu.poirier@linaro.org wrote:

...

I strongly advise _not_ using ptm2human unless you are very proficient with coresight, its compression protocol and ptm2human itself. Otherwise any output from ptm2human should be considered faulty.

Mathieu

On Tue, 10 Dec 2019 at 04:07, Mike Leach mike.leach@linaro.org wrote:

...

Hi Joey,

Please provide more information on the problems you are encountering and any errors you are seeing. Without this I cannot investigate further.

1. How are you attempting to use OpenCSD to decode this file? The

trc_pkt_lister test program will provide the same packet decode as PTMtoHuman but does require additional context to ensure that the decode is correct. This involves providing the raw data and certain ETMv4 registers in a "trace snapshot" format. The library comes with examples in this format and a specification for this format in the documentation.

2. If you wish to go beyond packet decode then OpenCSD can do that -

but you will need to provide additional program image data - again in the snapshot format described above.

Thanks & Regards

Mike

On Tue, 10 Dec 2019 at 07:55, Joey Jiao joeyjiaojg@163.com wrote:

...

Hi Mike, I cannot attach the dump into github, so I have to ask here.

OpenCSD cannot decode the etm binary attached, however an opensource ETM decoder https://github.com/hwangcc23/ptm2human can parse.

Can you help understand why?

And is there any bug in OpenCSD?

Thanks

Joey

-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

HI Joey,

On Wed, 11 Dec 2019 at 04:44, Joey Jiao joeyjiaojg@163.com wrote:

Hi Mike, Thanks for you reply, I did notice those snapshots, but don't understand what to provide there. For example I'm not familiar with below ini content if my device is using Cortex-A53 and what the regs for these registers and how to get the kernel_dump.bin.

But I searched kernel documentation which also mentioned to use ptm2human. So let me try that tool at the moment.

BTW, is ETM able to get user space address? I think the OpenCSD perf documented so, but I can only get some kernel address from ptm2human. 0x0000000000000000, 0xffffff9c7d4ff094, 0xffffff9c7d566198, 0xffffff9c7e0f758c,

ETM will trace all address ranges by default. However the range of addresses you see in any output will depend on the size of the sink buffer in use - it is possible that this has wrapped and you are seeing only kernel addresses in the data.

[device] name=cpu_0 class=core type=Cortex-A53

[regs] PC(size:64)=0xFFFFFFC000081000 SP(size:64)=0 SCTLR_EL1=0x1007 CPSR=0x1C5

[dump1] file=kernel_dump.bin address=0xFFFFFFC000081000 length=0x00050000

This is only one of a number of files that make up a snapshot - this describes a CPU and memory images / programs that were present during the trace session. There can be multiple dump sections. In the case of the CPU registers these are not important for trace decode, however in files that describe etm devices the registers are required to ensure correct decode in all circumstances. The format of snapshots is explained in the document OpenCSD/master/decoder/docs/specs/ARM Trace and Debug Snapshot file format 0v2.pdf . The docs/prog_guide/prog_guide_main.md contains an introduction to coresight trace debug. The explains the 3 stages of decode. 1) Trace frames to individual trace streams 2) trace streams to trace packets - these contain atoms and addresses - the level of trace decode provided by ptm2human. 3) trace packets to full trace decode - this stage needs the program images to determine the actual instructions traced.

I would advise reading these two documents along with the ETMv4 specification to understand how coresight trace decode works.

Regards

Mike

At 2019-12-10 19:07:25, "Mike Leach" mike.leach@linaro.org wrote:

...

Hi Joey,

Please provide more information on the problems you are encountering and any errors you are seeing. Without this I cannot investigate further.

1. How are you attempting to use OpenCSD to decode this file? The

trc_pkt_lister test program will provide the same packet decode as PTMtoHuman but does require additional context to ensure that the decode is correct. This involves providing the raw data and certain ETMv4 registers in a "trace snapshot" format. The library comes with examples in this format and a specification for this format in the documentation.

2. If you wish to go beyond packet decode then OpenCSD can do that -

but you will need to provide additional program image data - again in the snapshot format described above.

Thanks & Regards

Mike

On Tue, 10 Dec 2019 at 07:55, Joey Jiao joeyjiaojg@163.com wrote:

...

Hi Mike, I cannot attach the dump into github, so I have to ask here.

OpenCSD cannot decode the etm binary attached, however an opensource ETM decoder https://github.com/hwangcc23/ptm2human can parse.

Can you help understand why?

And is there any bug in OpenCSD?

Thanks

Joey

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