[ECOS] problems with hello ecos world

[ECOS] problems with hello ecos world

[H Girard]

Hi

I got redboot working on a new platform based on an idt part : the rc32v332
but i am having difficulty with building a hello.c  program that i can
download to the platform with gdb.
 When i link to the library produced with the default setting and the
target.ld linker script in the /install/lib directory, builds ok, but the
map shows that the hello program is located in the flash area.  the
/mips/mips32/src/mip_mips32.ld was used to build redboot and the library.

when i modify the target.ld to use mostly ram , i run out of ram but
otherwise builds ok. Either way I am stuck.

Looking at the map of the last case (using mostly ram) i notice that several
of the objects in there are already in the redboot in flash. The hello.c
program itself is very small in comparisom to the many other required
functions. All  that should be required is to modify the linker script to
use for the hello.c with the exact addresses of the many functions required
by the build that are already in the flash part running redboot right ????

Does anybody know if there is an automated way to do this : given the map
file of the redboot in flash,  extract the required names and addresses and
format them into a text acceptable by a linker script?   Other people must
have encountered this problem that occurs when you have much more flash
memory than ram or when you want a very small ram footprint.
There are many functions , some taken from the libtarget.a , some taken from
libgcc.a . I would prefer not to have to do this by hand, as it is
error prone and will have to be redone if the exact position or size of the
redboot where to change.

Have I missed something or is there an other way??

thanks in advance.

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

Re: [ECOS] problems with hello ecos world

[Jesper Skov]

On Sat, 2002-04-06 at 03:04, H Girard wrote:
> 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.

Jesper


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

Re: [ECOS] problems with hello ecos world

[H Girard]

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)

thanks

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

Re: [ECOS] problems with hello ecos world

[Jonathan Larmour]

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.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || 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

Re: [ECOS] problems with hello ecos world

[H Girard]

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

Re: [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