RTEMS stack + TSIM-LEON2 weird behaviour

[Jiri Gaisler]

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.

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