On Mar 20, 8:40=A0am, David Brown <david.br...@removethis.hesbynett.no>
wrote:
> On 20/03/11 06:06, rickman wrote:
>
> > On Mar 19, 6:21 pm, David Brown<david.br...@removethis.hesbynett.no>
> > wrote:
> >> On 19/03/11 22:25, Simon Clubley wrote:
>
> >>> On 2011-03-19, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth=
.UFP> =A0 wrote:
>
> >>>> The JTAG adapter and driver are implemented within (and only within)
> >>>> OpenOCD.
>
> >>> That statement (with it's implied lack of _direct_ JTAG support withi=
n gdb
> >>> itself) is stronger than I can justify with my level of experience, s=
o let
> >>> me clarify: some parts of GDB may have direct support for specific JT=
AG
> >>> devices (even though I have not yet come across this support if it ex=
ists),
> >>> but when OpenOCD is been used to connect to a device, then all JTAG
> >>> specific driver/adapter support which is actually used to talk to the
> >>> device is within OpenOCD itself.
>
> >>> Simon.
>
> >> Let me expand a little on that with some history of embedded gdb
> >> debugging before OpenOCD (and for non-ARM targets). =A0You probably kn=
ow
> >> much of this already, but perhaps by putting it in slightly different
> >> words it will help Rick (and maybe others) understand better. =A0I hop=
e I
> >> don't make /too/ many mistakes and confuse things further.
>
> >> gdb is a program built with three "ends" - a front-end, a middle-end,
> >> and a back-end. =A0The mainline version comes with several front-ends,
> >> several middle-ends, and several back-ends. =A0There are also specific
> >> ports or patched versions with additional variants of these ends. =A0O=
n
> >> top of this, it can be compiled for different hosts (for example,
> >> running on Windows or Linux) and for different targets (x86, ARM, etc.=
).
>
> >> This makes it a very flexible program. =A0For some uses, it is
> >> self-sufficient. =A0For other uses, it forms part of a chain of progra=
ms -
> >> which may even include more than gdb.
>
> >> At the front-end, you have the connection from the higher level world =
to
> >> gdb. =A0This can be using gdb's built-in command-line interpreter (for
> >> those that like a fast and efficient interface at the cost of a
> >> significant learning curve). =A0There is also a graphics interface,
> >> Insight, that is often built into the gdb binary. =A0Or it can also
> >> receive commands in a more concise format via a pipe, serial port or a
> >> tcp/ip socket - this is how other front-ends like ddd, Eclipse,
> >> CodeBlocks, etc., use gdb as their back-end debugger. =A0The front-end=
,
> >> along with the protocols used, are largely independent of the target,
> >> the language, and the back-end (though when using the CLI there will b=
e
> >> some specific commands).
>
> >> The middle-end supports the language and the target architecture. =A0g=
db
> >> supports C, C++, Ada, and various other languages. =A0And it supports =
a
> >> huge range of targets. =A0It is the middle-end that handles loading fi=
les,
> >> understanding debug symbols, registers, reading and writing memory, et=
c.
>
> >> The back-end also has a number of options. =A0It can connect to a nati=
ve
> >> process on suitable OS'es (such as for natively debugging programs
> >> running on Linux or Windows). =A0It can also connect using a serial po=
rt,
> >> pipe, or a tcp/ip socket and communicate with a lower-level debugger
> >> using the gdb debugging protocol. =A0This protocol is mostly, but not
> >> entirely, independent of the target architecture. =A0It is also someti=
mes
> >> build with target simulator backends.
>
> >> Mainline gdb by itself can therefore not debug embedded systems. =A0It
> >> knows nothing about jtag, BDM, or any other way of connecting to an
> >> embedded system. =A0The most common way to handle this is to have a pr=
oxy
> >> program that knows about the low-level interface, and which communicat=
es
> >> with gdb over a tcp/ip socket.
>
> >> It used to be common practice to make patched versions of gdb that
> >> directly support debugger interfaces. =A0For example, I have a gdb bui=
ld
> >> that communicate with a MC68332 using a parallel interface BDM debugge=
r.
> >> =A0 =A0Such patched monolithic builds made sense before, for speed rea=
sons -
> >> now host systems are so fast that it makes more sense to use
> >> development-friendly modular arrangements with separate proxies.
>
> >> Sometimes these proxies run directly on the target. =A0This is often t=
he
> >> case for debugging embedded Linux systems - here the "proxy" may in fa=
ct
> >> be a limited version of gdb running on the target. =A0But mostly the
> >> proxies run on the host, and communicate with a debugging interface of
> >> some kind.
>
> >> For example, with the CodeSourcery gcc toolchain for the ARM, you get
> >> some programs they call "debug sprites". =A0These are specific to the
> >> particular debugger interface, and let you use the same gdb for any
> >> supported debugger. =A0gdb talks to the sprite, and the sprite talks t=
o
> >> the hardware (via USB, typically). =A0The USB debugger interface then
> >> talks to the jtag interface on the target processor.
>
> >> Sometimes these proxy programs are not open source. =A0For example, TI=
has
> >> not released information about jtag debugging for the msp430. =A0But i=
t
> >> was willing to release it under an NDA to some msp-gcc developers. =A0=
So
> >> they wrote the a proxy, released as binary only to protect the NDA
> >> information, allowing GPL'ed gdb to talk to the msp430 processors.
>
> >> And sometimes the proxy is neither on the host or the target, but is o=
n
> >> an "intelligent" debugger unit, such as the ZY1000 debugger which
> >> connects to the host by Ethernet. =A0(The ZY1000 runs OpenOCD.).
>
> >> So where does OpenOCD fit into this picture? =A0OpenOCD is a debugger
> >> proxy program (it does other things as well). =A0It is designed to be =
very
> >> flexible - it supports a wide range of debugger interfaces, scripting,
> >> almost all types of ARM (and a few other targets such as some MIPS
> >> devices), flash programming, board support, etc. =A0The idea is to hav=
e
> >> one common proxy program that suits most uses - at least in the ARM
> >> world - rather than having lots of different proxy programs.
>
> >> OpenOCD therefore "knows" about JTAG and a range of debugger interface=
s.
> >> =A0 =A0Many of these interfaces are very simple - it is common to use =
the
> >> FTDI2232 chips for JTAG interfaces, which blindly pass data between th=
e
> >> USB and the JTAG connection. =A0Others are more complex and have more
> >> advanced protocols.
>
> >> As well as acting as a gdb proxy, OpenOCD supports scripting and an
> >> interface designed to control programming flash or other setup on
> >> devices, or to handle other jtag tasks such as board testing.
>
> > David, thank you for an excellent explanation. =A0This makes it all muc=
h
> > more clear now. =A0It would seem to me that if the source code for the
> > JTAG adapter on the Freescale eval boards (OSJTAG) is available as
> > open source, then the interfaces on either side would need to be open
> > even if not documented. =A0So it should not be a large job to make any
> > of the open source tools compatible with it.
>
> That's possibly correct - but remember that "open source" doesn't
> necessarily mean "documented", "well-written" or "understandable". =A0Man=
y
> developers who publish their source are proud of their work, and want
> people to view their code and think it is well written, and also want to
> write code that other people can work with an contribute to. =A0But that
> doesn't apply to all open source code, especially if it has been written
> as an internal project and then later released without due care and
> planning. =A0I have no idea what the situation is for Freescale's code
> here - I am just saying that even if the code is available, it does not
> mean the OpenOCD developers can trivially support the interface.
>
> > So I guess the only thing I am still not clear on is exactly what the
> > protocol levels are on the target side. =A0It seems clear that there is
> > a protocol between GDB and OpenOCD. =A0There are many protocols between
>
> Yes, that is GBD's protocol. =A0It is documented in the gdb documentation=
,
> if you are interested in the details:
>
> <http://sourceware.org/gdb/current/onlinedocs/gdb/>
> <http://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html...=
>
>
> > OpenOCD and the various JTAG adapters. =A0But a given adapter can work
> > with multiple targets. =A0At the JTAG point it is just a way to get
> > commands into the target. =A0What level of this hierarchy has to
> > understand the debugging protocol of the target? =A0I guess it would be
> > OpenOCD, yes? =A0Where is this documented? =A0In particular, for the
>
> Yes, it is OpenOCD that handles this - though possibly in cooperation
> with "intelligent" debugger hardware interfaces. =A0For simple interfaces
> such as the FTDI-based devices, OpenOCD handles all the translation
> between gdb protocol telegrams (such as "read 4 bytes from address
> 0x1234") into the required jtag telegrams for the particular target.
>
> > Kinetis devices could that be figured out from the OSJTAG code? =A0Or
> > does that just dumbly handle JTAG commands like the FTDI device? =A0If
> > not there, where would this info be available from?
>
> I don't know whether the OSJTAG does any work itself, or passes things
> on directly. =A0But either way, one would hope there is enough
> documentation available to allow OpenOCD to speak to the OSJTAG - if
> not, then reverse engineering based on the source code for OSJTAG is
> certainly possible.
The source for the OSJTAG device that's on the Kinetis boards is made
available by P&E Micro, so you can actually check what it's doing (and
alter it, if it weren't passing things through as cleanly as one
desired). If you grab the "Design Documents" link from the link
below, you'll have the source both for the libusb drivers and for the
OSJTAG/OSBDM JM60 firmware that runs on the embedded debugger:
http://www.pemicro.com/osbdm/index.cfm
I've been experimenting with the API provided by P&E and so far I've
had trouble with the abstracted functions that aren't just providing
fairly direct JTAG access (as far as I can tell, the commands for
halting and resetting are silently failing (returns OK status), but
reading from memory on the Kinetis gives me an error... not sure if
I'm missing something). They provide an alternate command structure
through a "special function" interface, look at
"jtag_kinetis.c:t_special_feature" which appears to be a more direct
JTAG interface, which as far as I can tell is what most of the
existing working IDEs and programming tools are using to flash and
program the device. Unfortunately I'm not that familiar with the
internals of ARM's JTAG implementation, but I suspect maybe this
interface could be somehow mated up with OpenOCD, or in the worst case
the firmware on the debugger chip could be altered as desired to
provide the interface needed and that could be used in stead.
> > Maybe I should say that I am trying to figure out how someone might
> > add debugging support to a tool. =A0I think OpenOCD would be used, so I
> > guess we just need to make OSJTAG work with OpenOCD which would be a
> > win/win.
Originally I was hoping that I might be able to put together a simple
flashing interface for this device that wouldn't need a full JTAG
implementation behind it, but what I've been finding, I think that
OpenOCD may be a better bet for communicating with this device and
getting both debugging and flashing functionality working.
>
> Yes, that's about right.
>
> Of course, there is another possible route. =A0The Kinetis development
> cards have a standard ARM jtag port, as far as I can see, in addition to
> the OSJTAG USB device. =A0So you can use any other Cortex-compatible
> debugger with them - ranging from powerful "intelligent" devices like
> the ZY1000 to cheap (or even home-made) FTDI-based devices. =A0So while I
> hope that OSJTAG support will make its way into OpenOCD sometime (and if
> Freescale are on the ball, they will contribute to that work
> themselves), you can always get around it with some cheap and simple
> hardware.