Eclipse ARM toolchain for the Linux

On 25/02/2011 01:29, ChrisQ wrote:
> Grant Edwards wrote:
>> On 2011-02-24, ChrisQ <meru@devnull.com> wrote:
>>
>>> I had a little fun and games building an arm toolchain for Solaris
>>> 10, in that some vesrions of gcc, gdb etc wouldn't build, even after
>>> a lot of tweaking, so I ended up with a bit of a mish mash of
>>> versions. I needed an earlier version of Insight (6.1) because the
>>> one of the debug protocols, which I needed to talk to an Embest
>>> network debug adapter, (Angel) was removed at some stage.
>>
>> The Angel stuff is gone?!?!
>>
>> After all the hours and sweat I put into the RDI and Angel Debugging
>> Protocol stuff, I'm sort of sad knowing it's all been flushed.
>>
>> The RDI/ADP stuff was rather a kludged together pile of junk, but a
>> few of the kludges and some parts of the junk were mine. IIRC, the
>> Insight GUI didn't work at all well with RDI/ADP before I took a
>> hammer to it.
>>
>> I still use RDI/ADP occasionally (last time was a couple months ago),
>> but I've got an ancient version of GDB (5.3) laying around for when I
>> need to do that, and I don't use Insight when I do.
>>
>
> I found something in one of the mailing lists about it. I think it was
> someone at Code Sourcery who proposed it's removal. It was discussed in
> the mailing list, with the Angel stuff described as "cruft". I did get
> in touch, but apparently there are no plans to put it back :-(.
>
> Why remove functionality ?. All it does is exclude certain devices
> without any benefit for those remaining, assuming that the code for each
> protocol is modular, with standard hooks. I remember being quite hacked

I have no idea about this case in particular, but usually functionality 
is removed because it is suffering bit-rot and has no one maintaining 
it.  Theoretically, things like this are modular with well-defined 
interfaces between the parts.  But in practice, things change - new 
versions of the interfaces are defined, and the different parts are 
moved over to the new interface.  If there are only a few older parts 
using the older interfaces, they become costly to maintain and are 
eventually dropped if no one is willing to do the work to update them.

> off about it at the time, but I guess it does make it easier to sell the
> overly expensive Abatron kit without competition :-(. There aren't that
> many
> network based debug adapters and they all tend to be very expensive. One
> new to me that looks interesting, from Norway, is the zylin zy1000. The
> price is not bad as well at around 700 euros. May invest in one later in
> the year, ongpoing work permitting.
>
> Usual disclaimer etc, web site is: www.zylin.com
>

I haven't yet tried the zy1000 - I haven't done much debugging with ARMs 
as yet.  But I know a little about it - Zylin is in our neighbourhood, 
and my company produces the devices.  (So you can assume I'm biased!) 
The devices run OpenOCD directly on the ZY1000, so you get very low 
latency for the low-level jtag communication, and you get everything 
OpenOCD gives you.  Zylin are major contributors to OpenOCD. They also 
made a plugin to improve embedded gdb debugging in Eclipse, though I 
don't think it is needed for modern versions of Eclipse + CDT.

On 23/02/11 23:18, Tim Wescott wrote:
> Eclipse is always Eclipse, it has an editor that has about 98% of what I
> want in an editor (being able to select columns of data, as you can do
> in Codewrite, is really nice but not available in Eclipse), and if I
> don't get your add-ons then you can't make me do things your way.

Eclipse finally got block selection in version 3.5 (Galileo).

You can toggle block selection mode with Alt+Shift+A.

Andy

ChrisQ <meru@devnull.com> writes:

> Grant Edwards wrote:
>> On 2011-02-24, ChrisQ <meru@devnull.com> wrote:
>>
>>> I had a little fun and games building an arm toolchain for Solaris
>>> 10, in that some vesrions of gcc, gdb etc wouldn't build, even after
>>> a lot of tweaking, so I ended up with a bit of a mish mash of
>>> versions. I needed an earlier version of Insight (6.1) because the
>>> one of the debug protocols, which I needed to talk to an Embest
>>> network debug adapter, (Angel) was removed at some stage.
>>
>> The Angel stuff is gone?!?!
>>
>> After all the hours and sweat I put into the RDI and Angel Debugging
>> Protocol stuff, I'm sort of sad knowing it's all been flushed.
>>
>> The RDI/ADP stuff was rather a kludged together pile of junk, but a
>> few of the kludges and some parts of the junk were mine.  IIRC, the
>> Insight GUI didn't work at all well with RDI/ADP before I took a
>> hammer to it.
>>
>> I still use RDI/ADP occasionally (last time was a couple months ago),
>> but I've got an ancient version of GDB (5.3) laying around for when I
>> need to do that, and I don't use Insight when I do.
>>
>
> I found something in one of the mailing lists about it. I think it was
> someone at Code Sourcery who proposed it's removal. It was discussed in
> the mailing list, with the Angel stuff described as "cruft". I did get
> in touch, but apparently there are no plans to put it back :-(.
>
> Why remove functionality ?. All it does is exclude certain devices
> without any benefit for those remaining, assuming that the code for each
> protocol is modular, with standard hooks. I remember being quite hacked
> off about it at the time, but I guess it does make it easier to sell the
> overly expensive Abatron kit without competition :-(. There aren't that many
> network based debug adapters and they all tend to be very expensive. One
> new to me that looks interesting, from Norway, is the zylin zy1000. The
> price is not bad as well at around 700 euros. May invest in one later in
> the year, ongpoing work permitting.

Of course openocd itself can function as a "network based debug
adaptor". I often run it on the lab laptop with a cheap jtag pod while
talking to it from my main development machine. 

I actually prefer this arrangement to my expensive abatron bdi2000,
Openocd supports a wider range of devices and I can use the same cheap
adapters and config files for board testing / production (done
elsewhere).

The zy1000 should be more responsive though for debugging (and perhaps
the company deserves support as contributors to the openocd project).

-- 

John Devereux

On 2011-02-24, ChrisQ <meru@devnull.com> wrote:
> Simon Clubley wrote:
>> 
>> I have also used Insight in the past (but not for remote target debugging)
>> and at one time it was the best gdb front end around, but it's development
>> has stagnated over the last couple of years.
>> 
>> Given that it's so tightly integrated with gdb and that you cannot replace
>> the version of gdb supplied with a Insight kit with a later version, this
>> caused me a problem when I needed to move to a gdb 7.x version a couple
>> of months ago.
>
> I'm not sure that's strictly true. I had a little fun and games building
> an arm toolchain for Solaris 10, in that some vesrions of gcc, gdb etc
> wouldn't build, even after a lot of tweaking, so I ended up with a bit
> of a mish mash of versions. I needed an earlier version of Insight (6.1)
> because the one of the debug protocols, which I needed to talk to an
> Embest network debug adapter,

Interesting.

A Insight source kit ships a copy of gdb as part of the kit (for example,
Insight 6.8 includes it's own version of gdb 6.8) and the Insight build
procedure uses this included copy of gdb, ignoring any other version of
gdb which might be available during building.

I looked to see if there was a way to point the Insight build routines to
a standalone (and later) version of the gdb source kit, but I couldn't find
a way to do this. Postings in the Insight or gdb mailing list from the
authors also claimed that this was not possible, at which point I left it
and started looking for another gdb front end.

If you have found a way to integrate a newer gdb kit into a Insight source
kit, I would really appreciate knowing how you did it.

Thanks,

Simon.

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

David Brown wrote:

> 
> I haven't yet tried the zy1000 - I haven't done much debugging with ARMs 
> as yet.  But I know a little about it - Zylin is in our neighbourhood, 
> and my company produces the devices.  (So you can assume I'm biased!) 
> The devices run OpenOCD directly on the ZY1000, so you get very low 
> latency for the low-level jtag communication, and you get everything 
> OpenOCD gives you.  Zylin are major contributors to OpenOCD. They also 
> made a plugin to improve embedded gdb debugging in Eclipse, though I 
> don't think it is needed for modern versions of Eclipse + CDT.

I'd like to develop this theme of debug adapter pricing. At the far end
of the scale, you have offerings from Abatron, which cost an
astronomical 2000 ukp here in the uk. People like Wind River most likley
have similar prices. Embest have the Unet-Ice, which has network and usb
ports, at a reasonable 300-400 ukp ($400 in the US fwir), but only talks
Angel debug protocol via the net. Then you have the usb only based
boxes, with items like the J-Link, again at an astronomical 1000+ ukp in
the uk, followed by the ulink 2 from Keil at around (iirc) 400.00 ukp,
still pretty steep for a usb only adapter. Then you have the Chinese
knockoffs of the Ulink and J-link at around 20-30 ukp via Ebay and the
Silicon Labs adapter that comes with the si labs development kits. A
replacement si labs adapter costs a mere 40 ukp.

There is a wide disparity in pricing and one has to ask questions like:
If si labs can sell their adapter at 40 ukp, what is so special about
the j-link that justifies a price tag of 1000+ ?. If you take the lid
off, they all seem to have the same amount of hardware internally and
similar build quality, so one can only assume that they charge as much
as they think the market will stand. Same comparison with the abatron vs
unetice at 2000 ukp vs 400 etc ad nauseum.

Network based debug is very useful if the target hardware is more than a
couple of metres away and has the added advantage of isolation, which is
essential for power electronics development, where a ground loop or
spike can very easily zap the debug adapter. Yes, you can buy usb and
jtag isolators, but have you seen the prices ?.
The zylin box, while not cheap, is like a breath of fresh air in terms
of competition, if it works as advertised. The more competition, the better.

Norway. Don't know if you are familiar with labf.com?. Have used their
nfs client for windows (NfsAxe) for years, since around v2 and it just
works out of the box. Just 40 euros per license as well. I think the
hummingbird nfs client was around 500 ukp at the time I was originally
looking, so no prizes for guessing which was used. Some good stuff comes
from the cold North :-)...

Regards,

Chris

Simon Clubley wrote:

> 
> Interesting.
> 
> A Insight source kit ships a copy of gdb as part of the kit (for example,
> Insight 6.8 includes it's own version of gdb 6.8) and the Insight build
> procedure uses this included copy of gdb, ignoring any other version of
> gdb which might be available during building.
> 
> I looked to see if there was a way to point the Insight build routines to
> a standalone (and later) version of the gdb source kit, but I couldn't find
> a way to do this. Postings in the Insight or gdb mailing list from the
> authors also claimed that this was not possible, at which point I left it
> and started looking for another gdb front end.
> 
> If you have found a way to integrate a newer gdb kit into a Insight source
> kit, I would really appreciate knowing how you did it.
> 
> Thanks,
> 
> Simon.
> 

Apologies, you are correct. Just checked the insight build directory and 
there is a subdir labelled gdb !, so it looks like it's included as part 
of insight download. I wonder what would happen if you create a new gdb 
subdir, untgz a different version and run configure ?.  The interesting 
question would be, what's changed to prevent this working ?.

It was August 2008 and I do remember having to go back quite a way with 
gcc and binutils to get a clean build under Solaris.

Gnu software used to be so easy to build. Now you almost need a degree 
in osf makefiles to do anything non standard...

Regards,

Chris

On 2011-02-25, ChrisQ <meru@devnull.com> wrote:
> Grant Edwards wrote:
>> On 2011-02-24, ChrisQ <meru@devnull.com> wrote:
>> 
>>> I had a little fun and games building an arm toolchain for Solaris
>>> 10, in that some vesrions of gcc, gdb etc wouldn't build, even after
>>> a lot of tweaking, so I ended up with a bit of a mish mash of
>>> versions. I needed an earlier version of Insight (6.1) because the
>>> one of the debug protocols, which I needed to talk to an Embest
>>> network debug adapter, (Angel) was removed at some stage.
>> 
>> The Angel stuff is gone?!?!
>> 
>> After all the hours and sweat I put into the RDI and Angel Debugging
>> Protocol stuff, I'm sort of sad knowing it's all been flushed.
>> 
>> The RDI/ADP stuff was rather a kludged together pile of junk, but a
>> few of the kludges and some parts of the junk were mine.  IIRC, the
>> Insight GUI didn't work at all well with RDI/ADP before I took a
>> hammer to it.
>> 
>> I still use RDI/ADP occasionally (last time was a couple months ago),
>> but I've got an ancient version of GDB (5.3) laying around for when I
>> need to do that, and I don't use Insight when I do.
>
> I found something in one of the mailing lists about it. I think it was
> someone at Code Sourcery who proposed it's removal. It was discussed in
> the mailing list, with the Angel stuff described as "cruft". I did get
> in touch, but apparently there are no plans to put it back :-(.
>
> Why remove functionality?

I wasn't following the gdb developers list at the time but my _guess_
is that maybe they didn't (remove functionality when they removed the
Angel stuff from the source tree).  Obscure features/protocols often
end up in a broken state as other parts of the system evolve.  If
there's nobody with the knowlege/desire/hardware/time to maintain the
obscure features, they end up being removed after they've been sitting
in a non-working, non-maintained state for a few years.

In other cases, an obscure feature (that may be working) is removed
because the maintainers know it's going to be broken by a big
refactoring or redesign, and nobody steps ups to bring the obscure
feature forward with the rest of the system.

Or maybe they just got tired of the ugliness.  :)

-- 
Grant Edwards               grant.b.edwards        Yow! We're going to a
                                  at               new disco!
                              gmail.com            

On 2011-02-25, ChrisQ <meru@devnull.com> wrote:
> David Brown wrote:
>
>> 
>> I haven't yet tried the zy1000 - I haven't done much debugging with
>> ARMs as yet.  But I know a little about it - Zylin is in our
>> neighbourhood, and my company produces the devices.  (So you can
>> assume I'm biased!) The devices run OpenOCD directly on the ZY1000,
>> so you get very low latency for the low-level jtag communication, and
>> you get everything OpenOCD gives you.  Zylin are major contributors
>> to OpenOCD. They also made a plugin to improve embedded gdb debugging
>> in Eclipse, though I don't think it is needed for modern versions of
>> Eclipse + CDT.
>
> I'd like to develop this theme of debug adapter pricing. At the far
> end of the scale, you have offerings from Abatron, which cost an
> astronomical 2000 ukp here in the uk. People like Wind River most
> likley have similar prices. Embest have the Unet-Ice, which has
> network and usb ports, at a reasonable 300-400 ukp ($400 in the US
> fwir), but only talks Angel debug protocol via the net.

I don't know if there are other debuggers out there that still talk
the Angel protocol, but Embest (and their customers) might be
well-served by either implimenting the standard GDB remote protocol or
providing a daemon that translates between "GDB remote" and whatever
they do speak.

-- 
Grant Edwards               grant.b.edwards        Yow! The FALAFEL SANDWICH
                                  at               lands on my HEAD and I
                              gmail.com            become a VEGETARIAN ...

On 25/02/2011 16:04, ChrisQ wrote:
> David Brown wrote:
>
>>
>> I haven't yet tried the zy1000 - I haven't done much debugging with
>> ARMs as yet. But I know a little about it - Zylin is in our
>> neighbourhood, and my company produces the devices. (So you can assume
>> I'm biased!) The devices run OpenOCD directly on the ZY1000, so you
>> get very low latency for the low-level jtag communication, and you get
>> everything OpenOCD gives you. Zylin are major contributors to OpenOCD.
>> They also made a plugin to improve embedded gdb debugging in Eclipse,
>> though I don't think it is needed for modern versions of Eclipse + CDT.
>
> I'd like to develop this theme of debug adapter pricing. At the far end
> of the scale, you have offerings from Abatron, which cost an
> astronomical 2000 ukp here in the uk. People like Wind River most likley
> have similar prices. Embest have the Unet-Ice, which has network and usb
> ports, at a reasonable 300-400 ukp ($400 in the US fwir), but only talks
> Angel debug protocol via the net. Then you have the usb only based
> boxes, with items like the J-Link, again at an astronomical 1000+ ukp in
> the uk, followed by the ulink 2 from Keil at around (iirc) 400.00 ukp,
> still pretty steep for a usb only adapter. Then you have the Chinese
> knockoffs of the Ulink and J-link at around 20-30 ukp via Ebay and the
> Silicon Labs adapter that comes with the si labs development kits. A
> replacement si labs adapter costs a mere 40 ukp.
>
> There is a wide disparity in pricing and one has to ask questions like:
> If si labs can sell their adapter at 40 ukp, what is so special about
> the j-link that justifies a price tag of 1000+ ?. If you take the lid
> off, they all seem to have the same amount of hardware internally and
> similar build quality, so one can only assume that they charge as much
> as they think the market will stand. Same comparison with the abatron vs
> unetice at 2000 ukp vs 400 etc ad nauseum.
>
> Network based debug is very useful if the target hardware is more than a
> couple of metres away and has the added advantage of isolation, which is
> essential for power electronics development, where a ground loop or
> spike can very easily zap the debug adapter. Yes, you can buy usb and
> jtag isolators, but have you seen the prices ?.
> The zylin box, while not cheap, is like a breath of fresh air in terms
> of competition, if it works as advertised. The more competition, the
> better.
>

There are several differences in the way these debug boxes work, that 
can influence their price and their worth (though I agree that the two 
concepts don't always correlate well).

The cheapo debuggers are typically made from an FTDI2232 device and a 
couple of level converters.  These work fairly well, and it's easy to 
integrate them into your own boards.  There is good OpenOCD support for 
a whole range of combinations of pinning on these devices.  But they are 
not very fast for downloads (which makes a difference for bigger 
projects), and they have significant latency when the communication is 
two-way.  For example, handling breakpoints requires quite a number of 
messages back and forth between the processor and the host, with each 
bus turnaround taking several milliseconds.

Then there are medium-complexity debuggers which use USB but have a 
dedicated microcontroller (or programmable logic) to handle the 
low-level communication - these greatly reduce the latency for many 
operations.  These are more fussy about the debuggers they will talk to 
- there may or may not be OpenOCD and/or gdb support.

Then you have the high-end devices which again have a local 
microcontroller, and which use Ethernet to communicate with the host. 
These have much higher download speeds, and the low-level communication 
has low latency.  They vary a lot as to which debuggers they support - 
typically, they will work with big-name commercial toolchains.  Some 
will also support gdb directly - Abatron do on their more expensive 
devices (but not on the cheaper ones).

Some devices have trace support - that adds a lot to the cost, but may 
be useful.  Some devices support debugging on a variety of 
architectures, though you often have to pay significantly for "processor 
adaptors" of some sort.

Sometimes the price makes sense, sometimes it does not.  I have in the 
past had parallel port debuggers consisting of a few logic chips and 
costing over a thousand dollars - without software.


The ZY1000 is cheaper than most networked debuggers, and implements 
OpenOCD on the board.  It talks OpenOCD and gdb protocols (and a few 
other protocols I think, but you'd have to check for details).


> Norway. Don't know if you are familiar with labf.com?. Have used their
> nfs client for windows (NfsAxe) for years, since around v2 and it just
> works out of the box. Just 40 euros per license as well. I think the
> hummingbird nfs client was around 500 ukp at the time I was originally
> looking, so no prizes for guessing which was used. Some good stuff comes
> from the cold North :-)...
>

I don't know labf - but then, I haven't looked for an NFS client for 
windows.

It's not /that/ cold here (at least, not normally - the past two winters 
were unusually cold).  I live in the south west, and in the summer it's 
warm enough to swim in the sea, get sunburned, etc.  I've even been 
swimming in the sea north of the Arctic Cirle, under the midnight sun, 
with snow on the tops of the hills over the fjord (and I don't mean 
Finnish style break-the-ice-first swimming - I mean picnic on the beach, 
dry yourself in the sun swimming).

John Devereux wrote:

> Of course openocd itself can function as a "network based debug
> adaptor". I often run it on the lab laptop with a cheap jtag pod while
> talking to it from my main development machine. 

This sound pretty good, as you could even use a pocket pc with network 
and usb to provide a very compact solution. Could you give a few more 
details of what software lives at each end and hints / pointers on where 
to find info on configuration ?. Can do some legwork to get it going, 
but have no in depth knowledge of gdb internals at all. Could be a good 
spare time project.

I already looked into network based usb hubs, (Belkin, Keyspan etc) but 
for at least for Keil ulink and the Si labs adapters, neither work at 
debug level. You can see the remote usb device attached at the host end, 
but the ide can't see it all. I guess they must be bypassing some or all 
of the usb stack, or even poking the hardware directly. Might be a 
config issue, but neither company seemed particularly interested in 
providing help to resolve the issue, nor were forthcoming in terms of 
any explanation...

Regards,

Chris