Seeking JTAG emulator for Atmel AT91 ARM Cores on Linux

On Aug 19, 1:41=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 19/08/2010 00:22, Johnson wrote:
>
> > That sounds great. I will check into it right now.
>
> > How about Zylin Embedded CDT?http://www.zylin.com/embeddedcdt.html
>
> > It integrates into Eclipse.
>
> For the debugger hardware, also look at Zylin:
> <http://www.zylin.com/zy1000.html>
>
> Disclaimer - I know this company because they are located near us. =A0I
> haven't used the device myself, but it certainly looks to me like it
> will do the job you need, and you can be confident that it will play
> well with Eclipse CDT, and both Linux and Windows hosts.
>
>
>
> > Leon wrote:
> >> On 18 Aug, 21:29, Johnson <gpsab...@yahoo.com> wrote:
> >>> Hi there,
>
> >>> We are porting a windows application from desktop into embedded Linux=
 on
> >>> Atmel AT91 ARM Cores, thus we need JTAG to debug the firmware under a
> >>> Linux environment. However, SAM-ICE only connects via USB to a PC
> >>> running Microsoft Windows2000 or XP. So I am looking for a JTAG emula=
tor
> >>> running on Linux. If you have any good idea/knowledge, could you
> >>> please help?
>
> >>> BTW, a friend of mine recommended YAGARTO toolchain for JTAG under
> >>> Linux, is it the best solution so far?
>
> >>> Thanks.
>
> >>> Johnson
>
> >>> --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
>
> >> The excellent Rowley CrossWorks ARM tools are available for Linux, and
> >> support several JTAG interfaces, including their own.
>
> > --- news://freenews.netfront.net/ - complaints: n...@netfront.net ---- =
Hide quoted text -
>
> - Show quoted text -

Well, it seems that if I only have JTAG and I want to denug the user-
space applications, Zylin ZY1000 JTAG Debugger is my only choice for
now. Any other opionion or advice?

To use ZY1000, I will also need Zylin Embedded CDT, right?

On Aug 19, 5:05 pm, Johnson <gpsab...@yahoo.com> wrote:

> If it is a mistake, I got to fix it. Is it a good idea for the USB
> firmware to generate one more virtual port for debugging (with GDB
> server)? The other virtual port will still be reserved for the
> peripheral.

Yes, getting yourself something akin to a console serial port over the
USB sounds like a very, very good idea.  And not just for GDB.

Assuming you have a USB host interface, can't you just put a hub in
there and plug in a usb-serial adapter next to the application
peripheral?   Drivers should already be in the kernel source, you
might only need to enable  them in the build config.

If you have a USB device interface you may need to look into something
like the USB composite device so as to present both your application
interface and something like a USB serial.  Then you controlling
computer (or something emulating/proxying for it) can either run GDB
or pass the channel of to your debug machine over a serial port or
ethernet or something.

Next time hook up those uart pins, even if just to pads you can solder
to.

On Aug 19, 3:53=A0pm, "cs_post...@hotmail.com" <cs_post...@hotmail.com>
wrote:
> On Aug 19, 5:05 pm, Johnson <gpsab...@yahoo.com> wrote:
>
> > If it is a mistake, I got to fix it. Is it a good idea for the USB
> > firmware to generate one more virtual port for debugging (with GDB
> > server)? The other virtual port will still be reserved for the
> > peripheral.
>
> Yes, getting yourself something akin to a console serial port over the
> USB sounds like a very, very good idea. =A0And not just for GDB.
>
> Assuming you have a USB host interface, can't you just put a hub in
> there and plug in a usb-serial adapter next to the application
> peripheral? =A0 Drivers should already be in the kernel source, you
> might only need to enable =A0them in the build config.
>
> If you have a USB device interface you may need to look into something
> like the USB composite device so as to present both your application
> interface and something like a USB serial. =A0Then you controlling
> computer (or something emulating/proxying for it) can either run GDB
> or pass the channel of to your debug machine over a serial port or
> ethernet or something.
>
> Next time hook up those uart pins, even if just to pads you can solder
> to.

Sounds great. Thanks!

On Aug 19, 5:15 pm, Johnson <gpsab...@yahoo.com> wrote:

> Well, it seems that if I only have JTAG and I want to denug the user-
> space applications, Zylin ZY1000 JTAG Debugger is my only choice for
> now. Any other opionion or advice?

I write my linux userspace embedded code such that it will compile for
a desktop linux pc (or sometimes even for windows) using a combination
of ifdefs and build configurations to incorporate either real hardware
interface functions or dummy/simulated ones depending on the target.
Then I do my initial debugging natively on the development machine,
and only push the code out to the target when I think it has a fair
chance of working or really needs the real hardware.  This is
particularly good for user interface issues since you can prototype
ideas and show them around, let potential customers play with the
product, etc without having to have built any hardware yet.  Writing
code that builds for multiple targets also means we can change
embedded architectures relatively easily.

With an ethernet interface I also set up scripts in my development
environment that can FTP a new copy of the userspace code into the
target, kill any running copy, and then launch the new one either
standalone or under gdbserver.   This works really well with a
compressed root filesystem  image that gets turned into a ramdisk on
boot - I can play around with a running system all I want, then once I
get a batch of changes done I do a full build of the application and
system image containing it and only then reflash the target.

On Aug 19, 4:04=A0pm, "cs_post...@hotmail.com" <cs_post...@hotmail.com>
wrote:
> On Aug 19, 5:15 pm, Johnson <gpsab...@yahoo.com> wrote:
>
> > Well, it seems that if I only have JTAG and I want to denug the user-
> > space applications, Zylin ZY1000 JTAG Debugger is my only choice for
> > now. Any other opionion or advice?
>
> I write my linux userspace embedded code such that it will compile for
> a desktop linux pc (or sometimes even for windows) using a combination
> of ifdefs and build configurations to incorporate either real hardware
> interface functions or dummy/simulated ones depending on the target.
> Then I do my initial debugging natively on the development machine,
> and only push the code out to the target when I think it has a fair
> chance of working or really needs the real hardware. =A0This is
> particularly good for user interface issues since you can prototype
> ideas and show them around, let potential customers play with the
> product, etc without having to have built any hardware yet. =A0Writing
> code that builds for multiple targets also means we can change
> embedded architectures relatively easily.
>
> With an ethernet interface I also set up scripts in my development
> environment that can FTP a new copy of the userspace code into the
> target, kill any running copy, and then launch the new one either
> standalone or under gdbserver. =A0 This works really well with a
> compressed root filesystem =A0image that gets turned into a ramdisk on
> boot - I can play around with a running system all I want, then once I
> get a batch of changes done I do a full build of the application and
> system image containing it and only then reflash the target.

Thanks for sharing!

On Aug 19, 3:53=A0pm, "cs_post...@hotmail.com" <cs_post...@hotmail.com>
wrote:
> On Aug 19, 5:05 pm, Johnson <gpsab...@yahoo.com> wrote:
>
> > If it is a mistake, I got to fix it. Is it a good idea for the USB
> > firmware to generate one more virtual port for debugging (with GDB
> > server)? The other virtual port will still be reserved for the
> > peripheral.
>
> Yes, getting yourself something akin to a console serial port over the
> USB sounds like a very, very good idea. =A0And not just for GDB.
>
> Assuming you have a USB host interface, can't you just put a hub in
> there and plug in a usb-serial adapter next to the application
> peripheral? =A0 Drivers should already be in the kernel source, you
> might only need to enable =A0them in the build config.
>
> If you have a USB device interface you may need to look into something
> like the USB composite device so as to present both your application
> interface and something like a USB serial. =A0Then you controlling
> computer (or something emulating/proxying for it) can either run GDB
> or pass the channel of to your debug machine over a serial port or
> ethernet or something.
>
> Next time hook up those uart pins, even if just to pads you can solder
> to.

Do you have any recommendation for the USB composite device? I prefer
simple and easy solutions.
Thanks.

The usb composite device is a driver in the linux kernel that lets a
device side interface be multiple functions at once, for example
pseudo ethernet and also mass storage.

Is your embedded board a usb host or a usb device?

If its a host, you dont need the composite driver, you just need a hub
and a usb serial dongle and to build and load the appropriate kernel
module for the dongle (plug it into a linux desktop instead and use
dmesg and lsmod to figure out what driver got autoloaded, then build
and load that on your embedded system).

Johnson wrote:
> On Aug 19, 3:53=A0pm, "cs_post...@hotmail.com" <cs_post...@hotmail.com>
> wrote:
> > On Aug 19, 5:05 pm, Johnson <gpsab...@yahoo.com> wrote:
> >
> > > If it is a mistake, I got to fix it. Is it a good idea for the USB
> > > firmware to generate one more virtual port for debugging (with GDB
> > > server)? The other virtual port will still be reserved for the
> > > peripheral.
> >
> > Yes, getting yourself something akin to a console serial port over the
> > USB sounds like a very, very good idea. =A0And not just for GDB.
> >
> > Assuming you have a USB host interface, can't you just put a hub in
> > there and plug in a usb-serial adapter next to the application
> > peripheral? =A0 Drivers should already be in the kernel source, you
> > might only need to enable =A0them in the build config.
> >
> > If you have a USB device interface you may need to look into something
> > like the USB composite device so as to present both your application
> > interface and something like a USB serial. =A0Then you controlling
> > computer (or something emulating/proxying for it) can either run GDB
> > or pass the channel of to your debug machine over a serial port or
> > ethernet or something.
> >
> > Next time hook up those uart pins, even if just to pads you can solder
> > to.
>
> Do you have any recommendation for the USB composite device? I prefer
> simple and easy solutions.
> Thanks.

On Aug 19, 6:14=A0pm, Johnson <gpsab...@yahoo.com> wrote:

> Do you have any recommendation for the USB composite device? I prefer
> simple and easy solutions.

The usb composite device is a driver in the linux kernel that lets a
device side interface be multiple functions at once, for example
pseudo ethernet and also mass storage Is your embedded board a usb
host or a usb device? If its a host, you dont need the composite
driver, you just need a hub and a usb serial dongle and to build and
load the appropriate kerne module for the dongle (plug it into a linux
desktop instead and use dmesg and lsmod to figure out what driver got
autoloaded, then build and load that on your embedded system)

Johnson wrote:

> Thank you very much for sharing the knowledge! It is really my dream
> to use JTAG plus OpenOCD for all purpose: firmware download, boot load
> debugging, and application debugging.

A warning: I think it will be very difficult to use JTAG, only. If you use
u-boot, you'll need some kind of interactive communication for setting up
the Linux boot parameters etc. and to see the debug output of u-boot and
the linux boot process. Maybe this is possible with JTAG, too, and in
theory you could setup anything before, including the u-boot environment,
on your development host and then flash it with JTAG, but at least it is
not the standard way and I think I would need much longer to get a board
working with JTAG, only.

And if you are running Linux, usually you need some kind of shell access to
setup init scripts, start daemons and applications for testing etc. Maybe
you can setup a serial port over USB in Linux, but finding the right driver
setttings for this USB support and watching the output, if a driver fails
to load, is impossible without some interactive access in the beginning. 

This would be like giving a braille instruction to a blind person for
flying an airplane from New York to Cologne :-)

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss <fb@frank-buss.de> writes:

> Johnson wrote:
>
>> Thank you very much for sharing the knowledge! It is really my dream
>> to use JTAG plus OpenOCD for all purpose: firmware download, boot load
>> debugging, and application debugging.
>
> A warning: I think it will be very difficult to use JTAG, only. If you use
> u-boot, you'll need some kind of interactive communication for setting up
> the Linux boot parameters etc. and to see the debug output of u-boot and
> the linux boot process. Maybe this is possible with JTAG, too, and in
> theory you could setup anything before, including the u-boot environment,
> on your development host and then flash it with JTAG, but at least it is
> not the standard way and I think I would need much longer to get a board
> working with JTAG, only.
>
> And if you are running Linux, usually you need some kind of shell access to
> setup init scripts, start daemons and applications for testing etc. Maybe
> you can setup a serial port over USB in Linux, but finding the right driver
> setttings for this USB support and watching the output, if a driver fails
> to load, is impossible without some interactive access in the beginning. 
>
> This would be like giving a braille instruction to a blind person for
> flying an airplane from New York to Cologne :-)

There is the ARM DCC that could possibly be used for this?  Perhaps
someone has put a facility for this into linux & u-boot already since it
is a fairly standard debugger feature.

-- 

John Devereux