RTEMS stack + TSIM-LEON2 weird behaviour

[Jiri Gaisler]

The SPARC BSP start-up is discussed in this Wiki article:

http://www.rtems.com/wiki/index.php/SparcBSPStartup

In particulary, see the first paragraph:

"The SPARC port of RTEMS generates binaries that do not perform any board initialisation, and that 
are linked to the beginning of the RAM. The idea behind this is to avoid having a separate bsp for 
every possible board around. Instead, a boot-prom builder (mkprom) is used to create a 
self-extracting prom image that initialises all board registers, loads the application to ram, and 
the starts it. The parameters to mkprom defines memory sizes, waitstates, frequency, stack pointer 
and so on."

When running a RAM image in TSIM, the simulator will recognize that no initialization
has been done, and automatically set the stack pointer, %psr and some other registers
to sane values. I do not see any reason why this should be changed. If you want a bsp
that does the initialization and start-up, I suggest that you create a new bsp rather
that modify the existing one. However, note that a SPARC V8 processor starts at address
0 (in PROM), so you will need to load some code in PROM as well to be able to jump to
the RAM image.

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