Can one BSP support multiple memory maps?

[gregory.menke at gsfc.nasa.gov]

We're doing it on the Mongoose bsp.  We rigged it by working out
multiple linkscripts which are supplied at the invocation of the
linker.  Their effect is cumulative;


# linkcmd-prolog.ld contains common defintions for all link targets
RTEMSLINK+= -qnostartfile -qnolinkcmds -Wl,-T -Wl,linkcmds/linkcmds-prolog.ld
# either prom or eprom is selected here
RTEMSLINK+= -Wl,-T -Wl,linkcmds/linkcmds-$(LMA).ld
# and the link layout is common
RTEMSLINK+= -Wl,-T -Wl,linkcmds/linkcmds-link.ld

-qnostartfile causes the bsp_specs to not automatically include the
 bsp start code.

-qnolinkcmds causes the bsp_specs to not include the default bsp's
 linkcmds.

Then we supply the "prolog" which sets up some basic sections always
common to this bsp.  The 2nd RTEMSLINK entry picks up one of two files
depending upon the value of $(LMA); we have both files predefined, its
up to the makefile to choose one.  This entry's function is only to
set a given symbol to the starting address of either PROM or EEPROM
memory as our board has both, but in different address regions.  The
3rd section supplies a standard link map which uses regions defined in
the 1st section, setting the LMA to the base address supplied by the
2nd section.  

We have the project's makefile rigged so we can "make prom" to
generate an image linked to run in RAM, with the LMA shifted to PROM
memory.  Or, we can "make eprom" which does the same thing, but shifts
the LMA to the different memory space containing EEPROM.

Since the location of the image is done by the linker, the link script
can use define link symbols which correlate to the actual LMA region.
And, because the actual link map is defined in only 1 file (the 3rd
section), the runtime layout of the program is always the same.

I hope I explained that clearly....

On the Mongoose bsp, the -qnolinkcmds option in the bsp_specs was
already there, so working out the link scripts was the only hurdle.
Our -qnostartfile was helpful for our customized startup (which in
fact depends on the fancied up link map), but not strictly necessary
for general purposes.

Gregm


 
 > The gen68360 is a nice example.  I recall it not only
 > has a ROM and RAM selection option in the bsp_specs, I
 > think it has a way to let the user completely override
 > the defaults.
 > 
 > FYI I recall some user mentioning a trick to avoid 
 > duplicating info between the two linker scripts.  Something
 > about setting values and including a base linker script.
 > Who was that? 
 > 
 > > 
 > > Background:  RTEMS 4.5.0 (not multilib'd) with a custom BSP for our
 > > MPC860 board.
 > > 
 > > Our product supports two different memory configurations (one with
 > > 8 megabytes of RAM and one with 16); the application code knows at
 > > compile time which memory configuration it is targeting.
 > > Can I have two different sets of linkcmds for the application code
 > > without splitting my BSP into two different BSPs?  (That is, two
 > > BSPs that differ only in their memory map.)
 > > 
 > > The only changes needed between the two configurations are the heap
 > > size/location and the start address for the text section.  I hope I
 > > can do this with a single BSP.