Hi Mathieu,
As this is a blocker I pinged a mail to one of the CoreSight architects in case MikeW was not available.
Answers below after my comments.
I would add to this:
a) The difference you are seeing in the two docs is that one doc is the architecture doc - listing all possible fundamental data sizes, the other is an implementation of that architecture with the data size fixed @ 32 bit.
b) Also as I am sure you know, strictly speaking you need to read STMPIDR1[3:0]+ STMPIDR0[7:0] to get the 0x962 (original 32 bit STM implementation) or 0x963 (STM-500 64 bit STM part).
This component ID is not however the best method for determining the fundamental data size. The architectural register STMFEAT2R[15:12] contains this value (DSize). It is feasible that another STM part that is architecturally compliant could come along with a different ID register value, but would have to have the correct entry in STMFEAT2R. This register also contains the information on the availability of guaranteed / invariant timing transactions which I imagine are also useful for the driver.
c) As seen below and from MikeWs comments it is evident that a 64 bit write should not be attempted on a 32 bit system or a 64 bit system running in AArch32 mode. In my view what the driver (or higher level software perhaps) does depends on the purpose/ API definition for the 64 bit write. If you want to generate a 64 bit STPv2 packet (D64[M][TS]) then the driver should refuse and error at this point. It may be acceptable to generate 2x32 bit packets under some circumstances, if the API definition allows for this.
Regards
Mike
=================================================================================== We have 2 implementations of the STM Architecture: a) STM, as documented in ARM DDI 0444B ([2] below). This is a 32-bit STM so has the 32-bit fundamental data size. b) STM-500 as documented in ARM DDI 0528B. This is a 64-bit STM so has the 64-bit fundamental data size.
You are likely to see either STM in 32 or 64-bit systems. We'd have preferred to only see the 64-bit STM in 64-bit systems, but it's not worked out that way unfortunately (e.g. Juno).
- Can an STM fitted on a 32 bit system have a fundamental data size
of 64 bit?
Yes, but see my comments further down.
- Can an STM fitted on a 64 bit system have a fundamental data size of
32 bit?
Yes.
- Can an STM fitted on a 64 bit system have a fundamental data size of
64 bit?
Yes.
- In all of the above cases will STMPIDR0[7:0] still read 0x962?
No. If you see a 64-bit STM-500 it has the part number of 0x963.
The purpose of the fundamental data size indication in the STMs is to indicate whether the STM will take a 64-bit access and generate a D64: - A 32-bit STM will probably generate 2xD32 packets from a 64-bit access, although this should not be relied upon. - A 64-bit STM will take a 64-bit access and generate a D64.
Note that there is no guaranteed way for a 32-bit system (either an ARMv7 core, or an ARMv8 core running in AArch32) to generate a 64-bit access to any STM. This means that even if you find a 64-bit STM in a 32-bit system, you should treat it as a 32-bit STM, and only perform 32-bit accesses. Treating a 64-bit STM as a 32-bit STM is fully compatible (i.e. code written to run on a 32-bit STM will work exactly the same on a 64-bit STM).
---------------------------------------------------------------- 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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Mathieu Poirier Sent: 10 February 2016 18:16 To: Michael Williams Cc: coresight@lists.linaro.org Subject: Re: [PATCH V2 0/6] Introduce CoreSight STM support
Hey Michael,
Have you had time to look into this? I'm afraid that without the information upstreaming of the STM driver can't move ahead.
Thanks, Mathieu.
[...]
This isn't guaranteed to work on the ARM 32 bit architectures. The STM
might receive a 64-bit write, or might receive a pair of 32-bit writes to the two addressed words *in either order*. The upshot is that this is not a valid way of writing to the STM. (The data reordering is a killer.)
The driver appears to use this if there is an STM-500 in an AArch32 system.
This is because the code interrogates the STM to decide whether it supports 64- bit accesses. It should either (a) not do so, and refuse 64-bit data if AArch32, or (b) use some property of the system to decide. I would still frown on (b) because the architecture makes it clear that this is UNPREDICTABLE, meaning you're not supposed to rely on it and the device isn't allowed to advertise its behaviour.
Hey Michael,
The above two paragraphs have been running around in my head all weekend long and I thought it best to clarify things before going any further with regards to upstreaming the driver.
First I did some soul searching in the documentation and found the following:
On page 32 of document [1], it is mentioned that an STM's fundamental data size can be either 32 or 64 bit. On page 3-12 of document [2], it is mentioned that an STM's fundamental data size can only be 32 bit.
From there have the following questions:
- Can an STM fitted on a 32 bit system have a fundamental data size
of 64 bit? 2) Can an STM fitted on a 64 bit system have a fundamental data size of 32
bit?
- Can an STM fitted on a 64 bit system have a fundamental data size of 64
bit?
- In all of the above cases will STMPIDR0[7:0] still read 0x962?
Clarifying the above 4 questions will go a long way.
Many thanks, Mathieu
[1]. ARM IHI 0054B (ID092613) [2]. ARM DDI 0444B (ID010111)
[4] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-
October/297379.html
I hope this is useful.
With kind regards,
Mike.
Michael Williams Principal Engineer ARM Limited www.arm.com The Architecture For The Digital World 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
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.