This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problems with hello ecos world



----- 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
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.  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.

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.  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.

regards,

Henri



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]