RES: Strange behavior when running RTEMS on an ERC32 chipset Tharsys board
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Fri Sep 9 14:16:30 UTC 2005
Fabrício de Novaes Kucinskis wrote:
> 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!
I thought Jiri's discussion deserved to be Wiki'ed. It is now at
http://www.rtems.com/wiki/index.php/SparcBSPStartup and linked to by the
Erc32 BSP. The other SPARC BSPs should link there was well.
Please feel free to add any comments or corrections, you think are needed.
--joel
> 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
>>>
>>
>>
>
--
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
More information about the users
mailing list