Strange behavior when running RTEMS on an ERC32 chipset Tharsys board

[Joel Sherrill <joel@OARcorp.com>]

What version of RTEMS is this with?  I was seeing an issue today with
the CVS head on SIS.  It turned out that the start.s code is copying
initialized data from ROM to RAM but I didn't see anywhere in the 
linkcmds where the initialized data was actually placed there. 
Commenting out "copy_data" loop fixed it.

Can anybody comment on what sections need to be added to the
linkcmds to make this work?

-joel

Fabrício de Novaes Kucinskis wrote:
> I'm working with a Tharsys board with a ERC32 chipset (TSC691E + TSC69È +
> TSC69É), and I noticed a very strange behavior when the RTEMS is being
> initialized.
> 
> When trying to execute the example program "rtems-task" in the board, the
> RTEMS freezes for some seconds, and then the watchdog timer resets the
> board.
> 
> After many hours of debugging, I discovered that the problem occurs when the
> RTEMS tries to read _ CLOCK_SPEED, stored in the address 0x020007e0.  This
> address is in the trap table area of the ERC32.
> 
> At the moment where the RTEMS tries to read this value, what is written in
> this position of memory is not the clock value, but the instruction "ta 0".
> 
> What I noticed was that, in the first instructions of the RTEMS, the Trap
> Base Register (TBR) is configured. At this moment, some addresses of the
> trap table have its routines modified, including the address of
> _CLOCK_SPEED.
> 
> What I don't understand is that the overlapping of trap table occurs in the
> execution of the instruction that modifies the TBR, what for me doesn't make
> sense. I verified the system registers, and none trap occurred at this
> moment.
> 
> It is important to notice that this problem doesn't happen in the Sparc
> Instruction Simulator.
> 
> I solved the problem with a small patch, rewriting the address _ CLOCK_SPEED
> after the TBR configuration, but I would like to know what is triggering the
> overwriting of the trap table.
> 
> Did somebody already find this problem using RTEMS with ERC32 (the real one,
> not the simulator)?

If you get a chance, I would like the output of at least a few of the 
tmtests on real hardware at a known clock speed to compare to the 
simulator.  That was what I was trying to look at today on the simulator 
but became uncertain that the numbers reported were right.  I need a
sanity check against real hardware. :)

> Thanks in advance and best regards,
> 
> 
> 
> Fabrício de Novaes Kucinskis - DEA / INPE
> -----------------------------------------
> Divisão de Eletrônica Aeroespacial
> Instituto Nacional de Pesquisas Espaciais
> 


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