So I was correct - this isn't something that can be read or deduced from a CS register - it comes from the platform.
Many thanks, Mathieu
On 9 December 2015 at 07:46, Mike Leach Mike.Leach@arm.com wrote:
The lingering question I still have is how you were able do deduce the master IDs of the different components on the Juno board. Enlightenment on that front would be greatly appreciated.
In this particular case, I read the Juno manual!
Now available in ARM Infocentre as : Juno r2 ARM Development Platform SoC TRM - ARMDDI0515E. section 2.9.5
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 09 December 2015 14:38 To: Mike Leach Cc: Chunyan Zhang; coresight@lists.linaro.org Subject: Re: STM masters/channels from hardware view
Good day Mike,
Many thanks for the detailed explanation - there is a lot of good information in what you wrote.
In the conversation I had with Chunyan I was raising the importance of understanding the meaning of master IDs in a CS context. Back to the time I was working on STM I had come to the conclusion they were related to HW components, something your email confirmed.
The lingering question I still have is how you were able do deduce the master IDs of the different components on the Juno board. Enlightenment on that front would be greatly appreciated.
Best regards, Mathieu
On 9 December 2015 at 04:11, Mike Leach Mike.Leach@arm.com wrote:
Hi Chunyan,
From what I have understood, I think STM masters/channels are a continuous physical space in STM, a bit like registers on this point.
This is not necessarily true - channels are a continuous memory space,
masters may be hardwired differently. This is platform implementation dependent.
The masters and channels may be a continuous space from the STM
hardware view, but not from the system memory view
A single master with the maximum of 65536 channels @ 256 bytes per
channel will take up 16MB (0x0100 0000) of memory locations.
Where the full 128 masters are mapped across a continuous memory space
then the total taken is 2GB (0x8000 0000) -> half the available memory space!
Therefore ARM strongly recommends that the slave address signals
AWADDRS[29:24] on the AXI input to the STM (which form the low 6 bits of the master ID) are not directly wired to the AXI memory bus, but are uniquely driven according to the master accessing the bus. This, combined with the PROTS input (forming the MSBit of the master ID) creates a unique master ID for each hardware master, differentiating between secure and non-secure accesses.
An example of this is the Juno platform. All masters on this platform see a
single 16MB master memory region of 65536 channels at the same effective memory address. The unique Master ID is formed according to which master is accessing the STM.
In the case of Juno the masters are:- 2xA72, 4xA53, Mali-GPU, M3-SCP,
8xExpansion masters, a default master and the DAP AXI-AP.
Thus on Juno, a secure STM write from A72_0 will appear on master ID 0, a
none secure STM write from A72_0 will appear on master ID 64.
Similarly A72_1 will use 1 and 65, the A53s 4-7, and 68-71 and so on.
Although the STM has a potential 128 masters, not all may be used, and they
may not be assigned contiguously. (on Juno secure master IDs 2-3, 8-31, 42-61 and the same range for non-secure {+64} are all reserved)
Therefore on Juno the software cannot select a master - only a channel. The
master will depend on which core the code is running on, and the secure/non- secure state of that core.
So in general for CS-STM software drivers and client applications:- i) It is highly likely that the STM software cannot select the master ID to
write to - this is determined by the core and security state that is currently executing the code.
ii) STM software can select the channel to be used for a given client function.
Therefore if a client function such as kernel ftrace is assigned channel 33 for example, it will then appear on channel 33 on any core that is using it, and therefore on any of the master IDs that are associated with cores.
iii) any application wanting to consume data from an STM client must
therefore monitor the given channel on all possible masters.
The TRM documents that CS-STM has 129 masters, 128 for software, each supporting 65536 channels. And my question is :
The CS-STM has 128 masters - one of these masters can be used for the
optional implementation dependent hardware event interface. The master used for the HW event interface is either hardwired at design time or controlled by the STMHEMASTR register.
- How much physical space each channel should take?
Always 256 bytes.
- Do the channels dump the trace packets in real time?
The packets can be generated in a time invariant or guaranteed manner.
Guaranteed packets will stall the AXI bus write until the STM can accept a
traced packet.
Time invariant packets will complete the write immediately. If the STM
cannot accept a trace packet then the packet will be dropped and an error packet generated as soon as the STM is able to accept further packets.
The packet type and timing type are selected by the address written in the
256 byte channel space.
An STM implementation is not required to support both types of write
timings. Therefore if an STM only supports time invariant writes, then any writes to the guaranteed locations will succeed but actually be time invariant.
- Is it correct that set total 0x180000 byte space for 128 masters
and 128*65536 channels?
This depends on your hardware configuration - though this does look too
small for a full 65536 channels. Number of implemented channels is defined by STMDEVID register.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Chunyan Zhang [mailto:zhang.chunyan@linaro.org] Sent: 09 December 2015 06:50 To: Mike Leach; Mathieu Poirier Cc: coresight@lists.linaro.org Subject: STM masters/channels from hardware view
Hi Mike, Mathieu
I've been reading STM driver and its device tree configurations along with the specifications recently.
Yesterday, Mathieu asked me a question about the true definition of STM masters. This morning, I read code and spec again. There's still a few details need to ask Mike.
Mike, please correct me if anything what I'm writing here is wrong.
From what I have understood, I think STM masters/channels are a continuous physical space in STM, a bit like registers on this point. On my Spreadtrum's board, for example, we are configuring 0x180000 byte space for stimulus ports (i.e. channels). The TRM documents that CS-STM has 129 masters, 128 for software, each supporting 65536 channels. And my question is :
- How much physical space each channel should take?
- Do the channels dump the trace packets in real time?
- Is it correct that set total 0x180000 byte space for 128 masters
and 128*65536 channels?
Thank you, Chunyan
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.
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.