Greetings,
I'm trying to enable the Coresight ETMv4 trace from kernel mode. I saw
there is no documentation on how to do this, except using the sysfs user
mode interface and perf.
To overcome this i looked a little bit in the coresight.h header file, and
came to these APIs:
> extern int coresight_enable(struct coresight_device *csdev);
>
> extern void coresight_disable(struct coresight_device *csdev);
And the sysfs implementation uses these APIs when enabing/disabling the
trace code, so i thought this could suit my needs. The next problem was
actually getting the coresight devices data structures, which aren't
exported and are actually provided internally to perf and sysfs. So i
exported the coresight bus type:
struct bus_type coresight_bustype = {
>
> .name = "coresight",
>
> };
>
> EXPORT_SYMBOL(coresight_bustype);
And enumerated the bus and just looked for the
type CORESIGHT_DEV_TYPE_SOURCE, since the only source on my board is ETMv4,
there isn't any conflicts so i should get only ETMv4s.
This worked, and indeed i collected a coresight device for every CPU, and
enabled the trace successfully while being in *non-atomic context*.
The problem is, i must enable the trace in *atomic context synchronously *on
the current thread's CPU(i can't issue a work-queue to enable the trace for
me). So.. i got many BUG() errors because of non-atomic API usage, for
example, the allocation of the TMC-ETR buffer:
> dma_alloc_coherent(drvdata->dev, etr_buf->size,
> &flat_buf->daddr, *GFP_KERNEL*);
So my questions are:
1) Is there a more documented way of enabling coresight from kernel mode? i
believe i achieved this using cheats.
2) I see there is no exported kernel API to config the coresight trace
attributes(for example, filter EL0). I can only do so from sysfs.. am i
missing something?
3) Are there any plans to make the Coresight infrastructure atomic-context
friendly?
If there are, is the development in progress? if not.. how would you
suggest tackling the issues i've described in this message?
Thank you!
Hi,
I have followed procedure to integrate libopenCSD in perf tool in target ARM. (based on kernel 4.18rc1)
I’ve seen in documentation that perf record need parameters cs_etm/(a)xxxxx.etr/u …<mailto:cs_etm/@xxxxx.etr/u%20…>
I would like to know if ETR device is mandatory to use coresight trace with perf ?
In my architecture, I’ve :
1 .funnel
1 .tpiu
2 .etm
1 .etf
1 .stm
1 replicator but no ETR ☹
If possible without ETR, do you have examples of perf record cmd usage ?
I’ve configured my coresight register as followed :
echo 1 > /sys/bus/coresight/devices/xxxx.stm/hwevent_select
echo 2 > /sys/bus/coresight/devices/xxxx.stm/hwevent_extmux_select
// Need to track IRQ up of UART
echo 0x200000 > /sys/bus/coresight/devices/xxxx.stm/hwevent_enable
echo 1 > /sys/bus/coresight/devices/yyyy.etf/enable_sink
echo 1 > /sys/bus/coresight/devices/xxxx.stm/enable_source
Which perf record cmd I must enter to catch my STM event ?
Thanks for your help.
Christophe.
Hi Mike, Mathieu,
[ + CoreSight ML ]
When I work on the CoreSight + perf tool and used crash extension
program to extract the tracing data from perf aux buffer, finally I
can get the trace data for about 1.6MB from ETF sink from DB410c board.
To verify the extracted trace data, I used 'snapshot' mode under
OpenCSD code base, you could see the tar file for this [1]. After
you download this file, you could place it under OpenCSD folder:
$ cp db410c_snapshot_kdump.tgz my_opencsd/decoder/tests/snapshots
$ cd my_opencsd/decoder/tests/snapshots
$ tar zxvf db410c_snapshot_kdump.tgz
$ cd db410c_snapshot_kdump
$ ../../bin/builddir/trc_pkt_lister
$ ../../bin/builddir/trc_pkt_lister -decode
If I use the command 'trc_pkt_lister' without any extra options, it
can print out trace packets successfully; but if I add the extra
option '-decode' it uses 'decode all' mode and it reports the errors as:
483710 Idx:53086; ID:10; [0xf8 ]; I_ATOM_F3 : Atom format 3.; NNN
483711 Idx:53086; ID:10; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0xffff000008abc9f0 )
483712 Idx:53088; ID:10; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE
483713 Idx:53194; ID:10; [0x6b 0x8c 0x08 0xfa 0xdc 0x95 0x5c ]; I_COND_RES_F1 : Conditional Result, format 1.
483714 DCD_ETMV4_0016 : 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Data Path fatal error
483715 0x0018 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; Unsupported packet type.Trace Packet Lister : Trace buffer done, processed 53216 bytes.
You also could check detailed log trc_pkt_lister.ppl in the shared
tar packet; After searched for the OpenCSD code and found this error is
due it cannot support some types of packets [2].
So want to check what's the best for this issue; seems to me we need
to fix this so it can support well to complete the decoding?
Thanks in advance for suggestion.
Leo Yan
[1] http://people.linaro.org/~leo.yan/opencsd_db410c/db410c_snapshot_kdump.tgz
[2] https://github.com/Linaro/OpenCSD/blob/master/decoder/source/etmv4/trc_pkt_…