LCA14: LCA-14-210: ETM/ETB/Coresight


Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

LCA14: LCA-14-210: ETM/ETB/Coresight

  1. 1. Mathieu Poirier - LCA14-210, Macau ETM/ETB/Coresight : Initial Discussion
  2. 2. Overview • What are ETM, ETB and Coresight • Current state upstream • Patches by various contributor • Linaro’s initial proposal for upstreaming • Open discussion
  3. 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. 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. 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. 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. 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: • • Pratik thinks this implementation is better than his but needs work, i.e doesn’t support routing one trigger (CTI) to another.
  8. 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. 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. 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. 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. 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. 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:
  14. 14. Your Turn: Open Discussion
  15. 15. Mathieu Poirier: More about Linaro Connect: More about Linaro: More about Linaro engineering: Linaro members: