Resource: LCA14 Name: LCA-14-210: ETM/ETB/Coresight Date: 04-03-2014 Speaker: Mathieu Poirier

1. Mathieu Poirier - LCA14-210, Macau
ETM/ETB/Coresight : Initial Discussion

2. Overview
• What are ETM, ETB and Coresight
• Current state upstream
• Patches by various contributor
• Linaro’s initial proposal for upstreaming
• Open discussion

3. Overview: ETM/ETB/Coresight
• Coresight is a set of IP block meant to provide
non-intrusive debug capabilities.
• Allow for debugging of different types of
components, not just processors (DSP, DMA).
• Cross-trigger interface stops everything that is
connected.
• Blocks usually split in: Source, link and sinks.
• SoCs designer will choose to implement different
“paths” based on requirement.
• Depending on the configurations, “paths” can be
modified on the fly.

4. Current State Upstream:
• Only one file: arch/arm/kernel/etm.c
• Includes ETB support and a single ETM
component.
• Enabled only by setting CONFIG_OMAP2.
• Works on beagleboard/beagleXM.
• Static and rigid configuration.
• Trace buffer output to the console.
• Nothing in the “Documentation/” directory.
• No longer maintained.

5. Patches by Contributors (ETM/ETB)
• Arve Hjønnevåg (Google):
• Mostly making the driver configuration more flexible
• Adds robustness and fixes a few bugs
• Added support for multiple ETM/PTM
• Adds tuning capabilities via sysfs
• Patches in the Android tree
• Adrien Vergé (Mtl. Polytechnic School of Eng.)
• Fixing basic memory allocation problems
• kobj_attribute → device_attribute
• Add tracing for specific address range (similar to Arve)
• Introducing tracing by PID, supports namespace
• Patches sent for review, already in its 3rd iteration

6. Patches by Contributors (Coresight)
• Pratik Patel (CodeAurora):
• Comprehensive drivers for the Coresight framework:
• ETM, ETB, Funnel, Replicator, STM, TMC, TPIU.
• Defines a new “coresight” platform bus.
• All components register with the coresight bus:
• Coresight components are independent.
• Connection between devices is defined in DT.
• Coresight sysfs bus interface enables the “path”.
• A “path” can be changed from sysfs interface.
• Already under “drivers/coresight/”
• Big - around 7K lines of code.
• Some hard coded values (clock name and buffer size)
• Minimal working functionality for each component

7. Patches by Contributors (Coresight)
• Robert Marklund (ST-Ericsson at the time):
• Building on the work done by Pratik Patel.
• Not sure if the patchset was ever sent for review.
• John Hunter (TI) has a Cross-trigger Interface:
• https://github.com/jonhunter/linux/commits/dev-cti
• Pratik thinks this implementation is better than his but
needs work, i.e doesn’t support routing one trigger (CTI)
to another.

8. What Should We Do Now?
• We don’t want efforts to be wasted by duplicating
what’s already done.
• Consensus on the mailing list toward Pratik’s
work:
• Should probably start from that and aggregate
contributions from other people.
• If we start with that, the patchset will need to be submitted
in smaller chunks.
• Comments from upstream need to be addressed
• AMBA vs platform bus.
• debugfs over sysfs.

9. We have questions...
• Where should the driver live (keeping arch64 in
mind)?
• Do we keep both current and new driver in the
tree for some time?
• AMBA or Coresight bus?
• Russel seemed to favour AMBA (clock issues in mind)
• There may be problems with multiple address space
access, i.e config registers + data plane
• Do we need ROM table discovery or DT is fine?
• What do do about:
• ARMv8
• TrustZone and security

10. Prerequisite for Uptreaming
• Items considered mandatory for upstream
acceptance of new patches:
• Move current code outside of “arch/arm/kernel”
• Remove dependency on CONFIG_OMAP2
• Move configurables to debugfs rather than sysfs
• Make the driver work on multiple platforms

11. Prerequisite for Uptsreaming (Cont’d)
• No loss of functionality while working on a solution
• Upstream suggested a new kernel config for the driver
that is conditional to !CONFIG_OC_ETM.
• That’s exactly what Pratik did.
• Front-end for platforms, back-end for generic parts or
multiple drivers for components?
• I guess we’ll just have to wait and see.
• Integration with ftrace or perf is a must
• Mandate intimate knowledge of ARM PFTv1.1.
• I would start with ftrace because of kernelshark.

12. Linaro’s Initial Proposal
• Start with Pratik’s work but:
• Rebase everything on 3.15.
• Add coresight components to beagleXM’s DT spec.
• Get the code working.
• Add enhancement from Google and A. Vergé (if not
already present).
• Address initial upstream comments (sysfs and AMBA)
• Send patches with ETM/ETB only as initial RFC.
• Add more advance features when the quarks of the initial
jet have been resolved.
• With an initial framework, other people will be
able to add in their code.

13. Who’s Willing to Help?
• If you have ETM/ETB/Coresigh work done
internally, your opinion counts.
• We need development boards with Coresight
enabled SoCs.
• I will start consolidating all this work:
http://git.linaro.org/git/people/mathieu.poirier/coresight.git

14. Your Turn: Open Discussion

15. Mathieu Poirier: mathieu.poirier@linaro.org
More about Linaro Connect: http://connect.linaro.org
More about Linaro: http://www.linaro.org/about/
More about Linaro engineering: http://www.linaro.org/engineering/
Linaro members: www.linaro.org/members