zwelch at codesourcery.com
Wed Sep 22 00:47:45 BST 2010
On 09/21/2010 12:52 PM, Christian Robottom Reis wrote:
> 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 
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.
 git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
zwelch at codesourcery.com
(650) 331-3385 x743
More information about the linaro-toolchain