Fwd: configuring memory size

[Ed Sutter]

Ok, thinking more about it, I guess I take back my earlier
statement regarding run-time query, especially when it comes
to a memory bound.  For example, if you use runtime to
determine where your memory end is, you can't really
be certain if it is the end of memory or just a bad device.
Ed

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