On 09/21/2010 12:52 PM, Christian Robottom Reis wrote: [snip]

Welcome on. We discussed OpenOCD at the last TSC meeting we had, and

we have discovered that we don't have a very firm grasp of the gaps in OpenOCD for v7 hardware at the moment. So let me ask a few basic questions and see if that can guide us somewhere:

- Of the platforms OMAP3, OMAP4, mx51 and U8500, does any have
  OpenOCD support today?

OMAP3 has the best support, though it remains hard-coded for the OMAP3530 chip. It is not difficult to patch the code to use OpenOCD with other chips, but this really should be handled by probing the ROM table(s) rather than making such naive assumptions. After OMAP3, MX51 has seen some progress, but it is not nearly as complete. Also, there are numerous FIXME and TODO comments scattered in the code.

Cortex-A9/OMAP4/U8500 has not seen any work as yet. That will be all new code, though work was been done to support the v7 Debug Programmer's Model for Cortex-A8. Since that is shared in the Cortex-A9, it may be possible to hack the Cortex-A8 support into limping along for A9. I can let you know when I get my hands on some hardware to use for testing, or others can take a stab at it with their own boards (see below). That will probably take some experience with OpenOCD to be successful.

- Are there levels of "support" that OpenOCD can provide for a
  platform? I.e. is it all or nothing, or is there basic support and
  what's a step up from that?

It will be gradual, though I don't want to say much more than that at this point for fear of promising too much. I am still familiarizing myself with the Cortex specifications and status of the code in OpenOCD.

My task for this week has been to try to sort out a path forward for Cortex-A9, but my summary above shows there is work that can be done to improve the existing support (and that will make that path easier to follow). For example, I think the ROM table support problem can be solved for Cortex-A8 before starting work on the A9.

- How much of OpenOCD is board-specific? In other words, does
  specific OpenOCD code (or config) need to be written to support,
  say, the Beagle versus the Beagle XM versus the IGEPv2?

The bits specific to chips and boards resides in scripts that are written in a simple dialect of TCL, making it fairly easy to add support for new hardware once a new core has been added to the C code. Moreover, this structure makes it possible to define new chips and boards without rebuilding the application, though this requires the core support to be sufficiently flexible. Again, this is impossible for Cortex-A8 at the present, but that can be resolved with a focused effort.

- Is there an OpenOCD starter doc we can give people that want to
  try OpenOCD out on their platforms (and report bugs to help
  provide items for your work queue)?

OpenOCD includes documentation written in TexInfo, so HTML and PDF versions of the current OpenOCD User Manual can be generated by running 'make docs' in the source tree. If that document has any shortcomings, they deserve to be brought up on the OpenOCD mailing list.

As this suggests, using the latest code from the Git repository [1] will offer the best path forward for those wanting to contribute concrete feedback from using OpenOCD with their own boards. Depending on the specific board and problems, I may not be the most qualified person to provide answers or assistance, so I would strongly encourage problems to be posted to the OpenOCD mailing list for discussion.

Unfortunately, the real shortcoming will be the lack of specific board scripts to try, so a list of target boards might be a good input for me. I can whip some together and publish them in my personal public repository.

[1] git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd