RTEMS initializing stack size

[Leon Pollak]

On Thursday January 7 2010, Joel Sherrill wrote:
> On 01/07/2010 04:56 AM, Leon Pollak wrote:
> > Hello, all.
> >
> > The cpu_supplement.pdf states in para 7.6.2 the following (about BSP):
> > - Must set stack pointer (sp or r1) such that a minimum stack size of
> > MINI- MUM_STACK_SIZE bytes is provided for the RTEMS initialization
> > sequence.
> >
> > Now, when I search the RTEMS source tree for MINIMUM_STACK_SIZE, I can
> > not find something looking "normal"...:-)
> >
> > Besides, I found some strange definition:
> > ..c/src/lib/libcpu/powerpc/rtems/powerpc/powerpc.h defines
> > PPC_MIMMUM_STACK_FRAME_SIZE as PPC_STACK_ALIGNMENT, which is 8 or
> > 16...???
> 
> Did you spell minimum wrong like I did on the first grep? It is
> not MIMMUM. :)  Is it that way in the code? <shudder>
SORRY!!!! Typo error.


> #define CPU_STACK_MINIMUM_SIZE          (1024*8)
> #define STACK_MINIMUM_SIZE  CPU_STACK_MINIMUM_SIZE
1. The cpu_supplement book defines the MINIMUM_STACK_SIZE name. Should it be 
CPU_MINIMUM_STACK_SIZE_FRAME?
2. Both definitions you mentioned are absent in 4.9.3. What is correct for it?
3. The problem (with PPC_MINIMUM_STACK_FRAME_SIZE) is in the file powerpc.h in 
4.9.3 too...:-)

 
> I don't know what version you are using but in at least the CVS
> head, that is a "recommended minimum" and you can configure
> the minimum that will be used for tasks.
I am at 4.9.3.

>FWIW I don't think you need 8K for RTEMS init unless you have
>deep calls or buffers in driver initialization.  Also please look
>at how the CVS head code is reserving it.  This has been fine tuned
>and made more consistent across BSPs so you can have separate
>workspace and C program heap or a single heap for both.
Thanks, Joel. 
Please, can you name 1-2 files where I can see this?


> > Just to be precise: I am speaking about the stack area required by RTEMS
> > at its initialization phase, before the first context switch.
> > Thanks ahead for clarifications.
> No problem.  It also gave me a chance to point out some areas
> that have improved in recent times.
Thanks. And this means that switching to the next version will again require 
BSP adaptations...:-)

When the next release is planned? May be I shall wait to do all changes at 
once...

Thanks again.
-- 
Leon