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.
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
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
On Wed, Jan 13, 2016 at 11:34 PM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
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
It actually uses master and channel IDs at the same time to determine the output path.
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
Yes, in the Intel world, they do be exposed to users from what I've learnt from the source code.
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
Right, I need to modify the CS-STM driver so that to make only one master can be seen from the software side.
65K channels. That would work but doing so logically splits the 65K
64K actually :)
channels between all the cores rather than having 65K channels per core as supported by the HW.
From what I understand, not all the "cores" split 64K channels, but
stm_source class devices or applications which would use STM to collect traces, can only see one master, it also means that they can only choose channels to use rather than master.
For example, 'stm_ftrace' which is assumed as an STM source device, would collects traces from different cores via Ftrace subsystem, and would write traces into STM through corresponding cores, assume that it was configured to use channel 1, it will actually use the channel 1 on all masters.
In CoreSight world, 64K channels can be allocated, I think that should be enough for the normal usage. I can write a paragraph in the CoreSight STM documentation (if there is) to tell the users to take as few channels as they can, if you think it is necessary.
Thanks, Chunyan
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
On 14 January 2016 at 06:28, Chunyan Zhang zhang.chunyan@linaro.org wrote:
On Wed, Jan 13, 2016 at 11:34 PM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
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
It actually uses master and channel IDs at the same time to determine the output path.
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
Yes, in the Intel world, they do be exposed to users from what I've learnt from the source code.
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
Right, I need to modify the CS-STM driver so that to make only one master can be seen from the software side.
65K channels. That would work but doing so logically splits the 65K
64K actually :)
channels between all the cores rather than having 65K channels per core as supported by the HW.
From what I understand, not all the "cores" split 64K channels, but stm_source class devices or applications which would use STM to collect traces, can only see one master, it also means that they can only choose channels to use rather than master.
For example, 'stm_ftrace' which is assumed as an STM source device, would collects traces from different cores via Ftrace subsystem, and would write traces into STM through corresponding cores, assume that it was configured to use channel 1, it will actually use the channel 1 on all masters.
I'm pretty sure that's what ARM had in mind when statically assigning masterID to sources. Looking at the resulting packet the decoder can use the masterID to identify on which core the packet was generated and the channel for the application/kernel service.
The interesting part is to find a way for the generic STM to understand that scheme. Like Mike suggested we could do some trickery in the STM source device that interfaces with the CS-STM or modify the generic STM to account for masterIDs assigned statically. I'm pretty sure the latter is a superior solution but being more familiar with the code, you are in a better position to make that call.
In CoreSight world, 64K channels can be allocated, I think that should be enough for the normal usage. I can write a paragraph in the CoreSight STM documentation (if there is) to tell the users to take as few channels as they can, if you think it is necessary.
Thanks, Chunyan
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
-
Chunyan Zhang -
Mathieu Poirier