Re: [ECOS] Error building from CVS sources

[Randall Nortman <ecoslists at wonderclown dot com>]

On Tue, Oct 18, 2005 at 07:59:59PM +0200, Andrew Lunn wrote:
> > Of course, looking at the results in install/bin, I see that
> > redboot.bin is approximately 72k.  I'm not sure that my application
> > can spare that much for the bootloader -- I've got 256kB of Flash and
> > 64kB of RAM, total.  Perhaps I'm barking up the wrong tree here, or
> > perhaps I just need to dig in and trim the thing down to what I need.
> > How small can RedBoot get?  My target is an arm7tdmi, and I expect to
> > use Thumb mode to cut down on code size.  (Specifically, I'm using an
> > Atmel AT91SAM7X256 on a custom-designed board.  I expect to have to
> > write my own HAL, of course, but I just used the existing pid target
> > to get this far.)
> 
> For such a target it does not really make much sense to use RedBoot. I
> suggest you actually just write ROM applications. The AT91SAM7X256 is
> designed to run from ROM, it is no slower than running from RAM. 

Oh, I was planning to run from ROM (i.e., Flash) mostly (except for
interrupt vectors and handlers, which should be fast, and Flash is a
bit slower than RAM), but the gdb interface of RedBoot was very
appealing.  Of course, it didn't occur to me under just now that it
presumably works by overwriting instructions at breakpoints to jump to
RedBoot code (probably via a software interrupt?), which would not be
entirely practical when running from Flash.

Shall I assume also the eCos is a bit too heavy for such a system, or
can it be trimmed down enough?  I have so far been going down the path
of either writing my own simple RTOS or using Contiki (after having
evaluated both FreeRTOS and Nut/OS and found them each unsuitable in
one way or another), using either lwIP or uIP as the IP stack, but now
that I've poked into eCos a bit it seems interesting.  Is it
configurable enough to fit into 256kB Flash and 64kB RAM, including a
TCP/IP stack and leaving room for some simple applications? (Assuming
most of the code runs directly from Flash, that is.)

> The more tricky problem is downloading code and the debugger. You need
> a JTAG programmer to download the code and somehow need to also
> connect gdb to JTAG. There is the cheap wiggler solution or more
> expensive solutions like the BDI2000. You are also limited to two
> hardware break points and no software breakpoints.

This chip actually has a built-in USB transceiver and ROM code which
can be used to program the Flash via USB.  I made this work (after
wrestling with Atmel's rather incomplete documentation), and in fact I
used uIP (with no OS) to make a primitive TCP/IP bootloader in 7kB
that works much faster than USB.  (I could only make the USB protocol
work one word at a time, with acknowledgement after each word.  The
latencies make this very slow.)  I plan to use this as a springboard
for getting a more robust system up and running.

I also got a wiggler to use JTAG, but did not have much luck making it
work, though I only tried for about 20 minutes.  There doesn't seem to
be much free software for JTAG debugging, and what is out there seems
rather raw.  OCD Commander from Macraigor is not Free, only "free",
and does not run well on my 64-bit system.  (I can run it in the
32-bit chroot, but there are weird problems with the GUI layout.)  I
was hoping that RedBoot would be my debugging solution.

Thanks for the help,

Randall

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss