OpenOCD on Cortex-A9

Registered by Michael Hope

Linaro may look into OpenOCD and especially OpenOCD for the Cortex-A9+NEON+SMP in the future. This session discusses the current state, potential users, and what's needed to get there.

Note: may be a short session as the drafter is unavailable

Blueprint information

Status:
Not started
Approver:
None
Priority:
Medium
Drafter:
Zach Welch
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

OpenOCD provides JTAG connectivity to boards for the purposes of programming and debugging. When used with GDB, OpenOCD allows debugging of bootloaders, stand-alone applications, and even the Linux kernel. Typically, user-space programs are debugged using an on-board gdbserver, rather than via JTAG.

While general functionality must be provided by C code, much of OpenOCD's flexibility comes from its use of scripts written in a simple dialect of TCL. Specifically, support for new chips and boards can be provided by writing new scripts, once the basic core support has been added. The script command language can also be used in a interactive shell, accessible through a telnet connection.

OpenOCD presently lacks any explicit support for the Cortex-A9 core; however, the current implementation for Cortex-M3 and -A8 cores provided many of the common building blocks that will be required (e.g. DAP access and ARMv7a, respectively). Much of the initial support for the A9 core should be a matter of abstracting the Cortex-A8 support and sharing the resulting infrastructure. The A9-specific features that need to be implemented will be unique core features and target/board scripts,

Thus, much of the pending work will improve support for multiple ARM cores, not just the A9. One good example of these common improvements is ROM Table scanning. OpenOCD presently makes hard-coded assumptions about the location of on-chip debugging resources, but the ARM ADI and CoreSight specifications provides ROM Tables as part of the means for detecting the debug topology. Other missing ARMv7a features include using vector catch to halt on reset and lack of VFPv3/NEON register support.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.