Changeset 835ece1 in rtems-docs


Ignore:
Timestamp:
Nov 26, 2021, 1:42:03 PM (7 weeks ago)
Author:
Sebastian Huber <sebastian.huber@…>
Branches:
master
Children:
732d8bc
Parents:
87d1f4d
git-author:
Sebastian Huber <sebastian.huber@…> (11/26/21 13:42:03)
git-committer:
Sebastian Huber <sebastian.huber@…> (11/26/21 13:47:12)
Message:

cpu-supplement: Update trap handling for SPARC

Close #4459.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • cpu-supplement/sparc.rst

    r87d1f4d r835ece1  
    11.. SPDX-License-Identifier: CC-BY-SA-4.0
    22
     3.. Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
    34.. Copyright (C) 1988, 2002 On-Line Applications Research Corporation (OAR)
    45
     
    564565and the following instruction.
    565566
     567Trap Table
     568----------
     569
     570A SPARC processor uses a trap table to execute the trap handler associated with
     571a trap.  The trap table location is defined by the Trap Base Register
     572(``TBR``).  The trap table has 256 entries.  Each entry has space for four
     573instructions (16 bytes).  RTEMS uses a statically initialized trap table.  The
     574start address of the trap table is associated with the ``trap_table`` global
     575symbol.  The first action of the system initialization (entry points ``_start``
     576and ``hard_reset``) is to set the ``TBR`` to ``trap_table``.  The interrupt
     577traps (trap numbers 16 to 31) are connected with the RTEMS interrupt handling.
     578Some traps are connected to standard services defined by the SPARC
     579architecture, for example the window overflow, underflow, and flush handling.
     580Most traps are connected to a fatal error handler.  The fatal error trap
     581handler saves the processor context to an exception frame and starts the system
     582termination procedure.
     583
    566584Vectoring of Interrupt Handler
    567585------------------------------
    568586
    569 Upon receipt of an interrupt the SPARC automatically performs the following
    570 actions:
    571 
    572 - disables traps (sets the ET bit of the ``PSR`` to 0),
    573 
    574 - the S bit of the ``PSR`` is copied into the Previous Supervisor Mode (PS) bit of
    575   the ``PSR``,
     587Upon receipt of an interrupt a SPARC processor automatically performs the
     588following actions:
     589
     590- disables traps (sets the ``PSR.ET`` bit to 0 in the ``PSR``),
     591
     592- the ``PSR.S`` bit is copied into the Previous Supervisor Mode (``PSR.PS``)
     593  bit in the ``PSR``,
    576594
    577595- the ``CWP`` is decremented by one (modulo the number of register windows) to
    578596  activate a trap window,
    579597
    580 - the PC and nPC are loaded into local register 1 and 2 (l0 and l1),
    581 
    582 - the trap type (tt) field of the Trap Base Register (``TBR``) is set to the
    583   appropriate value, and
     598- the PC and nPC are loaded into local register 1 and 2 (``%l0`` and ``%l1``),
     599
     600- the trap type (``tt``) field of the Trap Base Register (``TBR``) is set to
     601  the appropriate value, and
    584602
    585603- if the trap is not a reset, then the PC is written with the contents of the
    586   ``TBR`` and the nPC is written with ``TBR`` + 4.  If the trap is a reset, then the PC
    587   is set to zero and the nPC is set to 4.
     604  ``TBR`` and the nPC is written with ``TBR`` + 4.  If the trap is a reset,
     605  then the PC is set to zero and the nPC is set to 4.
    588606
    589607Trap processing on the SPARC has two features which are noticeably different
     
    591609register in effect immediately before the trap occurred is not explicitly
    592610saved.  Instead only reversible alterations are made to it.  Second, the
    593 Processor Interrupt Level (pil) is not set to correspond to that of the
    594 interrupt being processed.  When a trap occurs, ALL subsequent traps are
     611Processor Interrupt Level (``PSR.PIL``) is not set to correspond to that of the
     612interrupt being processed.  When a trap occurs, **all** subsequent traps are
    595613disabled.  In order to safely invoke a subroutine during trap handling, traps
    596614must be enabled to allow for the possibility of register window overflow and
     
    699717by default, trap handlers would execute on the stack of the RTEMS task which
    700718they interrupted.  This artificially inflates the stack requirements for each
    701 task since EVERY task stack would have to include enough space to account for
    702 the worst case interrupt stack requirements in addition to it's own worst case
    703 usage.  RTEMS addresses this problem on the SPARC by providing a dedicated
     719task since **every** task stack would have to include enough space to account
     720for the worst case interrupt stack requirements in addition to it's own worst
     721case usage.  RTEMS addresses this problem on the SPARC by providing a dedicated
    704722interrupt stack managed by software.
    705723
    706 During system initialization, RTEMS allocates the interrupt stack from the
    707 Workspace Area.  The amount of memory allocated for the interrupt stack is
    708 determined by the interrupt_stack_size field in the CPU Configuration Table.
    709 As part of processing a non-nested interrupt, RTEMS will switch to the
     724The interrupt stack is statically allocated by RTEMS.  There is one interrupt
     725stack for each configured processor.  The interrupt stack is used to initialize
     726the system.  The amount of memory allocated for the interrupt stack is
     727determined by the ``CONFIGURE_INTERRUPT_STACK_SIZE`` application configuration
     728option.  As part of processing a non-nested interrupt, RTEMS will switch to the
    710729interrupt stack before invoking the installed handler.
    711730
Note: See TracChangeset for help on using the changeset viewer.