Hello,
We are using coresight to dump compressed stream through ETR into a 16MB buffer in RAM. (The platform is nVidia TX2) To gather data from the buffer we are using the Linux dd command:
dd if=/dev/8050000.etr of=~/coresightdata.bin
The issue is that during the copying of the data, the coresight recording becomes disabled (which shouldn't really be the case since its a circular buffer), so we are having some blind spots in the recordings for the duration of the copying of data from RAM into a file.
Is there any way to prevent this from happening? Maybe to set up some kind of ping-pong scheme, or to specify somehow that coresight shouldn't stop recording while accessing the ETR buffer?
Thank you.
Srdjan Stokic
Mobile: +389-78-835-505
Hi,
On Tue, 1 Oct 2019 at 09:58, Srdjan Stokic srdjan.stokic@gmail.com wrote:
Hello,
We are using coresight to dump compressed stream through ETR into a 16MB buffer in RAM. (The platform is nVidia TX2) To gather data from the buffer we are using the Linux dd command:
dd if=/dev/8050000.etr of=~/coresightdata.bin
The issue is that during the copying of the data, the coresight recording becomes disabled (which shouldn't really be the case since its a circular buffer), so we are having some blind spots in the recordings for the duration of the copying of data from RAM into a file.
The ETR (TMC) hardware requires that capture be stopped or disabled to read stable versions of the RWP and RRP pointers - which are used to determine the start and end of captured data - and if the buffer has wrapped.
Is there any way to prevent this from happening? Maybe to set up some kind of ping-pong scheme, or to specify somehow that coresight shouldn't stop recording while accessing the ETR buffer?
If trace capture were to continue during the read process, then there is no guarantee that the data being read would not be overwritten with new data while the read is continuing. This would lead to corruption of the trace data. As you say, a ping-pong scheme could theoretically be implemented - which would perhaps reduce the loss during the copy operation by restarting trace capture into a new buffer while the read from the full buffer continues, but this is not built into the current driver software and would require significant effort if it was indeed possible. Additionally, if the new buffer was to wrap before the read operation on the old buffer was compete then there would still be the loss of some trace data.
Best Regards
Mike
Thank you.
Srdjan Stokic
Mobile: +389-78-835-505 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight