Date post: | 13-Jun-2015 |
Category: |
Technology |
Upload: | linaro |
View: | 402 times |
Download: | 1 times |
LCU14 BURLINGAME
Mathieu Poirier, LCU14
LCU14-105: CoreSight Advanced Topics
● Flash review of what we talked about in the introduction session● Porting guide to the CoreSight framework● Problems and Pending Issues
● STM, STM500 and Problem with Channel Management● “Metadata” Representation ● Trace Decoding● Kernel Interface
About this Presentation
● Coresight is a set of IP blocks making HW tracing possible on ARM SoCs
● Blocks can be divided in source, link and sinks.● HW tracing can be highly tuned to trace exactly what is required● Performs better in use cases where power management is
involved● ETM and PTMs provide program flow tracing at the instruction
level● STM allows any entity in the system to log events to channels,
offering a holistic view of what is going on throughout the platform● The coresight framework provides a central point to represent,
configure and manage coresight devices on a platform.
Going back on our Previous Session
A typical Coresight System
● make menuconfig, Kernel Hacking → Coresight Tracing Support[ ] Kernel low-level debugging functions (read help!) [ ] Write the current PID to the CONTEXTIDR register [ ] Set loadable kernel module data as NX and text as RO [*] CoreSight Tracing Support --->
● In the menu, pick the devices found on your system:--- CoreSight Tracing Support -*- CoreSight Link and Sink drivers [*] CoreSight Embedded Trace Macrocell 3.x driver
● If everything goes well individual devices along will show up in debugfs:root@linaro-developer:~# ls /sys/kernel/debug/coresight/00000000.replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etmroot@linaro-developer:~#
Porting Guide - Enabling the Framework
● Example of a DT specification:etb@20010000 { compatible = "arm,coresight-etb10", "arm,primecell";
... reg = <0 0x20010000 0 0x1000>;};
tpiu@20030000 { compatible = "arm,coresight-tpiu", "arm,primecell";
...reg = <0 0x20030000 0 0x1000>;
};
● Component names show up with their memory mapped value:root@linaro-developer:~# ls /sys/kernel/debug/coresight/00000000.replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etmroot@linaro-developer:~#
Porting Guide - DT and Naming Convention
● At this time all the coresight drivers are for generic components, i.e haven’t been modified by their implementer
● This is likely to change rather quickly, the quicker it happens the better it is → less code to convert
● Interested parties can read Documentation/trace/coresight.txt for more information
● Any coresight compliant device can register and unregister with the framework using a couple of APIs:
struct coresight_device *coresight_register(struct coresight_desc *desc);
void coresight_unregister(struct coresight_device *csdev);
Porting Guide - registration API
● Registration typically happens as part of the “probe()” routine of an amba_driver:
Porting Guide - Registration with the Framework
static struct amba_id etb_ids[] = { { .id = 0x0003b907, ← amba ID .mask = 0x0003ffff, }, { 0, 0},};
static struct amba_driver etb_driver = { .drv = { .name = "coresight-etb10", .owner = THIS_MODULE, }, .probe = etb_probe, ← coresight_register() .remove = etb_remove, ← coresight_unregister() .id_table = etb_ids,};
continued →
static int __init etb_init(void){ return amba_driver_register(&etb_driver);}module_init(etb_init);
static void __exit etb_exit(void){ amba_driver_unregister(&etb_driver);}module_exit(etb_exit);
● Everything starts with a coresight_desc:struct coresight_desc { enum coresight_dev_type type; struct coresight_dev_subtype subtype; const struct coresight_ops *ops; struct coresight_platform_data *pdata; struct device *dev; const struct coresight_ops_entry **debugfs_ops; struct module *owner;};
● In the next slides we take a look at the important fields
Porting Guide - type and subtypes
● enum coresight_dev_type type;● identifies what the device is, i.e source, link or sinks
enum coresight_dev_type {
CORESIGHT_DEV_TYPE_NONE, CORESIGHT_DEV_TYPE_SINK, CORESIGHT_DEV_TYPE_LINK, CORESIGHT_DEV_TYPE_LINKSINK, CORESIGHT_DEV_TYPE_SOURCE,};
● struct coresight_dev_subtype subtype:● Characterise the coresight_dev_type further as there can be different kinds of
source, link or sinks/* see include/linux/coresight.h for more details on each subtype */
struct coresight_dev_subtype { enum coresight_dev_subtype_sink sink_subtype; enum coresight_dev_subtype_link link_subtype; enum coresight_dev_subtype_source source_subtype;};
Porting Guide - type and subtypes
● struct coresight_ops *ops: Tells the framework how to perform generic operations for the components:struct coresight_ops_sink { int (*enable)(struct coresight_device *csdev); void (*disable)(struct coresight_device *csdev);};
struct coresight_ops_link { int (*enable)(struct coresight_device *csdev, int iport, int oport); void (*disable)(struct coresight_device *csdev, int iport, int oport);};
struct coresight_ops_source { int (*trace_id)(struct coresight_device *csdev); int (*enable)(struct coresight_device *csdev); void (*disable)(struct coresight_device *csdev);};
struct coresight_ops { const struct coresight_ops_sink *sink_ops; const struct coresight_ops_link *link_ops; const struct coresight_ops_source *source_ops;};
Porting Guide - coresight operations
● struct coresight_ops_entry **debugfs_ops: Operations specific to a particular device.
● Each device is different, as such, this field is necessarystruct coresight_ops_entry { const char *name; umode_t mode; const struct file_operations *ops;};
● Will usually look like:static const struct coresight_ops_entry *etb_attr_grps[] = { &debugfs_trigger_cntr_entry, &debugfs_status_entry, NULL, ← must be NULL terminated};
● Use macro “CORESIGHT_DEBUGFS_ENTRY()” whenever possible to created entries. See include/linux/coresight.h
Porting Guide - debugfs_ops
● struct coresight_platform_data *pdata: handle on the platform data as found in the DTpdata = of_get_coresight_platform_data(dev, np);
● struct device *dev: the device reference as carried by the amba_devicestatic int etm_probe(struct amba_device *adev, const struct amba_id *id){
…
drvdata->dev = &adev->dev;
…
};
● struct module *owner: reflects the information carried by THIS_MODULE
Porting Guide - The Remaining Fields
● With the previous slides in mind, this is what a typical _probe() routine would look like:
desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL); if (!desc) return -ENOMEM;
desc->type = CORESIGHT_DEV_TYPE_SINK; desc->subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER; desc->ops = &etb_cs_ops; desc->pdata = of_get_coresight_platform_data(dev, np); desc->dev = &adev->dev;; desc->debugfs_ops = etb_attr_grps; desc->owner = THIS_MODULE; drvdata->csdev = coresight_register(desc); if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
dev_info(dev, "ETB initialized\n"); return 0;
Putting it all Together
● ITM, STM and STM500 can expose up to 65 536 channels for anyone with access to the AMBA AXI interface to log information
● Can be thought of as a system-wide syslog facility● Problem:
● How to we reserve and use channel between user and kernel space?
● The solution has to take into account devices that don’t use the DT when booting. ex. DSP engine and modems running a proprietary OS.
● What to do with virtualisation and security
● Possible solutions:● Channel specification for each CPU is taken from the DT. From there the kernel
enforces what can be allocated to user space.● Something similar to the Kconfig “Memory split (2G/2G user/kernel split)”
Problems and Pending Issues - STM Channels
● The format of trace packets in the trace stream changes based on whether cycle-accurate tracing is enabled or not.
● cycle accurate tracing modifies the following PFT packets:● I-sync● atom packet● branch and timestamp
● As such the decoder must know about the PFT source’s config● It is also important to have the exact representation of the image in
RAM that we are tracing → self modifying code will cause problems
Problems and Pending Issues - Metadata
● Given a trace dump,how do we collect and attach that information so that decoders can work properly?
● A document has been started that, at least, formalise the problem and the metadata to collect:● http://people.linaro.org/~mathieu.poirier/coresight/cs-decode.pdf
Problems and Pending Issues - Metadata (cont’d)
● As previously discussed in the introduction session, trace decoding tools are not ubiquitous
● ptm2human[1] and etm-objdump[2][3] are certainly a step in the right direction but:● They need enhancement ● They need to be maintained
● DS-5 is very good but comes with a 30-day trial license● Lauderbach Trace32 will punch a hole in the budget● The aim is to come up with a decoding tool capable of dealing with
metadata and produce professional-grade results.
Problems and Pending Issues - Decoding Traces
● The kernel ftrace implementation has a kernel API that offers some trace control, ex ● tracing_on() and tracing_off()● Could “trace_printk()” be used in conjunction with STMs?
● We think it would be desirable to offer the same type of mechanism on the Coresight framework - if so, how much do we expose?● Is it desirable to have an API that list available Coresight components and their
capabilities?● How can we do so, is there something similar somewhere in the kernel?
● How do we trace user space programs?
Problems and Pending Issues - Kernel API
[1]. https://github.com/hwangcc23/ptm2human[2]. http://lists.linaro.org/pipermail/linaro-dev/2012-November/014439.html[3]. http://lists.linaro.org/pipermail/linaro-dev/2012-November/014476.html
Question and Comments
More about Linaro Connect: connect.linaro.org Linaro members: www.linaro.org/membersMore about Linaro: www.linaro.org/about/