Every chip needs debugging infrastructure. Without it, software development and bring-up becomes nearly impossible. At the same time, having a great debug and trace infrastructure is, in many cases, a “nice to have” on the never ending list of tasks, but not a primary selling point. A way out of this dilemma is provided by Open SoC Debug (OSD): a open, shared set of debug components which can be integrated into a SoC and do all the heavy lifting of a debug system.
Like its commercial counterparts ARM CoreSight or NEXUS 5001, OSD is first and foremost a specification. It describes the architecture of the debug system, and how this architecture can be extended with modules for specific debug and tracing tasks.
But that’s not enough: OSD comes with a full reference implementation of both hardware components and software tools. On the hardware side, OSD has support for generating control-flow traces from CPUs, for run-control debugging (setting breakpoints and such), as well as more sophisticated features, such as a virtual UART device over the debug connection (great for printing initial kernel messages during system bring-up!).
On the host software side, a daemon serves as central point communicating with the target device. Various software tools can connect to this daemon and analyze trace data, or interact with the system. For example, you can have a GDB instance talking to the system at the same time as another tool records an instruction trace, or logs performance data.
I’m contributing heavily to OSD as it provides the base for my research prototypes.
More information is available at opensocdebug.org.