Fwd: configuring memory size

[D. Peter Siddons]

Thanks everyone for your input. I had no idea I was opening such a can 
of worms :) My initial hope was that a simple declaration somewhere in 
my application code or build system could override the linkcmds 
definitions in RTEMS; that would have been perfect. It seems not to be 
possible. Oh well...
Pete.


gregory.menke at gsfc.nasa.gov wrote:

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