On 13 January 2016 at 05:30, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mathieu,
I've finished the verification of STM master stuff on Juno. We indeed don't need to care about which master the trace data should go from software side.
I think the right statement here is that we don't need to explicitly tell the CS-STM the master ID that will be found in packets. On the flip side and based on knowing exactly how the CS-STM HW behave, we need to understand how the generic STM framework handles master IDs.
From what I recall it uses master IDs to pick out channels and that's
where things get important. Again from what I recall, in the Intel world master IDs are part of the API exposed to users, making them choose which master to use when sending packets. As such the same core could be sending packets using different masters.
Following that scheme we could say that for CS-STM we communicate to the generic STM framework that we have a single (dummy) master ID and 65K channels. That would work but doing so logically splits the 65K channels between all the cores rather than having 65K channels per core as supported by the HW.
I can't emphasise enough on the fact that the above assessment comes from memories that are getting foggier with each passing month. My point here is, please take the time to understand exactly how the generic STM works and how it deals with master IDs.
Thanks, Mathieu
The attachments are the result, one is the trace output from Ftrace another is the decoding result with Mike's CS-STM decoding library.
FYI:
The CPUs and associated STM Mater id on Juno are: CPU Master ID 0 A53 core0 0x44 1 A57 core0 0x40 2 A57 core1 0x41 3 A53 core1 0x45 4 A53 core2 0x46 5 A53 core3 0x47
Regard, Chunyan