On Feb 20, 1:49=A0am, Juergen Beisert <jbeis...@netscape.net> wrote:
> emeb wrote:
> > I'm using arm-elf-gcc to write embedded code targeting the NXP
> > LPC2148. My application code will be loaded from an SD card into the
> > MCU flash and run by an existing bootloader described in more detail
> > here:
>
> >http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=3D94
>
> > This bootloader contains a number of utility / library routines that
> > I'd like to be able to use from my own application rather than
> > duplicating the same code in my binary file. Since I've compiled &
> > flashed the bootloader myself, I have access to all the linker output
> > from the build process, including the maps, lists and symbol tables
> > and I know what the function addresses are. What I need is a clean way
> > to let the compiler/linker know this when I prepare the application
> > code.
>
> > This sounds to me kind of like linking against a shared library, but
> > since this is an embedded application I'm sure that the process is
> > very different. I've done a bit of checking around but haven't found
> > anything that looks similar enough to what I'm trying to do to be a
> > good starting point.
>
> > Any suggestions on where I should start with this?
>
> Keep the final elf file of your bootloader and link your new application
> code with the linker parameter --just-symbols=3D<your bootloader elf file=
>.
> This will force the linker to link all references in your new application
> to the bootloader in an absolute manner. So your application code can run
> anywhere from RAM while it calls code from your bootloader (at a fixed
> address) in flash.

That sounds like exactly what I want. I'll give that a try.

Thanks,

Eric

emeb wrote:

> I'm using arm-elf-gcc to write embedded code targeting the NXP
> LPC2148. My application code will be loaded from an SD card into the
> MCU flash and run by an existing bootloader described in more detail
> here:
> 
> http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=94
> 
> This bootloader contains a number of utility / library routines that
> I'd like to be able to use from my own application rather than
> duplicating the same code in my binary file. Since I've compiled &
> flashed the bootloader myself, I have access to all the linker output
> from the build process, including the maps, lists and symbol tables
> and I know what the function addresses are. What I need is a clean way
> to let the compiler/linker know this when I prepare the application
> code.
> 
> This sounds to me kind of like linking against a shared library, but
> since this is an embedded application I'm sure that the process is
> very different. I've done a bit of checking around but haven't found
> anything that looks similar enough to what I'm trying to do to be a
> good starting point.
> 
> Any suggestions on where I should start with this?

Keep the final elf file of your bootloader and link your new application
code with the linker parameter --just-symbols=<your bootloader elf file>.
This will force the linker to link all references in your new application
to the bootloader in an absolute manner. So your application code can run
anywhere from RAM while it calls code from your bootloader (at a fixed
address) in flash.

Hope it helps.
jbe

"emeb" <ebrombaugh@gmail.com> wrote in message
news:56ce350c-27a3-4a31-b8a3-0919918abc63@f29g2000vbf.googlegroups.com...
> I'm using arm-elf-gcc to write embedded code targeting the NXP
> LPC2148. My application code will be loaded from an SD card into the
> MCU flash and run by an existing bootloader described in more detail
> here:
>
> http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=94
>
> This bootloader contains a number of utility / library routines that
> I'd like to be able to use from my own application rather than
> duplicating the same code in my binary file. Since I've compiled &
> flashed the bootloader myself, I have access to all the linker output
> from the build process, including the maps, lists and symbol tables
> and I know what the function addresses are. What I need is a clean way
> to let the compiler/linker know this when I prepare the application
> code.

There are several solutions to this problem. You can use (a) software
interrupt(s) to access functions in the bootloader, you can create a call
table at a fixed address and even let the bootloader pass a pointer to that
table to main(). The benefit of this approach is that you don't need to
rebuild your application when the bootloader changes.

Meindert

I'm using arm-elf-gcc to write embedded code targeting the NXP
LPC2148. My application code will be loaded from an SD card into the
MCU flash and run by an existing bootloader described in more detail
here:

http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=94

This bootloader contains a number of utility / library routines that
I'd like to be able to use from my own application rather than
duplicating the same code in my binary file. Since I've compiled &
flashed the bootloader myself, I have access to all the linker output
from the build process, including the maps, lists and symbol tables
and I know what the function addresses are. What I need is a clean way
to let the compiler/linker know this when I prepare the application
code.

This sounds to me kind of like linking against a shared library, but
since this is an embedded application I'm sure that the process is
very different. I've done a bit of checking around but haven't found
anything that looks similar enough to what I'm trying to do to be a
good starting point.

Any suggestions on where I should start with this?

Eric