Hi Jeremy,

On Fri, 2 Aug 2019 at 03:00, Jeremy Ng ngyzj95@gmail.com wrote:

Hi Mike,

Thank you for your reply!

On Thu, Aug 1, 2019 at 1:09 AM Mike Leach mike.leach@linaro.org wrote:

...

Hi Jeremy,

The trc_pkt_lister app uses a mapping from core name to determine architecture version and core profile. A73 was not included inthe version of the library you are using, but it has been updated in v0.12.0 released today.

Thank you for updating me on this information. I have tried it with Cortex-A73 and it works!

...

On Thu, 25 Jul 2019 at 10:44, Jeremy Ng ngyzj95@gmail.com wrote:

...

Dear Mike,

I will like to ask you for guidance on using openCSD.

I was trying to use and understand trc_pkt_lister from demos and notice that snapshot of the device is required (hikey960 device is used here).

I have also tried looking at the programmer's guide for openCSD but I am confused with what I am required to do.

Nevertheless, I tried running trc_pkt_lister in the hikey960 snapshot folder and it gave me this error:

Trace Packet Lister : reading snapshot from path ./ Using ETR_0 as trace source ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_4. ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_5. ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_6. ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Unrecognized Core name Cortex-A73. Cannot evaluate profile or architecture.ss2_dcdtree : 0x0025 (OCSD_ERR_TEST_SS_TO_DECODER) [test snapshot to decode tree conversion error]; Failed to create decoder for source ETM_7. Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x10 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x12 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x14 Trace Packet Lister : Protocol printer ETMV4I on Trace ID 0x16 Trace Packet Lister : Error : Unable to open trace buffer

I am not exactly sure if there is a proper software to perform snapshots/kernel dump/reading registers values. I also thought it worthy to note that the snapshot files are made in reference to the juno-uname-002 demo project.

On another note, I will like to ask if it is possible to use openCSD to decode just the trace binary dumps without the need for snapshots.

If you write your own application to use the library then you can specify whatever input format you wish to provide the correct data for the library.

What level of decode are you looking for? If you want to simply convert the trace binaries into simple packet listings like ptmtohuman, then far less information is needed. For a full trace decode however both configuration information and program images are required for decode.

The snapshots provide a format that manages this information and is easy to use for the library test programs such as trc_pkt_lister.

May I inquire how I might go about doing that?

I am have gotten a snapshot of my device, thanks to Leo Yan, however, I will like to understand how the information in the snapshot was acquired.

Especially the following values: In cpu_0.ini:

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

How was the value for PC, SP, SPCTLR_EL1 and CPSR acquired?

The original snapshot this was based on was generated by DS-5 - which requires these values. These are not needed for tracing.

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

How do I acquire kernel_dump.bin and how was the address and length decided?

Address and length was chosen arbitrarily as a demo for trace decode. The memory for this demo was dumped from a live system using an external debug tool.

The snapshot specification is provided in decoder\docs\specs.

Binary dumps can be taken from live systems or can be program / library binaries with addresses and lengths set to the load addresses during the trace session.

If you look in the ./tests/snapshots/juno-uname-002 directory you will see multiple binary dumps, each representing the loaded elements during the trace session.

Regards

Mike

My apologies for the amateurish questions.

Regards, Jeremy

...

Regrds

Mike

...

Any assistance will be appreciated

Cheers, Jeremy

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