Fwd: configuring memory size

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Tue Dec 6 18:55:30 UTC 2005


That approach presents problems when there are very tight & specific
requirements on how an application is laid out in memory.  Further, its
not unreasonable for memory mapped peripherals or missing regions of
memory space to be in the way and if thats the case, memory detection
algorithms might well cause a good deal of trouble.

That said, any such provision for bizarre link scripts and memory sizing
should probably be made by the user project and not be built into the
RTEMS kernel.  So a reasonable compromise might be to arrange a default
linker script and memory map, which the user can override.  But I would
strongly disagree that mandatory automatic memory detection should be
encouraged unless its particularly suited to a given architecture.

Greg



Ed Sutter writes:
 > Can't disagree there!
 > :-)
 > Ed
 > 
 > Till Straumann wrote:
 > 
 > > Sorry for the urge I feel to repeat myself.
 > > IMO, the whole approach of creating multiple linker scripts and binaries,
 > > one for each memory / board configuration is bad.
 > > A single instance should perform a run-time check and configure the
 > > workspace and heap according to the amount of memory detected.
 > > 
 > > T.
 > > 
 > > Ed Sutter wrote:
 > > 
 > >> Peter,
 > >> If you're looking for alternatives, then I also have a homegrown tool
 > >> that I use for this.  Very trivial, but does what I want, essentially
 > >> replacing a few sed/awk script with something that keeps everything to 
 > >> one
 > >> simple command line.
 > >> The purpose is slightly different than Thomas's, so you'll have several
 > >> options!  The purpose is to maintain the address information for the 
 > >> linker
 > >> file in my makefile as a variable.  Then the variable can be included in
 > >> CFLAGS if needed, along with being used as input to a template that 
 > >> creates
 > >> the final linker command file.
 > >> Anyway, the tool (called vsub) is included in the MicroMonitor source 
 > >> distribution
 > >> at http://www.microcross.com/html/micromonitor.html, or I can just send
 > >> you the source for that alone.
 > >> Lemme know if you want it.
 > >> Ed
 > >>
 > >> Thomas Doerfler wrote:
 > >>
 > >>> Hi,
 > >>>
 > >>> just as an additional idea: Some years ago I used the C preprocessor 
 > >>> to generate linker command files from a template. The benefit was, 
 > >>> that I could have ONE header file defining address/size information 
 > >>> for the C compiler and for the linker.
 > >>>
 > >>> Maybe this would also be convenient for Peter?
 > >>>
 > >>> wkr,
 > >>> Thomas.
 > >>>
 > >>>
 > >>> D. Peter Siddons wrote:
 > >>>
 > >>>> Hi Till,
 > >>>> The bsp is very similar to the uC5282. _M68k_Ramsize is copied from 
 > >>>> the linker value (_Ramsize) in bsp_start() (part of bspstart.c). I 
 > >>>> could easily check for the two possibilities here. Is that early 
 > >>>> enough?
 > >>>> Pete.
 > >>>>
 > >>>> Till Straumann wrote:
 > >>>>
 > >>>>> Eric Norum wrote:
 > >>>>>
 > >>>>>>>
 > >>>>>>> Looks like what I suggested won't work.   The linker complains 
 > >>>>>>> if  the expressions in the  ORIGIN/LENGTH contain symbols even if 
 > >>>>>>> those  symbols have been defined before the assignment.
 > >>>>>>>
 > >>>>>>> I guess that you'll need to have two separate linkcmds files and  
 > >>>>>>> use something like
 > >>>>>>>     -Wl,-TlinkcmdsFor4MFlash
 > >>>>>>> or
 > >>>>>>>     -Wl,-TlinkcmdsFor16MFlash
 > >>>>>>
 > >>>>>>
 > >>>>>>
 > >>>>>>
 > >>>>>>
 > >>>>>>
 > >>>>> A much better solution would be enhancing the BSP so it does
 > >>>>> auto-detection. This has to be performed early enough,though.
 > >>>>>
 > >>>>> If an early detection is too cumbersome, then you can limit
 > >>>>> the initial size to a minimum, let's say 4M and increase the
 > >>>>> size later. In order to make the additional ram available to
 > >>>>> RTEMS (i.e., after the malloc heap/libc have been initialized)
 > >>>>> you have to implement a trivial 'sbrk()'. The only constraint
 > >>>>> is that the 'late ram'-portion of the heap to be added by sbrk()
 > >>>>> must be contiguous to the initial heap.
 > >>>>>
 > >>>>> You can look at powerpc/shared/bspstart which uses the
 > >>>>> two-staged heap approach for different reasons.
 > >>>>>
 > >>>>> HTH
 > >>>>> T.
 > >>>>>
 > >>>>>>>
 > >>>>>>>
 > >>>>>>>>
 > >>>>>>>> Eric Norum wrote:
 > >>>>>>>>
 > >>>>>>>>>> You need to pass the --defsym option to the linker.
 > >>>>>>>>>>
 > >>>>>>>>>> On the compile line, add something like
 > >>>>>>>>>>     -Wl,--defsym,_RamSize=0x10000000
 > >>>>>>>>>>
 > >>>>>>>>>> On Dec 2, 2005, at 10:50 PM, D. Peter Siddons wrote:
 > >>>>>>>>>>
 > >>>>>>>>>>> I have two boards which are identical except for the amounts  
 > >>>>>>>>>>> of  flash and RAM. The linkcmds file has definitions for 
 > >>>>>>>>>>> these   parameters like:
 > >>>>>>>>>>> _RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
 > >>>>>>>>>>>
 > >>>>>>>>>>> so my question is, can I invoke a definition somewhere in 
 > >>>>>>>>>>> the   application make process to override the one in 
 > >>>>>>>>>>> linkcmds? If  so,  how and/or where?
 > >>>>>>>>>>>
 > >>>>>>>>>>> Pete.
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>>>>
 > >>>>>>>
 > >>>>>>> -- 
 > >>>>>>> Eric Norum <norume at aps.anl.gov>
 > >>>>>>> Advanced Photon Source
 > >>>>>>> Argonne National Laboratory
 > >>>>>>> (630) 252-4793
 > >>>>>>>
 > >>>>>>>
 > >>>>>>
 > >>>>>
 > >>>>>
 > >>>
 > >>>
 > > 
 > 




More information about the users mailing list