RE: [ECOS] memory maps, linker control files, etc.

[Gary Thomas <gary at mlbassoc dot com>]

On Wed, 2005-09-28 at 15:03 -0700, Andrew Voelkel wrote:
> >> This lack of information stands in the way of my understand basic things
> >> like how Redboot and an ECOS application can both use system memory
> >without
> >> stepping on each other - an issue that I've handled manually in other
> >> situations. 
> >> 
> >> Even figuring out how to generate a linker map file involved poring
> >through
> >> the giant man page for arm-elf-gcc.
> >
> >Normally it is not necassary to change anything. The only time you do
> >is when you are porting to different hardware, adding or removing
> >memory etc.
> >
> >Generally each port has two setups, ROM and RAM. Redboot use the ROM
> >setup and the application uses the RAM setup. Generally the lower part
> >of RAM is reserved for the ROM redboot to put its stack, bss, etc. The
> >size of this is hard coded. 
> >
> >So take for example the ebsa285....
> 
> So the ROMRAM or RAM versions of redboot cannot be used to load and debug
> ECOS programs? I don't remember reading that anywhere. But of course I've
> been reading so much new stuff, I may have not have noticed it.

Not correct.  ROMRAM is used for RedBoot (or any monitor) and is 
perfectly suited for loading RAM programs.  RAM mode is designed for
general eCos applications.

The ROMRAM and RAM loader templates (.ldi files) are structured so that
memory used by one does not conflict with the other.  In most cases, 
ROMRAM uses a chunk of low memory and RAM version are allowed to use
everything else.

> 
> If this is true, it would be consistent with my observation that the .ldi
> files for configurations derived from the Redboot ROMRAM template and the
> "default" ROMRAM template seem to be identical.

The template used has no effect on the memory layout - only the 
HAL_STARTUP setting changes this.

> 
> This brings up a couple more questions, one of which has been rattling
> around in my brain for a bit:
> 
> 1. What is the purpose of the ROMRAM and RAM versions of Redboot, if they
> cannot be used for loading and running ECOS programs?

See above.

> 
> 2. Why use the GDB stubs in Redboot to debug ECOS programs, when you can
> just have the ECOS program take over completely and have their own GDB
> stubs? That seems a simpler model, without the complexity of the VVTs,
> Ethernet port sharing, etc. When one is finished debugging, one can simply
> press the reset switch on the eval board to restart Redboot. Or, in the case
> where the program exits itself, one could trigger a hard system reset from
> ROM via software. The only reason I can think of to leave Redboot around
> while an ECOS program is running is to use its other capabilities during the
> operation of an ECOS program. It strikes me that this capability is not
> needed very often. What am I missing?

True enough (all you need to do is make your configuration not use the
rom monitor).  That said, why waste/duplicate code which is already in
memory that can be reused?  Also, it affords a much more seamless 
operation for many things.  For example, many systems have more than
one possible console device.  RedBoot can choose amongst these and when
an eCos program is loaded, it will continue to use that device for it's
debug I/O.  This even works over the network, which can be real slick.
Here's a little example, from my desktop:
  [gthomas@hermes wiggler]$ telnet 192.168.1.249 9000
  Trying 192.168.1.249...
  Connected to 192.168.1.249.
  Escape character is '^]'.
  RedBoot> lo a.test
  Using default protocol (TFTP)
  Entry point: 0x00060000, address range: 0x00060000-0x002f0878
  RedBoot> g
  BOOTP[eth0] op: REQUEST
         htype: Ethernet
          hlen: 6
          hops: 0
           xid: 0xf026a233
          secs: 0
  ...

If my program didn't have RedBoot around (and the connection I made),
this would not be possible.

However, since eCos is totally configurable (that's what it stands 
for!), you are free to do things as you wish.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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