123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226 |
- .. SPDX-License-Identifier: GPL-2.0
- =============================================
- CoreSight Embedded Cross Trigger (CTI & CTM).
- =============================================
- :Author: Mike Leach <mike.leach@linaro.org>
- :Date: November 2019
- Hardware Description
- --------------------
- The CoreSight Cross Trigger Interface (CTI) is a hardware device that takes
- individual input and output hardware signals known as triggers to and from
- devices and interconnects them via the Cross Trigger Matrix (CTM) to other
- devices via numbered channels, in order to propagate events between devices.
- e.g.::
- 0000000 in_trigs :::::::
- 0 C 0----------->: : +======>(other CTI channel IO)
- 0 P 0<-----------: : v
- 0 U 0 out_trigs : : Channels ***** :::::::
- 0000000 : CTI :<=========>*CTM*<====>: CTI :---+
- ####### in_trigs : : (id 0-3) ***** ::::::: v
- # ETM #----------->: : ^ #######
- # #<-----------: : +---# ETR #
- ####### out_trigs ::::::: #######
- The CTI driver enables the programming of the CTI to attach triggers to
- channels. When an input trigger becomes active, the attached channel will
- become active. Any output trigger attached to that channel will also
- become active. The active channel is propagated to other CTIs via the CTM,
- activating connected output triggers there, unless filtered by the CTI
- channel gate.
- It is also possible to activate a channel using system software directly
- programming registers in the CTI.
- The CTIs are registered by the system to be associated with CPUs and/or other
- CoreSight devices on the trace data path. When these devices are enabled the
- attached CTIs will also be enabled. By default/on power up the CTIs have
- no programmed trigger/channel attachments, so will not affect the system
- until explicitly programmed.
- The hardware trigger connections between CTIs and devices is implementation
- defined, unless the CPU/ETM combination is a v8 architecture, in which case
- the connections have an architecturally defined standard layout.
- The hardware trigger signals can also be connected to non-CoreSight devices
- (e.g. UART), or be propagated off chip as hardware IO lines.
- All the CTI devices are associated with a CTM. On many systems there will be a
- single effective CTM (one CTM, or multiple CTMs all interconnected), but it is
- possible that systems can have nets of CTIs+CTM that are not interconnected by
- a CTM to each other. On these systems a CTM index is declared to associate
- CTI devices that are interconnected via a given CTM.
- Sysfs files and directories
- ---------------------------
- The CTI devices appear on the existing CoreSight bus alongside the other
- CoreSight devices::
- >$ ls /sys/bus/coresight/devices
- cti_cpu0 cti_cpu2 cti_sys0 etm0 etm2 funnel0 replicator0 tmc_etr0
- cti_cpu1 cti_cpu3 cti_sys1 etm1 etm3 funnel1 tmc_etf0 tpiu0
- The ``cti_cpu<N>`` named CTIs are associated with a CPU, and any ETM used by
- that core. The ``cti_sys<N>`` CTIs are general system infrastructure CTIs that
- can be associated with other CoreSight devices, or other system hardware
- capable of generating or using trigger signals.::
- >$ ls /sys/bus/coresight/devices/etm0/cti_cpu0
- channels ctmid enable nr_trigger_cons mgmt power powered regs
- connections subsystem triggers0 triggers1 uevent
- *Key file items are:-*
- * ``enable``: enables/disables the CTI. Read to determine current state.
- If this shows as enabled (1), but ``powered`` shows unpowered (0), then
- the enable indicates a request to enabled when the device is powered.
- * ``ctmid`` : associated CTM - only relevant if system has multiple CTI+CTM
- clusters that are not interconnected.
- * ``nr_trigger_cons`` : total connections - triggers<N> directories.
- * ``powered`` : Read to determine if the CTI is currently powered.
- *Sub-directories:-*
- * ``triggers<N>``: contains list of triggers for an individual connection.
- * ``channels``: Contains the channel API - CTI main programming interface.
- * ``regs``: Gives access to the raw programmable CTI regs.
- * ``mgmt``: the standard CoreSight management registers.
- * ``connections``: Links to connected *CoreSight* devices. The number of
- links can be 0 to ``nr_trigger_cons``. Actual number given by ``nr_links``
- in this directory.
- triggers<N> directories
- ~~~~~~~~~~~~~~~~~~~~~~~
- Individual trigger connection information. This describes trigger signals for
- CoreSight and non-CoreSight connections.
- Each triggers directory has a set of parameters describing the triggers for
- the connection.
- * ``name`` : name of connection
- * ``in_signals`` : input trigger signal indexes used in this connection.
- * ``in_types`` : functional types for in signals.
- * ``out_signals`` : output trigger signals for this connection.
- * ``out_types`` : functional types for out signals.
- e.g::
- >$ ls ./cti_cpu0/triggers0/
- in_signals in_types name out_signals out_types
- >$ cat ./cti_cpu0/triggers0/name
- cpu0
- >$ cat ./cti_cpu0/triggers0/out_signals
- 0-2
- >$ cat ./cti_cpu0/triggers0/out_types
- pe_edbgreq pe_dbgrestart pe_ctiirq
- >$ cat ./cti_cpu0/triggers0/in_signals
- 0-1
- >$ cat ./cti_cpu0/triggers0/in_types
- pe_dbgtrigger pe_pmuirq
- If a connection has zero signals in either the 'in' or 'out' triggers then
- those parameters will be omitted.
- Channels API Directory
- ~~~~~~~~~~~~~~~~~~~~~~
- This provides an easy way to attach triggers to channels, without needing
- the multiple register operations that are required if manipulating the
- 'regs' sub-directory elements directly.
- A number of files provide this API::
- >$ ls ./cti_sys0/channels/
- chan_clear chan_inuse chan_xtrigs_out trigin_attach
- chan_free chan_pulse chan_xtrigs_reset trigin_detach
- chan_gate_disable chan_set chan_xtrigs_sel trigout_attach
- chan_gate_enable chan_xtrigs_in trig_filter_enable trigout_detach
- trigout_filtered
- Most access to these elements take the form::
- echo <chan> [<trigger>] > /<device_path>/<operation>
- where the optional <trigger> is only needed for trigXX_attach | detach
- operations.
- e.g.::
- >$ echo 0 1 > ./cti_sys0/channels/trigout_attach
- >$ echo 0 > ./cti_sys0/channels/chan_set
- Attaches trigout(1) to channel(0), then activates channel(0) generating a
- set state on cti_sys0.trigout(1)
- *API operations*
- * ``trigin_attach, trigout_attach``: Attach a channel to a trigger signal.
- * ``trigin_detach, trigout_detach``: Detach a channel from a trigger signal.
- * ``chan_set``: Set the channel - the set state will be propagated around
- the CTM to other connected devices.
- * ``chan_clear``: Clear the channel.
- * ``chan_pulse``: Set the channel for a single CoreSight clock cycle.
- * ``chan_gate_enable``: Write operation sets the CTI gate to propagate
- (enable) the channel to other devices. This operation takes a channel
- number. CTI gate is enabled for all channels by default at power up. Read
- to list the currently enabled channels on the gate.
- * ``chan_gate_disable``: Write channel number to disable gate for that
- channel.
- * ``chan_inuse``: Show the current channels attached to any signal
- * ``chan_free``: Show channels with no attached signals.
- * ``chan_xtrigs_sel``: write a channel number to select a channel to view,
- read to show the selected channel number.
- * ``chan_xtrigs_in``: Read to show the input triggers attached to
- the selected view channel.
- * ``chan_xtrigs_out``:Read to show the output triggers attached to
- the selected view channel.
- * ``trig_filter_enable``: Defaults to enabled, disable to allow potentially
- dangerous output signals to be set.
- * ``trigout_filtered``: Trigger out signals that are prevented from being
- set if filtering ``trig_filter_enable`` is enabled. One use is to prevent
- accidental ``EDBGREQ`` signals stopping a core.
- * ``chan_xtrigs_reset``: Write 1 to clear all channel / trigger programming.
- Resets device hardware to default state.
- The example below attaches input trigger index 1 to channel 2, and output
- trigger index 6 to the same channel. It then examines the state of the
- channel / trigger connections using the appropriate sysfs attributes.
- The settings mean that if either input trigger 1, or channel 2 go active then
- trigger out 6 will go active. We then enable the CTI, and use the software
- channel control to activate channel 2. We see the active channel on the
- ``choutstatus`` register and the active signal on the ``trigoutstatus``
- register. Finally clearing the channel removes this.
- e.g.::
- .../cti_sys0/channels# echo 2 1 > trigin_attach
- .../cti_sys0/channels# echo 2 6 > trigout_attach
- .../cti_sys0/channels# cat chan_free
- 0-1,3
- .../cti_sys0/channels# cat chan_inuse
- 2
- .../cti_sys0/channels# echo 2 > chan_xtrigs_sel
- .../cti_sys0/channels# cat chan_xtrigs_trigin
- 1
- .../cti_sys0/channels# cat chan_xtrigs_trigout
- 6
- .../cti_sys0/# echo 1 > enable
- .../cti_sys0/channels# echo 2 > chan_set
- .../cti_sys0/channels# cat ../regs/choutstatus
- 0x4
- .../cti_sys0/channels# cat ../regs/trigoutstatus
- 0x40
- .../cti_sys0/channels# echo 2 > chan_clear
- .../cti_sys0/channels# cat ../regs/trigoutstatus
- 0x0
- .../cti_sys0/channels# cat ../regs/choutstatus
- 0x0
|