Freescale's Idea of Open Source JTAG

I was recently at a seminar for ARM MCUs and Freescale was talking
about their new Kinetis devices (now I can even spell Kinetis).  They
talked about their "tower" eval boards using a USB connector for
debug.  Funny how the keep saying you can use a JTAG cable, but never
actually said it uses a JTAG port!  I'm not sure if there is any
significance to that or not.  It appears to use a standard JTAG port
on a PC for the debug software interface.

However, that is pretty much the end of what they explain.  They use a
Freescale 8 bit MCU to implement a USB to JTAG convertion.  The 8 bit
MCU also connects a serial port to the Kinetis part and seems to
provide some basic revision info on the board and manages power.

As far as I can tell, Freescale has plopped one of their own parts on
the board with proprietary firmware as a JTAG interface and called it
"Open Source JTAG".  Does anyone know if this is really open source in
any way?  Or is Freescale just trying to give us a warm fuzzy
feeling?

I tried to ask some questions about this at the seminar, but didn't
get any real info out of them.

Rick

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> I was recently at a seminar for ARM MCUs and Freescale was talking
> about their new Kinetis devices (now I can even spell Kinetis).  They
> talked about their "tower" eval boards using a USB connector for
> debug.  Funny how the keep saying you can use a JTAG cable, but never
> actually said it uses a JTAG port!  I'm not sure if there is any
> significance to that or not.  It appears to use a standard JTAG port
> on a PC for the debug software interface.
>
> However, that is pretty much the end of what they explain.  They use a
> Freescale 8 bit MCU to implement a USB to JTAG convertion.  The 8 bit
> MCU also connects a serial port to the Kinetis part and seems to
> provide some basic revision info on the board and manages power.
>
> As far as I can tell, Freescale has plopped one of their own parts on
> the board with proprietary firmware as a JTAG interface and called it
> "Open Source JTAG".  Does anyone know if this is really open source in
> any way?  Or is Freescale just trying to give us a warm fuzzy
> feeling?
>

In a situation like this, I would think more about asking if it has a
"Open Specification" instead of been "Open Source".

For a interface like this, my first question would be: Does Freescale
_openly_ provide enough information for support for the Freescale supplied
8 bit MCU interface to be added to OpenOCD/gdb if anyone were inclined to
do so ?

If they don't then the interface is not open in any way at all.

If they do, then the 8 bit interface device can at least be considered to
at least have a open API-level interface specification.

The next level of questioning however would be about if Freescale
provide enough information to allow you to build your own interface device
to replace the Freescale supplied one on the board.

If they don't then it cannot be truly considered open at a open source
type level.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

rickman <gnuarm@gmail.com> wrote:
> As far as I can tell, Freescale has plopped one of their own parts on
> the board with proprietary firmware as a JTAG interface and called it
> "Open Source JTAG".  Does anyone know if this is really open source in
> any way?  Or is Freescale just trying to give us a warm fuzzy
> feeling?

I think they use an interface called "OSBDM" which is one of a whole
family of similar open-source debugging interfaces originally developed
for Freescale's 8- and 16-bit micros. The main source of information are
the Freescale forums, but unfortunately they are a total unorganized mess.

-a

Anders.Montonen@kapsi.spam.stop.fi.invalid wrote:
> rickman <gnuarm@gmail.com> wrote:
>> As far as I can tell, Freescale has plopped one of their own parts on
>> the board with proprietary firmware as a JTAG interface and called it
>> "Open Source JTAG".  Does anyone know if this is really open source in
>> any way?  Or is Freescale just trying to give us a warm fuzzy
>> feeling?

Looks like what you want: <http://www.pemicro.com/osbdm/index.cfm>

-a

On Mar 19, 12:52=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2011-03-19, rickman <gnu...@gmail.com> wrote:
>
>
>
> > I was recently at a seminar for ARM MCUs and Freescale was talking
> > about their new Kinetis devices (now I can even spell Kinetis). =A0They
> > talked about their "tower" eval boards using a USB connector for
> > debug. =A0Funny how the keep saying you can use a JTAG cable, but never
> > actually said it uses a JTAG port! =A0I'm not sure if there is any
> > significance to that or not. =A0It appears to use a standard JTAG port
> > on a PC for the debug software interface.
>
> > However, that is pretty much the end of what they explain. =A0They use =
a
> > Freescale 8 bit MCU to implement a USB to JTAG convertion. =A0The 8 bit
> > MCU also connects a serial port to the Kinetis part and seems to
> > provide some basic revision info on the board and manages power.
>
> > As far as I can tell, Freescale has plopped one of their own parts on
> > the board with proprietary firmware as a JTAG interface and called it
> > "Open Source JTAG". =A0Does anyone know if this is really open source i=
n
> > any way? =A0Or is Freescale just trying to give us a warm fuzzy
> > feeling?
>
> In a situation like this, I would think more about asking if it has a
> "Open Specification" instead of been "Open Source".
>
> For a interface like this, my first question would be: Does Freescale
> _openly_ provide enough information for support for the Freescale supplie=
d
> 8 bit MCU interface to be added to OpenOCD/gdb if anyone were inclined to
> do so ?
>
> If they don't then the interface is not open in any way at all.

The question there is "who" do you ask?  the presenter at a multi-
vendor presentation is not a wealth of knowledge.  He tossed around
the "Open Source" whatever name as if it was a Good Housekeeping seal
of approval.

I'm pretty sure the extent of their involvement will be to point me to
the various "open" whatever projects.


> If they do, then the 8 bit interface device can at least be considered to
> at least have a open API-level interface specification.
>
> The next level of questioning however would be about if Freescale
> provide enough information to allow you to build your own interface devic=
e
> to replace the Freescale supplied one on the board.
>
> If they don't then it cannot be truly considered open at a open source
> type level.

That much they do.  From what I can gather the firmware is out there
for all to see.  You will have to use one of their chips to host it
unless you want to do some porting, but that is not a big issue.

My bigger concern is about what software will talk to it.  You mention
GDB/OpenOCD.  I know what a debugger is, which is what I assume GDB is
about.  But what does OpenOCD do?  I don't get how that fits into the
picture.  Does it handle the translation between commands that GDB
speaks (which I guess would be target and device independent) and the
protocol that has to be used to talk to the JTAG adapter?  If so, is
there anything like a spec for either side of this interface?

Funny how so many open source projects are so bad at explaining what
they are about.  A lot of the cores on opencores literally give one
sentence of description.  The OpenOCD user guide intro says, "The Open
On-Chip Debugger (OpenOCD) aims to provide debugging, in-system
programming and boundary-scan testing for embedded target devices" and
then dives into talking about the adapters.  It doesn't talk any
further about what OpenOCD does or what it connects to on the other
side and none of the "how" for any of it.

Rick

On Mar 19, 1:37=A0pm, Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> Anders.Monto...@kapsi.spam.stop.fi.invalid wrote:
> > rickman <gnu...@gmail.com> wrote:
> >> As far as I can tell, Freescale has plopped one of their own parts on
> >> the board with proprietary firmware as a JTAG interface and called it
> >> "Open Source JTAG". =A0Does anyone know if this is really open source =
in
> >> any way? =A0Or is Freescale just trying to give us a warm fuzzy
> >> feeling?
>
> Looks like what you want: <http://www.pemicro.com/osbdm/index.cfm>
>
> -a

Thanks for the link.  I have found some info on OSBDM.  From this page
it appears that PEMicro is using this as a way to get you into their
camp so they can sell you a bigger and better adapter... nothing wrong
with that.  I just want to understand the whole tool chain for
debugging.  I also would like to figure out what is useful across the
spectrum of targets and how restricted any of these components are.

Rick

rickman <gnuarm@gmail.com> wrote:
> I just want to understand the whole tool chain for debugging.  I also
> would like to figure out what is useful across the spectrum of targets
> and how restricted any of these components are.

CodeWarrior and IAR should support OSBDM on ARM. I'm not aware of any
open-source tools that would support this combination (IIRC there are some
tools for Freescale's 8/16-bit micros). There's been some talk of support
for the Kinetis chips on the OpenOCD mailing lists, but I don't think
anything has been done yet, and I also don't know if this would include
OSBDM support.

-a

On 2011-03-19, rickman <gnuarm@gmail.com> wrote:
> On Mar 19, 12:52&#4294967295;pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
> Earth.UFP> wrote:
>> If they do, then the 8 bit interface device can at least be considered to
>> at least have a open API-level interface specification.
>>
>> The next level of questioning however would be about if Freescale
>> provide enough information to allow you to build your own interface device
>> to replace the Freescale supplied one on the board.
>>
>> If they don't then it cannot be truly considered open at a open source
>> type level.
>
> That much they do.  From what I can gather the firmware is out there
> for all to see.  You will have to use one of their chips to host it
> unless you want to do some porting, but that is not a big issue.
>
> My bigger concern is about what software will talk to it.  You mention
> GDB/OpenOCD.  I know what a debugger is, which is what I assume GDB is
> about.  But what does OpenOCD do?  I don't get how that fits into the
> picture.  Does it handle the translation between commands that GDB
> speaks (which I guess would be target and device independent) and the
> protocol that has to be used to talk to the JTAG adapter?  If so, is
> there anything like a spec for either side of this interface?
>

OpenOCD is a JTAG programmer and debugger interface.

It can be used as a standalone program (by means of a builtin scripting
language) from the command line to load code into a target board's
SRAM/RAM/Flash memory.

It can also be used in a server mode which allows gdb to connect to it
via gdb's remote target protocol. You can then use gdb to talk to the board
via the OpenOCD controlled JTAG interface.

OpenOCD has knowledge of a range of JTAG devices and various boards.
The builtin scripting language also serves as a configuration language
which allows developers to define new targets which OpenOCD does not
already know about.

Developers wishing to add a new type of JTAG interface can modify the
OpenOCD source code to provide that support and then expose that new
interface via the scripting language.

You ask how it all connects together. One example:

The physical setup for a board in front of me has a ARM-JTAG cable from
Olimex plugged into the JTAG connecter on the board and the other end of
the cable plugged into a (real) parallel port.

I run OpenOCD by giving it the name of one of my own scripts. The first
thing that script does is to load a OpenOCD supplied script which
defines the parallel port interface. It also loads a second script
which defines the attributes of the board attached to the JTAG device.

My own scripts, depending on requirements, can tell OpenOCD to go into
a server mode so that GDB can attach to it via gdb's target command, or
it can tell OpenOCD to load a program binary into the target board's
memory.

Therefore if I am running a debugger (I use the ddd frontend to gdb),
the comms path looks like this:

	ddd -> gdb -> OpenOCD -> target board.

ddd to gdb communications are via GDB's machine interface.
gdb to OpenOCD communications are via a TCP/IP port opened up by OpenOCD.
OpenOCD to target board communications are via the JTAG cable.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

rickman <gnuarm@gmail.com> writes:

> On Mar 19, 12:52&nbsp;pm, Simon Clubley <clubley@remove_me.eisner.decus.org-

[...]

>
> That much they do.  From what I can gather the firmware is out there
> for all to see.  You will have to use one of their chips to host it
> unless you want to do some porting, but that is not a big issue.
>
> My bigger concern is about what software will talk to it.  You mention
> GDB/OpenOCD.  I know what a debugger is, which is what I assume GDB is
> about.  But what does OpenOCD do?  I don't get how that fits into the
> picture.  Does it handle the translation between commands that GDB
> speaks (which I guess would be target and device independent) and the
> protocol that has to be used to talk to the JTAG adapter?  If so, is
> there anything like a spec for either side of this interface?

Yes, On the host side it speaks the GDB remote debug protocol. Also
there is a telnet command-line interface. Use of these is explained in
the manual.

On the target side it speaks whatever is required to talk to the many
compatible adapters. FTDI based ones especially plus other USB and
parallel port types.

> Funny how so many open source projects are so bad at explaining what
> they are about.  A lot of the cores on opencores literally give one
> sentence of description.  The OpenOCD user guide intro says, "The Open
> On-Chip Debugger (OpenOCD) aims to provide debugging, in-system
> programming and boundary-scan testing for embedded target devices" and
> then dives into talking about the adapters.  It doesn't talk any
> further about what OpenOCD does or what it connects to on the other
> side and none of the "how" for any of it.

It was always clear to me, I think the openocd manual is very good
actually.

-- 

John Devereux

On Mar 19, 2:58 pm, John Devereux <j...@devereux.me.uk> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Mar 19, 12:52 pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
>
> > That much they do.  From what I can gather the firmware is out there
> > for all to see.  You will have to use one of their chips to host it
> > unless you want to do some porting, but that is not a big issue.
>
> > My bigger concern is about what software will talk to it.  You mention
> > GDB/OpenOCD.  I know what a debugger is, which is what I assume GDB is
> > about.  But what does OpenOCD do?  I don't get how that fits into the
> > picture.  Does it handle the translation between commands that GDB
> > speaks (which I guess would be target and device independent) and the
> > protocol that has to be used to talk to the JTAG adapter?  If so, is
> > there anything like a spec for either side of this interface?
>
> Yes, On the host side it speaks the GDB remote debug protocol. Also
> there is a telnet command-line interface. Use of these is explained in
> the manual.
>
> On the target side it speaks whatever is required to talk to the many
> compatible adapters. FTDI based ones especially plus other USB and
> parallel port types.

Yes, it only makes sense that it would talk "whatever is required".
This layer must correspond to the JTAG adapter to target protocol in
some manner.  It seems like everything has been done with little
coordination and is a collection of "ad hoc" approaches.  There must
be some underlying commonality.  I guess that is what you get when the
goal of each vendor is to get you to use their approach end to end.


> > Funny how so many open source projects are so bad at explaining what
> > they are about.  A lot of the cores on opencores literally give one
> > sentence of description.  The OpenOCD user guide intro says, "The Open
> > On-Chip Debugger (OpenOCD) aims to provide debugging, in-system
> > programming and boundary-scan testing for embedded target devices" and
> > then dives into talking about the adapters.  It doesn't talk any
> > further about what OpenOCD does or what it connects to on the other
> > side and none of the "how" for any of it.
>
> It was always clear to me, I think the openocd manual is very good
> actually.

It may be clear to you, but to someone who isn't familiar with it an
adequate basis is not provided.  I think the example I gave is very
illustrative.  But that is not the point, or at least my point.  I am
trying to come up the learning curve.  BTW, part of the problem is
terminology.  For example, Simon's reply talks about using an "ARM-
JTAG cable" when it would be more clear if he said a JTAG adapter.  He
knew exactly what he meant, but I had to figure it out from context.
Not a big thing, but there are lots of things like this.  The terms
JTAG and Debugger are used for everything so that it is hard to tell
what is being discussed.

OpenOCD provides an interface for a user or a debugger like GB to
connect to a JTAG adapter... or actually to the driver for the JTAG
debugger.  There are JTAG adapters that can be copied, like the
wiggler, but they use (or did at one time) what is still a proprietary
driver.

I'm also very unclear about the protocols for the various layers.
JTAG specifies one or maybe two layers, the transport of commands
across the interface and the commands for operating the TAP
controller.  I'm not sure, but I expect this is considered one layer.
The JTAG adapter provides the electrical interface and for any devices
more complex than the Wiggler, also provides the layer that transports
the TAP commands.  Outside of that I have little idea of what the
protocols are and exactly where they are implemented.

I guess one thing I don't get is why OpenOCD is separate from GDB.
How is GDB used without OpenOCD?  What it the protocol between them?
How does this protocol relate to the target?  Is it at all target
specific?  Which of the layers are target specific?

All these years I have learned only enough about JTAG to get stuff to
work.  I think everyone is like this.  As a result very few people
really understand the design of the various tools for using JTAG
debugging.  Now I want to learn more so I can deal with debugging
issues of adding new devices and new tools.

Rick