This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Possible similar Setups trying to use the ARM Developer Suite with ECOS
- To: Jason van Aardt <Jason at roninwireless dot com>
- Subject: Re: [ECOS] Possible similar Setups trying to use the ARM Developer Suite with ECOS
- From: Grant Edwards <grante at visi dot com>
- Date: Mon, 18 Sep 2000 13:26:12 -0500
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <s9c66c34.075@roninwireless.com>
On Mon, Sep 18, 2000 at 07:25:07PM +0200, Jason van Aardt wrote:
> Has anyone else tried using the ARM developer Suite Tools
> (armasm, compiler and linker) to build ECOS for the ARM
> processor?
Various people have tinkered with using non-gcc compilers, I
don't know if anybody has gotten it to work. If you do, you're
going to be on your own...
> I personally would prefer to use linux and the GNU tools,
> however, there is a requirement to use the debugger that comes
> with the ADS (ARM Debugger for Windows), which supports
> debuging via the JTAG port. Our application is timing critial
> (ok all embedded apps are;) ), and as far as I understand, GDB
> only supports " softice" debugging via the serial (or ethernet
> ports).
Gdb currently supports using the JTAG port via either of two
JTAG interface boxes: the Jeeni from EPI or the EmbeddedICE
from ARM. With recent patches, Insight also works. Hint: the
"RDI" target is the one that talks to the JTAG boxes, so if you
search the archive for RDI, you'll see the relevent messages.
There is reportedly a Gdb target in the works for the
EmbeddedICE successor (MultiICE). It uses a different protocol
than the earlier JTAG boxes and therefore won't work with the
existing RDI target code in gdb.
> As I understand, the ARM has specialised hardware, which can be
> connected to via the JTAG interface, which can perform
> debugging (MULTI-ICE), and the ADW supports this.
Correct -- as does Gdb, though I don't know if multi-ice
support has been released to the public.
> My concern over timing is is due to the fact that our
> application interfaces to dedicated "phsical layer" hardware
> for a cellular phone , and the timing critical chain is the
> control path to the physical layer.
Even if you do software debugging (via gdb stubs) instead of
the JTAG port, timing of your executing code is unaffected.
Downloading is a lot faster via JTAG, and it's slightly easier
to regain control via JTAG when your target software runs off
into the weeds. JTAG also alows you to put a breakpoint in ROM
code.
> Has anyone any comments about the merits of a Softice( debug
> monitor) versus this "JTAG MULTI_ICE approach"?
JTAG is nice if you don't have an "extra" serial/ethernet port.
> I personally have only ever use the softice approach (paradigm
> on x86) and a "real ICE" (plugs in where the CPU normally plugs
> in)
JTAG debugging is a lot closer to soft-ICE than it is to "real
ICE". JTAG has no trace buffer, no overlay memory, and only
supports a couple hardware breakpoints. Except for the
hardware breakpoints, you're basically doing soft-ICE though a
dedicated high speed sync serial port (which is nice compared
to gluing on an extra Ethernet or RS-232 port)..
> After wading through the mailing list, I realise that the
> general answer to "is is possible to compile ECOS with compiler
> X" is NO as ECOS uses GCC specific thingamabobs.
My _guess_ is that it would be easier to get the gnu output
files converted to a format that the ARM debugger understands
than it would be to compile eCos w/ ARM's compiler. But, I
haven't tried to do either, so I'm just shooting from the hip.
Some of the other commerical debugger products (e.g. X-RAY)
support Multi-ICE and gnu ELF object file formats. I've not
tried any of them, but that's what vendors claimed at the
Embedded systems conference last spring.
> I have spent some time compiling ECOS with armcc, and although
> I see some GCC specific things, most of them I have been able
> to get around( ignoring the attribute directive though, and a
> couple others ), and have got the C source files to compile
> with only warnings(mostly about unused parameters).
> However the ASM is proving to be a nightmare (but slowly
> getting there) And I am therefore nowhere near linking.
ISTR that there is some fancy (gcc specific) stuff done with
C++ initialization methods or something like that. Others know
more about that than do I.
> Basically I want to know if what I am trying to do is a
> complete and utter waste of time, as it is impossible, and
> there are other things I am missing/misunderstanding.
If I were you, I would (in order)
1) Try to talk whoever has the Multi-ICE support for gdb into
giving you a copy.
2) Look into commercial debuggers if you've got the money.
3) Look into converting ELF into whatever format you need.
[...]
n) Try to build eCos with ARM compiler/assembler/linker
--
Grant Edwards
grante@visi.com