Hi Mike,

Thanks you for your quick and relevant response.

You are right, the problems came from different sources :

- into the script, the PTM is activated before the beginning of the “targeted” user application and that explain why we have a bunch of others application's traces before the “targeted application” (bash interpreter, loader, linker, etc…) I solved that by enabling and disabling the PTM into the “_start" and “exit" functions in the LibC (musl libc) and linking statically the application.

- We also found some errors in the trace decoder that we fixed. (problems with waypoints packets, etc…) Now we are using the ETB in order to make sur that there is no problem int he Coresight configuration side.

In order to filter traces and receiving only traces from the targeted application, I enable Context IDI woth the mode bellow into the script :

# Broadcast Branch and Context ID echo -n 30 > $PTM_CPU_0/mode

Despite the fact that I configured the address range (addr_range) with the .text addresses (0x100e0 to 0x15140) and configured ctxid_idx to 0 and ctxpid_pid with the PID of the targeted application, I still receive others traces…

For example, when launching the script with the ETB and decoding it with ptm2human, I have the traces below :

…. instruction addr at 0x147c0, ARM state, secure state, context ID 0x31440, instruction addr at 0x14784, ARM state, secure state, context ID 0x3123d, ….

Is it the right way to configure the Coresight components for filtering traces with the given address range and the PID of the targeted application ?

Best regards,

Mounir

On 14 Jun 2019, at 12:48, Mike Leach mike.leach@linaro.org wrote:

Hi,

If we look at few key lines in your script....

# Turn off cpu 1 to make sure the program will be launched on cpu 0 echo -n 0 > $CPU_1/online

; OK - but now everything is running on CPU0, including this script....

echo -n 1 > $PTM_CPU_0/enable_source

; trace starts here - so you are tracing anything withing the address range, including any code that executes as part of this script that lies within the range.

# Run binary $EXEC 3

; to run binary the OS must process this script line, load the program into the address and start it - any code executed as part of this procedure that falls within the address range will be traced.

... so you could well be tracing a lot of code you did not intend to.

I don't know the limits of your custom, buffer, or the process you are using to decode, but my guess would be that you see the program addresses at the end of the trace as you run out of space due to everything that was traced before it.

An application such as perf traces a specific program either by only switching on trace on the cpu as the program is scheduled (--per-thread), or by using CPU wide trace and tracing with context ID to extract only the relevant trace from the full traced data.

Regards

Mike

On Fri, 14 Jun 2019 at 01:34, Nasr allah Mounir <nasrallah.mounir@icloud.com mailto:nasrallah.mounir@icloud.com> wrote:

...

Hello,

I am trying to trace a statically linked application on my ZedBoard (Zynq-7000 SoC). Please find attached the ELF file and the assembler file of the application.

For the context:

• The CPU0 runs at 333 MHz
• The TPIU runs at 200 MHz
• The PL (FPGA) runs at 250 MHz

For tracing the application, I use the attached script.sh file, which mainly:

• Disable the CPU1
• Setting up the address comparator
• Activate the Branch Broadcast mode
• Specify the address range to trace
• Activate the PTM and the TPIU
• Execute the application
• Retrieve the trace in a dedicated BRAM memory in the PL.

When I trace the whole .text section (from 0x100e0 to 0x15140) I receive incomplete and inconsistent traces, for example:

00 9c 148d4 15d4c 10db4 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 147c0 b6f78030 14784 b6f6f3c8 13ecc b6f9df44 14704 b6f6f3c8 14784 b6f6f3c8 13d08 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 14784 b6f6f3c8 13ecc b6f9df44 14784 b6f6f3c8 14784 b6f6f3c8 13d88 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 10104 10128 105d0 10390 136a0 00 00 00 00 00 00 00 00

Note that the addresses (10104 10128 105d0 10390 136a0) in bold above correspond to:

10104 _start ( entry point ) 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset

1. How the entry point can end up at the end of the traces?

But when I trace a tiny interval of the .text section, for example from 0x100e0 to 0x136ac, I receive correct traces.

00 10104 10128 105d0 10390 136a0 10338 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 10420 10468 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10488 138b4 10490 10388 10498 1048c 10404 1049c 10590 105f8 10598 100d4 100a4 10008 1fff0010 1fff009c 105bc 10214 1023c 10198 105c4 105fc 102c4 102a0 10300 1361c 13658 10310 10270 102b8 10330 10650 10698 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 10820 10810 10868 13318 108c8 108e4 10920 10968 10980 109c0 10a0c 10a68 10b20 10b34 10ba4 10ba0 10bec 10d20 13468 134e4 106ec 1070c 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 ………………

These addresses correspond to:

10104 _start 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset 10338 103c4 Loop in __init_libc ….. 103e8 Loop in __init_libc …. 102c4 main …

2. Is there a limitation for the traced address range ? The only difference between those traces is the addr_range value:

For tracing the whole .text section : echo -n 0x100e0 0x15140 > $PTM_CPU_0/addr_range For tracing a tiny interval in the .text section echo -n 0x100e0 0x136ac > $PTM_CPU_0/addr_range

If there is no limitation, what can explain this behaviour? A wrong configuration of the Coresight Components?

Kind Regards,

Mounir NASR ALLAH

---

CoreSight mailing list CoreSight@lists.linaro.org mailto:CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight https://lists.linaro.org/mailman/listinfo/coresight

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

On Wed, 26 Jun 2019 at 08:25, Mike Leach mike.leach@linaro.org wrote:

Hi Mounir,

On Fri, 21 Jun 2019 at 15:44, Nasr allah Mounir nasrallah.mounir@icloud.com wrote:

...

Hi Mike,

Thanks you for your quick and relevant response.

You are right, the problems came from different sources :

• into the script, the PTM is activated before the beginning of the “targeted” user application and that explain why we have a bunch of others application's traces before the “targeted application” (bash interpreter, loader, linker, etc…) I solved that by enabling and disabling the PTM into the “_start" and “exit" functions in the LibC (musl libc) and linking statically the application.

• We also found some errors in the trace decoder that we fixed. (problems with waypoints packets, etc…) Now we are using the ETB in order to make sur that there is no problem int he Coresight configuration side.

In order to filter traces and receiving only traces from the targeted application, I enable Context IDI woth the mode bellow into the script :

# Broadcast Branch and Context ID echo -n 30 > $PTM_CPU_0/mode

Despite the fact that I configured the address range (addr_range) with the .text addresses (0x100e0 to 0x15140) and configured ctxid_idx to 0 and ctxpid_pid with the PID of the targeted application, I still receive others traces…

For example, when launching the script with the ETB and decoding it with ptm2human, I have the traces below :

…. instruction addr at 0x147c0, ARM state, secure state, context ID 0x31440, instruction addr at 0x14784, ARM state, secure state, context ID 0x3123d, ….

Is it the right way to configure the Coresight components for filtering traces with the given address range and the PID of the targeted application ?

You need to program the PTM to use the relevant contextID compare register either as an enable event. or as part of the address range comparison.

So if you have programmed your address range with 0x100e0 to 0x15140, you must ensure that the address comparator access type registers include the context comparator as part of the range so that match only occurs on (0x100e0 to 0x15140) && ContextID.

See the TRM for details.

A common cause of problem is also the kernel itself where CONTEXTID tracking needs to be enabled:

$ make menuconfig

"Kernel hacking" > "Write the current PID to the CONTEXTIDR register"

Regards

Mike

...

Best regards,

Mounir

On 14 Jun 2019, at 12:48, Mike Leach mike.leach@linaro.org wrote:

Hi,

If we look at few key lines in your script....

# Turn off cpu 1 to make sure the program will be launched on cpu 0 echo -n 0 > $CPU_1/online

; OK - but now everything is running on CPU0, including this script....

echo -n 1 > $PTM_CPU_0/enable_source

; trace starts here - so you are tracing anything withing the address range, including any code that executes as part of this script that lies within the range.

# Run binary $EXEC 3

; to run binary the OS must process this script line, load the program into the address and start it - any code executed as part of this procedure that falls within the address range will be traced.

... so you could well be tracing a lot of code you did not intend to.

I don't know the limits of your custom, buffer, or the process you are using to decode, but my guess would be that you see the program addresses at the end of the trace as you run out of space due to everything that was traced before it.

An application such as perf traces a specific program either by only switching on trace on the cpu as the program is scheduled (--per-thread), or by using CPU wide trace and tracing with context ID to extract only the relevant trace from the full traced data.

Regards

Mike

On Fri, 14 Jun 2019 at 01:34, Nasr allah Mounir nasrallah.mounir@icloud.com wrote:

Hello,

I am trying to trace a statically linked application on my ZedBoard (Zynq-7000 SoC). Please find attached the ELF file and the assembler file of the application.

For the context:

• The CPU0 runs at 333 MHz
• The TPIU runs at 200 MHz
• The PL (FPGA) runs at 250 MHz

For tracing the application, I use the attached script.sh file, which mainly:

• Disable the CPU1
• Setting up the address comparator
• Activate the Branch Broadcast mode
• Specify the address range to trace
• Activate the PTM and the TPIU
• Execute the application
• Retrieve the trace in a dedicated BRAM memory in the PL.

When I trace the whole .text section (from 0x100e0 to 0x15140) I receive incomplete and inconsistent traces, for example:

00 9c 148d4 15d4c 10db4 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 147c0 b6f78030 14784 b6f6f3c8 13ecc b6f9df44 14704 b6f6f3c8 14784 b6f6f3c8 13d08 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 14784 b6f6f3c8 13ecc b6f9df44 14784 b6f6f3c8 14784 b6f6f3c8 13d88 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 10104 10128 105d0 10390 136a0 00 00 00 00 00 00 00 00

Note that the addresses (10104 10128 105d0 10390 136a0) in bold above correspond to:

10104 _start ( entry point ) 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset

1. How the entry point can end up at the end of the traces?

But when I trace a tiny interval of the .text section, for example from 0x100e0 to 0x136ac, I receive correct traces.

00 10104 10128 105d0 10390 136a0 10338 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 10420 10468 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10488 138b4 10490 10388 10498 1048c 10404 1049c 10590 105f8 10598 100d4 100a4 10008 1fff0010 1fff009c 105bc 10214 1023c 10198 105c4 105fc 102c4 102a0 10300 1361c 13658 10310 10270 102b8 10330 10650 10698 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 10820 10810 10868 13318 108c8 108e4 10920 10968 10980 109c0 10a0c 10a68 10b20 10b34 10ba4 10ba0 10bec 10d20 13468 134e4 106ec 1070c 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 ………………

These addresses correspond to:

10104 _start 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset 10338 103c4 Loop in __init_libc ….. 103e8 Loop in __init_libc …. 102c4 main …

2. Is there a limitation for the traced address range ? The only difference between those traces is the addr_range value:

For tracing the whole .text section : echo -n 0x100e0 0x15140 > $PTM_CPU_0/addr_range For tracing a tiny interval in the .text section echo -n 0x100e0 0x136ac > $PTM_CPU_0/addr_range

If there is no limitation, what can explain this behaviour? A wrong configuration of the Coresight Components?

Kind Regards,

Mounir NASR ALLAH

---

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 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight

Good morning,

On Thu, 27 Jun 2019 at 05:05, Nasr allah Mounir nasrallah.mounir@icloud.com wrote:

Hi Mike and Mathieu,

Thank you very much for your response, the problem is resolved.

With the actual drivers, programming addr_range permit to automatically filter traces depending of the given addresses. I thought that programming ctxid_pid into the driver enables the filtering of traces as well, but that is not the case.

I also discover that ctxid_pid should be left shifted by 8 bits because into traces the value is the same than CONTEXTIDR :

—————————————————— | PID | ASID | ——— 24 bits —————— 8 bits ——

Due to the fact that there is no guaranty that ASID doesn’t change during the process execution, I mask those 8 bits by programming the ContextID comparator Mask ( ctxid_mask )

Are you potentially interested for a patch ?

Up to now there hasn't been a strong usecase for contextID tracing and as such the feature may need adjustment. If you want to send a patch make sure to do so following the linux kernel standard. You also need to clearly demonstrate the problem being fixed and how to reproduce the failure. Also note that I can't review patches that are directly sent to me - you will have to CC either the CS mailing list, the linux-arm-kernel mailing list or both.

Thanks, Mathieu

Best regards,

Mounir

On 26 Jun 2019, at 18:03, Mathieu Poirier mathieu.poirier@linaro.org wrote:

On Wed, 26 Jun 2019 at 08:25, Mike Leach mike.leach@linaro.org wrote:

Hi Mounir,

On Fri, 21 Jun 2019 at 15:44, Nasr allah Mounir nasrallah.mounir@icloud.com wrote:

Hi Mike,

Thanks you for your quick and relevant response.

You are right, the problems came from different sources :

• into the script, the PTM is activated before the beginning of the “targeted” user application and that explain why we have a bunch

of others application's traces before the “targeted application” (bash interpreter, loader, linker, etc…) I solved that by enabling and disabling the PTM into the “_start" and “exit" functions in the LibC (musl libc) and linking statically the application.

• We also found some errors in the trace decoder that we fixed. (problems with waypoints packets, etc…)

Now we are using the ETB in order to make sur that there is no problem int he Coresight configuration side.

In order to filter traces and receiving only traces from the targeted application, I enable Context IDI woth the mode bellow into the script :

# Broadcast Branch and Context ID echo -n 30 > $PTM_CPU_0/mode

Despite the fact that I configured the address range (addr_range) with the .text addresses (0x100e0 to 0x15140) and configured ctxid_idx to 0 and ctxpid_pid with the PID of the targeted application, I still receive others traces…

For example, when launching the script with the ETB and decoding it with ptm2human, I have the traces below :

…. instruction addr at 0x147c0, ARM state, secure state, context ID 0x31440, instruction addr at 0x14784, ARM state, secure state, context ID 0x3123d, ….

Is it the right way to configure the Coresight components for filtering traces with the given address range and the PID of the targeted application ?

You need to program the PTM to use the relevant contextID compare register either as an enable event. or as part of the address range comparison.

So if you have programmed your address range with 0x100e0 to 0x15140, you must ensure that the address comparator access type registers include the context comparator as part of the range so that match only occurs on (0x100e0 to 0x15140) && ContextID.

See the TRM for details.

A common cause of problem is also the kernel itself where CONTEXTID tracking needs to be enabled:

$ make menuconfig

"Kernel hacking" > "Write the current PID to the CONTEXTIDR register"

Regards

Mike

Best regards,

Mounir

On 14 Jun 2019, at 12:48, Mike Leach mike.leach@linaro.org wrote:

Hi,

If we look at few key lines in your script....

# Turn off cpu 1 to make sure the program will be launched on cpu 0 echo -n 0 > $CPU_1/online

; OK - but now everything is running on CPU0, including this script....

echo -n 1 > $PTM_CPU_0/enable_source

; trace starts here - so you are tracing anything withing the address range, including any code that executes as part of this script that lies within the range.

# Run binary $EXEC 3

; to run binary the OS must process this script line, load the program into the address and start it - any code executed as part of this procedure that falls within the address range will be traced.

... so you could well be tracing a lot of code you did not intend to.

I don't know the limits of your custom, buffer, or the process you are using to decode, but my guess would be that you see the program addresses at the end of the trace as you run out of space due to everything that was traced before it.

An application such as perf traces a specific program either by only switching on trace on the cpu as the program is scheduled (--per-thread), or by using CPU wide trace and tracing with context ID to extract only the relevant trace from the full traced data.

Regards

Mike

On Fri, 14 Jun 2019 at 01:34, Nasr allah Mounir nasrallah.mounir@icloud.com wrote:

Hello,

I am trying to trace a statically linked application on my ZedBoard (Zynq-7000 SoC). Please find attached the ELF file and the assembler file of the application.

For the context:

• The CPU0 runs at 333 MHz
• The TPIU runs at 200 MHz
• The PL (FPGA) runs at 250 MHz

For tracing the application, I use the attached script.sh file, which mainly:

• Disable the CPU1
• Setting up the address comparator
• Activate the Branch Broadcast mode
• Specify the address range to trace
• Activate the PTM and the TPIU
• Execute the application
• Retrieve the trace in a dedicated BRAM memory in the PL.

When I trace the whole .text section (from 0x100e0 to 0x15140) I receive incomplete and inconsistent traces, for example:

00 9c 148d4 15d4c 10db4 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 13ecc b6fa3f44 14568 b6f85720 148d4 b6fa5d4c 147c0 b6f78030 14784 b6f6f3c8 13ecc b6f9df44 14704 b6f6f3c8 14784 b6f6f3c8 13d08 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 14784 b6f6f3c8 13ecc b6f9df44 14784 b6f6f3c8 14784 b6f6f3c8 13d88 b6f9ea70 13d88 b6f9ea70 13c68 b6f99484 14628 b6f994b4 1485c b6fa0174 1452c b6faa2c4 14094 b6fabcb0 142b0 b6fab754 10104 10128 105d0 10390 136a0 00 00 00 00 00 00 00 00

Note that the addresses (10104 10128 105d0 10390 136a0) in bold above correspond to:

10104 _start ( entry point ) 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset

1. How the entry point can end up at the end of the traces?

But when I trace a tiny interval of the .text section, for example from 0x100e0 to 0x136ac, I receive correct traces.

00 10104 10128 105d0 10390 136a0 10338 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103c4 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 103e8 10420 10468 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10480 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10464 10488 138b4 10490 10388 10498 1048c 10404 1049c 10590 105f8 10598 100d4 100a4 10008 1fff0010 1fff009c 105bc 10214 1023c 10198 105c4 105fc 102c4 102a0 10300 1361c 13658 10310 10270 102b8 10330 10650 10698 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 10820 10810 10868 13318 108c8 108e4 10920 10968 10980 109c0 10a0c 10a68 10b20 10b34 10ba4 10ba0 10bec 10d20 13468 134e4 106ec 1070c 10810 13318 108c8 108e4 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 108e0 ………………

These addresses correspond to:

10104 _start 10128 _ start_c 105d0 __libc_start_main 10390 __init_libc 136a0 memset 10338 103c4 Loop in __init_libc ….. 103e8 Loop in __init_libc …. 102c4 main …

2. Is there a limitation for the traced address range ? The only difference between those traces is the addr_range value:

For tracing the whole .text section : echo -n 0x100e0 0x15140 > $PTM_CPU_0/addr_range For tracing a tiny interval in the .text section echo -n 0x100e0 0x136ac > $PTM_CPU_0/addr_range

If there is no limitation, what can explain this behaviour? A wrong configuration of the Coresight Components?

Kind Regards,

Mounir NASR ALLAH

---

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 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight