Hi,
On Mon, 2 Sep 2019 at 10:59, Al Grant Al.Grant@arm.com wrote:
- Does openCSD tool supports decoding of trace capture from hardware that
has trace formatter disabled.
From the openCSD RRADME, "The library will decode formatted trace in three stages:
Frame Deformatting : Removal CoreSight frame formatting from individual trace streams. Packet Processing : Separate individual trace streams into discrete packets. Packet Decode : Convert the packets into fully decoded trace describing the program flow on a core."
So, is it possible for openCSD to carry out decoding bypassing the first stage mentioned above.
Yes,
https://github.com/Linaro/OpenCSD/blob/master/decoder/docs/prog_guide/prog_g...
says
"In limited cases where the hardware has a single trace source, or only a single source is being used, then it is possible to switch off the hardware frame formatter in the ETB/ETR/TPIU. In this case @ref OCSD_TRC_SRC_SINGLE (from enum @ref ocsd_dcd_tree_src_t) may be defined as the first parameter to the function."
But in general, any ETR that can deal with multiple trace sources should support formatting, otherwise the trace will be corrupt if more than one trace source is enabled. Practically the only reason ever to have an ETR that doesn't support formatting is if the ETR is specific to a single trace source (e.g. one ETR per CPU).
- Linux Coresight ETR driver as part of managing the trace buffer wrap
condition, a barrier packet is written at the beginning which is essentially a Frame synchronization packet. This gives an impression that that ETR driver is making an assumption that the trace formatter is implemented in hardware. Should we not need a fix here, to accommodate hardware configurations that doesn't support trace formatter as well ?
That would be sensible. Even if the ETR does support formatting, in some cases (e.g. the case of one ETR per CPU) there may be a slight bandwidth improvement in turning it off.
The barrier packet here is to deal with the perf mechanics when it saves trace. During a perf session multiple blocks of trace are concatenated together in the trace file making it impossible for the decoder to spot the end of one block and the beginning of a new block when the block has wrapped. The driver inserts these packets to allow for correct decode later. The packet size and format is chosen to make it compatible with frame formatted trace, though there is no assumption inside the driver that the formatter is running.
However, there is an assumption that a formatter is present in the perf decode routines - these set up a decoder from the library with flags to enable both the frame decoder, and the option to look for the barrier packets. The presence of 4 consecutive frame sync packets is used by the decoder to implement a full reset and restart the decode process, and this detection is done in the frame decode part of the process.
Additionally the trace management and decode in perf assumes an association between a trace source ID - as programming into the ETM, and a specific CPU ID in the perf data file in order to ensure that request from the decode to access the loaded program images can be correctly resolved in perf.
Therefore some adjustment to both the library and perf decode is required if you plan to use perf to analyse trace from a system with formatting disabled.
Regards
Mike
Al IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight