Hi,
We have an ARM v8 based SOC that has got Marvell's ARM trace implementation, with the Trace formatter disabled. ie. FFSR[FtNotPresent] in ETR register space reports 0b1.
Have couple of queries related to the tracing and decoding of this hardware configuration.
1. 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.
2. 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 ?
Thanks. Linu Cherian
- 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.
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.
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
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
Hi,
-----Original Message----- From: Al Grant Al.Grant@arm.com Sent: Monday, September 2, 2019 3:29 PM To: Linu Cherian lcherian@marvell.com; coresight@lists.linaro.org Cc: Sunil Kovvuri Goutham sgoutham@marvell.com Subject: [EXT] RE: Tracing and decoding support for trace hardware without trace formatter
- 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).
Yes. We have 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.
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.
[...]
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).
Yes. We have one ETR per CPU.
I am very surprised (and thrilled) to see such topology emerging. Unfortunately it also means you will not be able to use the current coresight infrastructure (kernel and user space) without _serious_ refactoring. Your platform wouldn't happen to be in the public domain by any chance? Or perhaps Marvell would be interested in shipping a board to a selected group of people? That would help with both development and testing.
Thanks, Mathieu
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Wednesday, September 4, 2019 8:39 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil Kovvuri Goutham sgoutham@marvell.com Subject: [EXT] Re: Tracing and decoding support for trace hardware without trace formatter
[...]
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).
Yes. We have one ETR per CPU.
I am very surprised (and thrilled) to see such topology emerging. Unfortunately it also means you will not be able to use the current coresight infrastructure (kernel and user space) without _serious_ refactoring. Your platform wouldn't happen to be in the public domain by any chance? Or perhaps Marvell would be interested in shipping a board to a selected group of people? That would help with both development and testing.
Thanks for the help Mathieu. At this point of time, due to some internal reasons we may not be able to ship the board or provide access to them. But we would be happy to test any patches if any.
Thanks, Mathieu
On Thu, 5 Sep 2019 at 11:22, Linu Cherian lcherian@marvell.com wrote:
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Wednesday, September 4, 2019 8:39 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil Kovvuri Goutham sgoutham@marvell.com Subject: [EXT] Re: Tracing and decoding support for trace hardware without trace formatter
[...]
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).
Yes. We have one ETR per CPU.
I am very surprised (and thrilled) to see such topology emerging. Unfortunately it also means you will not be able to use the current coresight infrastructure (kernel and user space) without _serious_ refactoring. Your platform wouldn't happen to be in the public domain by any chance? Or perhaps Marvell would be interested in shipping a board to a selected group of people? That would help with both development and testing.
Thanks for the help Mathieu. At this point of time, due to some internal reasons we may not be able to ship the board or provide access to them. But we would be happy to test any patches if any.
The problem here is that refactoring is so extensive that it would be impossible for me to send you patches. To be efficient I would need a board to work with. Please let me know if and when the boards become available. Note that it would also be possible to sign an exclusive NDA with Marvell if need be.
Thanks, Mathieu
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Thursday, September 5, 2019 11:01 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil Kovvuri Goutham sgoutham@marvell.com Subject: Re: [EXT] Re: Tracing and decoding support for trace hardware without trace formatter
On Thu, 5 Sep 2019 at 11:22, Linu Cherian lcherian@marvell.com wrote:
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Wednesday, September 4, 2019 8:39 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil
Kovvuri
Goutham sgoutham@marvell.com Subject: [EXT] Re: Tracing and decoding support for trace hardware
without
trace formatter
[...]
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).
Yes. We have one ETR per CPU.
I am very surprised (and thrilled) to see such topology emerging. Unfortunately it also means you will not be able to use the current coresight infrastructure (kernel and user space) without _serious_ refactoring. Your platform wouldn't happen to be in the public domain by any chance? Or perhaps Marvell would be interested in shipping a board to a selected group of people? That would help with both development and testing.
Thanks for the help Mathieu. At this point of time, due to some internal reasons we may not be able to
ship the board
or provide access to them. But we would be happy to test any patches if any.
The problem here is that refactoring is so extensive that it would be impossible for me to send you patches. To be efficient I would need a board to work with. Please let me know if and when the boards become available. Note that it would also be possible to sign an exclusive NDA with Marvell if need be.
Understand your point about the difficulty in testing when the changes are huge. But I would like to clarify that we wont be able to ship/share the board for internal reasons. Sorry about that.
Thanks, Mathieu
On Mon, 9 Sep 2019 at 09:41, Linu Cherian lcherian@marvell.com wrote:
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Thursday, September 5, 2019 11:01 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil Kovvuri Goutham sgoutham@marvell.com Subject: Re: [EXT] Re: Tracing and decoding support for trace hardware without trace formatter
On Thu, 5 Sep 2019 at 11:22, Linu Cherian lcherian@marvell.com wrote:
Hi,
-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: Wednesday, September 4, 2019 8:39 PM To: Linu Cherian lcherian@marvell.com Cc: Al Grant Al.Grant@arm.com; coresight@lists.linaro.org; Sunil
Kovvuri
Goutham sgoutham@marvell.com Subject: [EXT] Re: Tracing and decoding support for trace hardware
without
trace formatter
[...]
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).
Yes. We have one ETR per CPU.
I am very surprised (and thrilled) to see such topology emerging. Unfortunately it also means you will not be able to use the current coresight infrastructure (kernel and user space) without _serious_ refactoring. Your platform wouldn't happen to be in the public domain by any chance? Or perhaps Marvell would be interested in shipping a board to a selected group of people? That would help with both development and testing.
Thanks for the help Mathieu. At this point of time, due to some internal reasons we may not be able to
ship the board
or provide access to them. But we would be happy to test any patches if any.
The problem here is that refactoring is so extensive that it would be impossible for me to send you patches. To be efficient I would need a board to work with. Please let me know if and when the boards become available. Note that it would also be possible to sign an exclusive NDA with Marvell if need be.
Understand your point about the difficulty in testing when the changes are huge. But I would like to clarify that we wont be able to ship/share the board for internal reasons. Sorry about that.
Very well - let me know if that changes.
Thanks, Mathieu
-
Al Grant -
Linu Cherian -
Mathieu Poirier -
Mike Leach