[ECOS] problems with hello ecos world

[Jonathan Larmour]

H Girard wrote:
> 
> ----- Original Message -----
> From: "Jonathan Larmour" <jlarmour@redhat.com>
> To: "H Girard" <hgirard@broadbandnetdevices.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, April 10, 2002 4:44 PM
> Subject: Re: [ECOS] problems with hello ecos world
> 
> > H Girard wrote:
> > >
> > > Subject: Re: [ECOS] problems with hello ecos world
> > >
> > > > > Have I missed something or is there an other way??
> > > >
> > > > Yes, you should make a *new* build directory and configure eCos for
> RAM
> > > > startup. Link you application against that library, not the one used
> for
> > > > RedBoot.
> > > >
> > > from the maps of the previous redboot build for rom , and the
> application
> > > build only for ram , it would appear that there would not be enough ram
> to
> > > hold  redboot executable , the ram it requires ,the application and its
> ram
> > > requirement. Using the flash to store & execute redboot & library
> creates a
> > > speed penalty but (on this particular board) there is plenty of flash
> > > compared to ram. If at all possible , i would prefer to use the flash
> > > ressource for execution of redboot(at least for small ram footprints).
> > >
> > > Currently , i suspect that there are 2 possibilities to achieve this :
> > > 1-     include the names and addresses in the linker script for the
> > > references that are in flash (probably requires a script)
> > > 2-    use the -R filename option for the linker that links the
> application
> > > where the filename is the redboot build in flash (yet to get this
> working)
> >
> > Better to program your application into Flash and directly run it from
> > there. You'll need to make a new memory layout for your startup type to be
> > like the ROM one, but with a different flash base address, to leave room
> > for redboot.
> >
> > Note that part of the effect of this should be for the application not to
> > use any RedBoot services so that it can use RedBoot's RAM. So make sure
> > that CYGSEM_HAL_USE_ROM_MONITOR is unset.
> 
> just to make shure i understand :
> you are suggesting to build a libtarget.a with the ..ROM_MONITOR unset

Yep.

> Build the application linking to that library with a memory layout in the
> linker script
>  that is set up to have a flash offset to leave room for redboot ,and a
> ram offset required by redboot.

I'm not sure what you mean by "ram offset required by redboot". The point
about disabling the USE_ROM_MONITOR stuff is so that you can reuse the
memory that redboot is using.

>  Merge both in the flash , run with go
> location where the location is the start
> of the application executable that is now in flash
> or set up the application to be started everytime redboot starts.

Or you can use
fis load <image>
go

which is probably easier/more reliable. The entry point for ARM is
generally the start of the image+0x40 bytes e.g. 0x20040, not 0x20000 if
the image is programmed at 0x20000.
 
> while i understand the end application would run that way with small ram
> footprint
> , it would be convenient to have the capability to debug the new application
> while in ram and download it with gdb.

Ah, that would be somewhat of a problem then, except you could also enable
CYGDBG_HAL_INCLUDE_GDB_STUBS so that the application would itself have GDB
stubs, rather than using redboot's. That way you wouldn't have the space
occupied by other features in redboot.

Or of course you can look at reducing the RAM usage of your program as per
the advice in: http://sources.redhat.com/fom-serv/ecos/cache/89.html
particularly the linker map to show you where the RAM is going.

>  What seems to be preventing this is
> that it is not
> clear how to tell the application to use the functions it needs that are
> already at fixed
> locations in the flash containing redboot instead of having a second copy in
> ram for its own
> private use thus using up more ram than what is on this board.

It's tricky as it would essentially be dynamic loading, something that
isn't easy in eCos.

You could add some custom extensions in RedBoot _and_ eCos to indirect via
a function dispatch table. Still non-trivial, hence my hope to try
something else first.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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