<br><tt><font size=2>This comment just remind me that this should be like
Jiri say, also to clearly separate the bootstrap code from the application
code.</font></tt>
<br>
<br><tt><font size=2>thanks a lot</font></tt>
<br>
<br><tt><font size=2>Aitor</font></tt>
<br>
<br><tt><font size=2><br>
> The SPARC BSP start-up is discussed in this Wiki article:<br>
</font></tt>
<br><tt><font size=2>> http://www.rtems.com/wiki/index.php/SparcBSPStartup<br>
</font></tt>
<br><tt><font size=2>> In particulary, see the first paragraph:<br>
</font></tt>
<br><tt><font size=2>> "The SPARC port of RTEMS generates binaries
that do not perform any <br>
> board initialisation, and that<br>
> are linked to the beginning of the RAM. The idea behind this is to
<br>
> avoid having a separate bsp for<br>
> every possible board around. Instead, a boot-prom builder (mkprom)
<br>
> is used to create a<br>
> self-extracting prom image that initialises all board registers, <br>
> loads the application to ram, and<br>
> the starts it. The parameters to mkprom defines memory sizes, <br>
> waitstates, frequency, stack pointer<br>
> and so on."<br>
</font></tt>
<br><tt><font size=2>> When running a RAM image in TSIM, the simulator
will recognize that <br>
> no initialization<br>
> has been done, and automatically set the stack pointer, %psr and <br>
> some other registers<br>
> to sane values. I do not see any reason why this should be changed.
<br>
> If you want a bsp<br>
> that does the initialization and start-up, I suggest that you create<br>
> a new bsp rather<br>
> that modify the existing one. However, note that a SPARC V8 <br>
> processor starts at address<br>
> 0 (in PROM), so you will need to load some code in PROM as well to
<br>
> be able to jump to<br>
> the RAM image.<br>
</font></tt>
<br><tt><font size=2>> Jiri.<br>
</font></tt>
<br>