Changes between Version 3 and Version 4 of TBR/UserManual/SparcBSPStartup


Ignore:
Timestamp:
Jan 15, 2008, 8:51:50 AM (12 years ago)
Author:
JoelSherrill
Comment:

Spelling, capitalization

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/SparcBSPStartup

    v3 v4  
    44The startup procedure for the SPARC [wiki:TBR/BSP/Erc32 Erc32] and Leon BSPs is complicated.  Jiri Gaisler provided this explanation in response to a user's questions.  See http://www.rtems.com/ml/rtems-users/2005/september/msg00024.html for the original.
    55
    6  *  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...
     6 *  The SPARC port of RTE<S 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. So far so good...
    77
    8  *  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.
     8 *  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.
    99
    10  *  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.
     10 *  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.
    1111
    12  *  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.
     12 *  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.
    1313
    14 Note that these issues are commented in start.S and spurious.c of the sparc/erc32 bsp.
     14Note that these issues are commented in start.S and spurious.c of the ''sparc/erc32'' bsp.
    1515= start.S =
    1616