Hi,
-----Original Message----- From: Mike Leach mike.leach@linaro.org Sent: Monday, September 2, 2019 4:38 PM To: Al Grant Al.Grant@arm.com Cc: Linu Cherian lcherian@marvell.com; coresight@lists.linaro.org; Sunil Kovvuri Goutham sgoutham@marvell.com Subject: [EXT] Re: Tracing and decoding support for trace hardware without trace formatter
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_gui de/prog_guide_main.md
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.
Thanks for the explanation. Will take a look on that.
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
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK