Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
* STM policy management of master/channel:
1. Policy management source code: driver/hwtrace/stm/policy.c
2. Policy management introduce: (excerpts from Documentation/trace/stm.txt) 1) On the receiving end of this STP stream (the decoder side), trace sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
2) To solve this mapping problem, stm class provides a policy management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
3. Create policy rules on target: 1) mount -t configfs none /config (the directory 'stp-policy/' will appear under 'config/')
2) Create policy rule for given STM device： mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
3) Create policy rules for a given stm_source class device: mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
4) After created policy rule, there will be two files 'master' and 'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
4. Allocate one master and a range of channels for stm_source class device: 1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
2) When linking stm_source with STM device happens, the program will poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
5. Allocate master/channels for applictions: 1) Set policy rule which should include 'assigned master', 'first assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13a4eb12f...
Hi,
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
If I have understood this correctly then there is a significant issue here - for the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
This really means that the policy for masters should show only a single master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master. This can then be unpicked by the linux high level STM decoder layer (i.e. not the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c#l745 _______________________________________________ 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.
Hi Mike,
Thanks for reviewing this.
On Thu, Jan 14, 2016 at 9:20 PM, Mike Leach Mike.Leach@arm.com wrote:
Hi,
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
If I have understood this correctly then there is a significant issue here - for the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
Thanks, Chunyan
This really means that the policy for masters should show only a single master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master. This can then be unpicked by the linux high level STM decoder layer (i.e. not the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c#l745 _______________________________________________ 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.
On 14 January 2016 at 13:27, Chunyan Zhang zhang.chunyan@linaro.org wrote:
On Thu, Jan 14, 2016 at 9:20 PM, Mike Leach Mike.Leach@arm.com wrote:
If I have understood this correctly then there is a significant issue
here - for the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
I guess it's worth explicitly separating the application visible model from the hardware model, saying that we may do things like simplify the view the application has of the system in order to handle hardware requirements like this?
On Thu, Jan 14, 2016 at 10:26 PM, Mark Brown broonie@linaro.org wrote:
On 14 January 2016 at 13:27, Chunyan Zhang zhang.chunyan@linaro.org wrote:
On Thu, Jan 14, 2016 at 9:20 PM, Mike Leach Mike.Leach@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
I guess it's worth explicitly separating the application visible model from the hardware model, saying that we may do things like simplify the view the application has of the system in order to handle hardware requirements like this?
From the user view, how to show master to the users do you think is
more clear and more easier to understand this kind of hardware requirements (i.e. users are not able to choose master) for users? Would it be better if hiding "master" ABI from users for this kind of hardware configuration?
Thanks, Chunyan
On 15 January 2016 at 10:50, Chunyan Zhang zhang.chunyan@linaro.org wrote:
On Thu, Jan 14, 2016 at 10:26 PM, Mark Brown broonie@linaro.org wrote:
I guess it's worth explicitly separating the application visible model
from
the hardware model, saying that we may do things like simplify the view
the
application has of the system in order to handle hardware requirements
like
this?
From the user view, how to show master to the users do you think is more clear and more easier to understand this kind of hardware requirements (i.e. users are not able to choose master) for users? Would it be better if hiding "master" ABI from users for this kind of hardware configuration?
I don't know for sure - I don't know to what extent the users *have* to know this stuff and to what extent we can simplify so that they can have a model they work with that will work regardless of the underlying hardware.
If I have understood this correctly then there is a significant issue here - for
the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
But you need to support the common subset. Configurable masters aren't going to work on ARM (as Mike says) so the framework needs to not assume they are. The rules can just map trace sources to channels and not masters.
On Intel how is the source CPU indicated in the trace? On ARM you can have, for example, kernel trace from all the cores simultaneously outputting independent trace messages to STM, using the same channel range, and the CPU can be identified by master id, allowing the high-level decoder to reconstruct the trace messages output from each CPU. Does that work on Intel too or is it required that when a trace source is outputting on several CPUs concurrently, each CPU has a separate channel range (this also assumes that the trace source is pinned to CPUs)?
Al
Thanks, Chunyan
This really means that the policy for masters should show only a single
master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master.
This can then be unpicked by the linux high level STM decoder layer (i.e. not
the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from
Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13 a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c# l745 _______________________________________________ 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. _______________________________________________ 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.
On Fri, Jan 15, 2016 at 8:40 PM, Al Grant Al.Grant@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for
the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
But you need to support the common subset. Configurable masters aren't going to work on ARM (as Mike says) so the framework needs to not assume they are. The rules can just map trace sources to channels and not masters.
Agree, that's just what I mentioned in another email. I'm planning to hide "masters" from users for this kind of hardware configuration via revising generic STM framework code.
On Intel how is the source CPU indicated in the trace? On ARM you can
I have no idea on this either so far.
have, for example, kernel trace from all the cores simultaneously outputting independent trace messages to STM, using the same channel range, and the CPU can be identified by master id, allowing the high-level decoder to reconstruct the trace messages output from each CPU. Does that work on
Yes, understand.
Intel too or is it required that when a trace source is outputting on several CPUs concurrently, each CPU has a separate channel range (this also assumes that the trace source is pinned to CPUs)?
I have to learn more about this further, and then may be able to answer this, thanks for your questions which would push me to think/learn more.
Thanks, Chunyan
Al
Thanks, Chunyan
This really means that the policy for masters should show only a single
master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master.
This can then be unpicked by the linux high level STM decoder layer (i.e. not
the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from
Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13 a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c# l745 _______________________________________________ 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. _______________________________________________ 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.
Hi Al and others,
I think I've found the answer of how is the source CPU indicated in the Intel STH trace data, and I would like to share with you here.
On Fri, Jan 15, 2016 at 8:40 PM, Al Grant Al.Grant@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for
the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
But you need to support the common subset. Configurable masters aren't going to work on ARM (as Mike says) so the framework needs to not assume they are. The rules can just map trace sources to channels and not masters.
On Intel how is the source CPU indicated in the trace? On ARM you can
The following words are copied from Chapter 4 of the attached documentation.
The Software Trace Hub (STH) is one of the trace data sources feeding data into the Global Trace Hub (GTH) component of the Intel ® Trace Hub architecture, as shown in Figure 3. It is the means by which a device, often a CPU or micro-controller, can send debug messages over the system fabric to the GTH to be collected, encoded, time stamped, and later sent to a trace destination. Trace destinations can be either off-chip (for example, a high-speed trace port) or on-chip (for example, system memory).
Debug messages can include Intel ® Processor Trace (PT) data, which can be sent to the STH when Intel ® PT hardware in the CPU is configured to direct its output to Intel Trace Hub MMIO space as explained elsewhere in this document. It can also include regular (non-PT) software and firmware trace data, such as the message from a Linux kernel printk instruction or application printf instructions. Hereafter, non-PT data will be referred to simply as software trace data or regular software data. Software messages are not limited to software running on the CPU core(s); they can also be sent from other microcontrollers running firmware, so long as they can master one of the interfaces to the STH (primary or sideband fabric).
Thanks, Chunyan
have, for example, kernel trace from all the cores simultaneously outputting independent trace messages to STM, using the same channel range, and the CPU can be identified by master id, allowing the high-level decoder to reconstruct the trace messages output from each CPU. Does that work on Intel too or is it required that when a trace source is outputting on several CPUs concurrently, each CPU has a separate channel range (this also assumes that the trace source is pinned to CPUs)?
Al
Thanks, Chunyan
This really means that the policy for masters should show only a single
master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master.
This can then be unpicked by the linux high level STM decoder layer (i.e. not
the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from
Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13 a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c# l745 _______________________________________________ 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. _______________________________________________ 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.
Hi Al and others,
I think I've found the answer of how is the source CPU indicated in the Intel STH trace data, and I would like to share with you here.
On Fri, Jan 15, 2016 at 8:40 PM, Al Grant Al.Grant@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for
the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
But you need to support the common subset. Configurable masters aren't going to work on ARM (as Mike says) so the framework needs to not assume they are. The rules can just map trace sources to channels and not masters.
On Intel how is the source CPU indicated in the trace? On ARM you can
The following words are copied from the Chapter 4 of [1].
The Software Trace Hub (STH) is one of the trace data sources feeding data into the Global Trace Hub (GTH) component of the Intel ® Trace Hub architecture, as shown in Figure 3. It is the means by which a device, often a CPU or micro-controller, can send debug messages over the system fabric to the GTH to be collected, encoded, time stamped, and later sent to a trace destination. Trace destinations can be either off-chip (for example, a high-speed trace port) or on-chip (for example, system memory).
Debug messages can include Intel ® Processor Trace (PT) data, which can be sent to the STH when Intel ® PT hardware in the CPU is configured to direct its output to Intel Trace Hub MMIO space as explained elsewhere in this document. It can also include regular (non-PT) software and firmware trace data, such as the message from a Linux kernel printk instruction or application printf instructions. Hereafter, non-PT data will be referred to simply as software trace data or regular software data. Software messages are not limited to software running on the CPU core(s); they can also be sent from other microcontrollers running firmware, so long as they can master one of the interfaces to the STH (primary or sideband fabric).
Thanks, Chunyan
[1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-develo...
have, for example, kernel trace from all the cores simultaneously outputting independent trace messages to STM, using the same channel range, and the CPU can be identified by master id, allowing the high-level decoder to reconstruct the trace messages output from each CPU. Does that work on Intel too or is it required that when a trace source is outputting on several CPUs concurrently, each CPU has a separate channel range (this also assumes that the trace source is pinned to CPUs)?
Al
Thanks, Chunyan
This really means that the policy for masters should show only a single
master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master.
This can then be unpicked by the linux high level STM decoder layer (i.e. not
the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
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: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from
Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13 a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c# l745 _______________________________________________ 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. _______________________________________________ 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.
-
Al Grant -
Chunyan Zhang -
Mark Brown -
Mike Leach