RES: Strange behavior when running RTEMS on an ERC32 chipset Tharsys board

Fri Sep 9 12:32:47 UTC 2005

Jiri,

Thank you very much for the explanation! I was sure that a trap was
happening and overwriting the trap table, but I could not find what trap,
nor the reason!

I didn't realize that "mov %gX, %tbr" is a synthetic instruction, and it is,
in fact, a "wrtbr", which is a privileged instruction! And because there is
a "ta 0" in the address of the trap type "privileged instruction", the TBR
continues to show me that the last trap ocurred is Ticc (the same as before
the TBR is set), not a privileged instruction. Now everything is clear!

Thank you again!
Best regards,

Fabrício.

-----Mensagem original-----
De: Jiri Gaisler [mailto:jiri at gaisler.com]
Enviada em: quinta-feira, 8 de setembro de 2005 20:44
Para: joel.sherrill at OARcorp.com
Cc: Fabrício de Novaes Kucinskis; RTEMS - Mailing List
Assunto: Re: Strange behavior when running RTEMS on an ERC32 chipset
Tharsys board

This is not a bug. The whole process is somewhat complex
to explain though. So here we go ...

1. The sparc port of rtems generates binaries that do
    not perform any board initialisation, and that are
    linked to the begining 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 selft-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. So far so good...

2. When running on a (recent) erc32 simulator, the rtems
    image is loaded into the emulated ram and started from
    there. The simulator detects that the start address is
    not 0 (sparc reset vector) and perform the necessary
    board init routines that would have been make by mkprom
    on real hardware.

3. An issue with the 3-chip version of ERC32 is that the
    timer scaling register can not be read, only written (!).
    The rtems application can therefore not read the timer
    scaler to figure out which frequency the board is running
    at. To solve this, both the mkprom loader and the simulator
    writes a copy of the scaler value to trap entry 0x7e in
    the sparc trap table, because this trap can never occur
    anyway. The rtems application picks up the value from
    there and now knows the frequency and can generate proper
    timer events etc.

4. Possible cause of the problem: Fabrício could be running rdbmon
    debug monitor on his board, using it to download and start
    applications. rdbmon is an application on its own, and needs
    to insert its trap vectors into the rtems applications
    trap table. This is done by starting the application in
    user mode. The first priviledged instruction that occurs
    is a write to %tbr (trap base register). This instruction
    will trap and control is transfered to rdbmon. The monitor
    can read out the value of the new %tbr, insert its trap
    entries there, write the scaler value in 0x7e of the new
    trap table, and re-start the application is supervisor mode.
    What can not be done (and this is also mentioned in the
    leccs/rdbmon manual) is to single step through this
    procedure. What can also not be done is to use a custom
    loader that does not write 0x7e, or custom start up code
    that re-allocates the trap table.

Note that these issues are commented in start.S and spurious.c
of the sparc/erc32 bsp.

start.S
===============

/*
    This is a sad patch to make sure that we know where the
    MEC timer control register mirror is so we can stop the timers
    from an external debugger. It is needed because the control
    register is write-only. Trap 0x7C cannot occur in ERC32...

    We also use this location to store the last location of the
    usable RAM in order not to overwrite the remote debugger with
    the RTEMS work-space area.

*/

	.global SYM(_ERC32_MEC_Timer_Control_Mirror), SYM(rdb_start),
SYM(CLOCK_SPEED)
	.global SYM(Configuration)

SYM(rdb_start):
SYM(_ERC32_MEC_Timer_Control_Mirror):

   BAD_TRAP; BAD_TRAP;                           ! 7C - 7D undefined

SYM(CLOCK_SPEED):

   .word	0x0a, 0, 0, 0				! 7E (10 MHz default)

spurious.c
===============

   for ( trap=0 ; trap<256 ; trap++ ) {

     /*
      *  Skip window overflow, underflow, and flush as well as software
      *  trap 0 which we will use as a shutdown. Also avoid trap 0x70 - 0x7f
      *  which cannot happen and where some of the space is used to pass
      *  paramaters to the program.
      */

      if (( trap == 5 || trap == 6 ) ||
      	(( trap >= 0x11 ) && ( trap <= 0x1f )) ||
      	(( trap >= 0x70 ) && ( trap <= 0x83 )))
       continue;

     set_vector( (rtems_isr_entry) bsp_spurious_handler,
          SPARC_SYNCHRONOUS_TRAP( trap ), 1 );
   }

Joel Sherrill <joel at OARcorp.com> wrote:
> 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
>>
>
>