| * Decode Tree API updates. |
| -> Re-factor the decode tree API to: |
| 1) remove the per decoder type creation functions - CreateETMv4Decoder(...), |
| replacing with a single CreateDecoder("Type"). |
| 2) Use new structure to enable custom decoders - may be proprietary / binaries to |
| be used in the decoder structure. |
| 3) Make it easier to add a new decoder to the library source, without the overhead of |
| doing all the creation fns. |
| |
| * STM "full decode". |
| -> This is simply to come up with a generic packet format that will consist of |
| Master+Channel+<payload>, where <payload> is [data]+[TS]+[marker/flag]. This |
| combines a number of packets from the raw STPv2 format. |
| |
| * ETMv4/PTM - decoder updates to handle advanced configuration. |
| -> Certain (currently unused by perf / current hardware) configuration settings |
| can alter the format of the trace output. One example is Return Stack - |
| settable in the control registers for PTM/ETMv4, and removes some inline |
| addresses. Decoder must use a follower to correctly trace when this is set. |
| |
| * ITM packet processing and decode. |
| -> ITM is primarily an M class SW trace module. I wouldn't expect to see it on |
| systems with STM, unless a companion M class was present. |
| |
| *Data trace - ETMv4 / ETMv3 |
| -> Differing solutions to data trace in v4/v3 - v4 is separate trace stream |
| completely, output at trace ID <instruction_trace_ID>+1. ETMv3 is inline with |
| the instruction trace. |
| |
| Cortex-A cores do not support this architecturally. On R and M profile cores it |
| is an option. There are scenrios in future that could see linux on R cores, plus |
| on something like Juno it is possible to switch on trace for the SCP |
| (M class processor). So at some point data trace |