RTEMS stack + TSIM-LEON2 weird behaviour

[Joel Sherrill]

Jiri Gaisler wrote:
> The code at line 228 in start.S stores the memory size into
> address 0x7C0 in the trap table:
>
> Assembly:
>
>         set     (SYM(rdb_start)), %g6   ! End of work-space area
>         st      %sp, [%g6]
>         set     (SYM(Configuration)), %l1
>         ld      [%l1+4], %l3            ! work_space_size
>         sub     %sp, %l3, %sp           ! set %sp to area below work_space
>         andn    %sp, 0x0f, %sp          ! align stack on 16-byte boundary
>
>          mov     %sp, %fp                ! Set frame pointer
>          nop
>
> Simulator:
>
>         49  40001038  0d100001  sethi    %hi(0x40000400), %g6
>         50  4000103c  8c11a3c0  or       %g6, 0x3c0, %g6
>         51  40001040  dc218000  st       %sp, [%g6]
>         60  40001044  2310005b  sethi    %hi(0x40016c00), %l1
>         61  40001048  a2146134  or       %l1, 0x134, %l1
>         62  4000104c  e6046004  ld       [%l1 + 0x4], %l3
>         66  40001050  9c238013  sub      %sp, %l3, %sp
>         75  40001054  9c2ba00f  andn     %sp, 0xf, %sp
>         76  40001058  bc10000e  mov      %sp, %fp
>         77  4000105c  01000000  nop
>
>
> I think that the comment 'End of work-space area' is not quite correct.
> The rdbmon debug stub uses the 0x7C0 info to know how much memory is
> in the system.
>   
I knew it went somewhere but not precisely the magic.
Fix the comment as you see fit and submit it for 4.7 and 4.8.

I think the memory on this BSP (until last week) was laid out
with .bss, C program heap, starting stack and then RTEMS
Workspace.  Weird that the starting stack was in the middle
and unlike any other BSP.

I changed this area of code last week on the head.  The C program
heap and RTEMS workspace are not contiguous and the
starting stack is at the end of memory.  This lets the sparc
BSPs use the new shared code to split the memory up.

--joel
> Jiri.
>
> Joel Sherrill wrote:
>   
>> Jiri Gaisler wrote:
>>     
>>> %sp is set either by the boot loader (mkprom), grmon
>>> or rdbmon (gdb stub). The %sp is also stored to an
>>> unused part of the trap table (0x7C0). This works
>>> fine without any problems on both simulator and
>>> real hardware ...
>>>
>>>       
>> I understand that but what is the purpose
>> of the sub instruction at line 228 of start.S?
>> It is using the original %sp in math to get
>> the starting stack.
>>
>> Is the value of %sp always 0 here?  Or is it
>> possible to be non-zero?
>> If it is always zero, then a mov would be safer.
>>
>> If it is non-zero, does this statement make sense?
>>
>> I trust the environment is right when the BSP
>> gets control.  I have never seen a problem but
>> the math just bothers me and there must be
>> a guarantee I am missing.
>>
>> --joel
>>     
>>> Jiri.
>>>
>>> Joel Sherrill wrote:
>>>
>>>
>>>       
>>>> I don't disagree.  But why is the stack pointer set the way it is in
>>>> start.S? It assumes some value is in %sp from the invoking environment.
>>>> If that
>>>> isn't 0, it looks to me that the code doesn't work.
>>>>
>>>> --joel
>>>>
>>>>         
>>>>> Jiri.
>>>>>
>>>>>
>>>>>
>>>>> Joel Sherrill wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Aitor.Viana.Sanchez at esa.int wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> The initial value of %sp seens to be 0 on the sparc configurations I
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> have.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> So the sub instruction you highlighted above would set the %sp to
>>>>>>>> the area below the work space.
>>>>>>>>         This code hasn't changed in a LONG time and makes
>>>>>>>> assumptions about
>>>>>>>> the execution environment which I cannot personally guarantee.  Jiri
>>>>>>>> would be able to do so.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> i am pretty sure (Jiri will correct me if I am wrong) that TSIM
>>>>>>> initializes %sp and %fp to allow direct RAM execution in case the SW
>>>>>>> does not have a bootstrap SW behind (e.g. mkprom)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> My first thought this morning is that this may have been a valid
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> assumption
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> at one time (initial %sp is 0) but with more variations and starting
>>>>>>>> environments,
>>>>>>>> it may not be valid anymore.  I would guess that the "sub" statement
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> would
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> be better changed to a "mov %l3, %sp" and ignore the inherited %sp.
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> I think this a good solution.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> It is certainly simple.  We need confirmation from Jiri or Daniel.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Regards,
>>>>>>>
>>>>>>> Aitor
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>     


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985