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
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 0echo -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 addressrange, including any code that executes as part of this script thatlies within the range.# Run binary$EXEC 3; to run binary the OS must process this script line, load the programinto the address and start it - any code executed as part of thisprocedure 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 areusing to decode, but my guess would be that you see the programaddresses at the end of the trace as you run out of space due toeverything that was traced before it.An application such as perf traces a specific program either by onlyswitching on trace on the cpu as the program is scheduled(--per-thread), or by using CPU wide trace and tracing with context IDto extract only the relevant trace from the full traced data.RegardsMikeOn 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 LeachPrincipal Engineer, ARM Ltd.Manchester Design Centre. UK