|author||Chris Johns <email@example.com>||2016-11-03 16:58:08 +1100|
|committer||Chris Johns <firstname.lastname@example.org>||2016-11-03 16:58:08 +1100|
Rename all manuals with an _ to have a -. It helps released naming of files.
Diffstat (limited to 'cpu-supplement/m68xxx_and_coldfire.rst')
1 files changed, 356 insertions, 0 deletions
diff --git a/cpu-supplement/m68xxx_and_coldfire.rst b/cpu-supplement/m68xxx_and_coldfire.rst
new file mode 100644
@@ -0,0 +1,356 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+.. COMMENT: Copyright (c) 2014 embedded brains GmbH. All rights reserved.
+M68xxx and Coldfire Specific Information
+This chapter discusses the Freescale (formerly Motorola) MC68xxx and Coldfire
+architectural dependencies. The MC68xxx family has a wide variety of CPU
+models within it based upon different CPU core implementations. Ignoring the
+Coldfire parts, the part numbers for these models are generally divided into
+MC680xx and MC683xx. The MC680xx models are more general purpose processors
+with no integrated peripherals. The MC683xx models, on the other hand, are
+more specialized and have a variety of peripherals on chip including
+sophisticated timers and serial communications controllers.
+For information on the MC68xxx and Coldfire architecture, refer to the
+following documents available from Freescale website
+- *M68000 Family Reference, Motorola, FR68K/D*.
+- *MC68020 User's Manual, Motorola, MC68020UM/AD*.
+- *MC68881/MC68882 Floating-Point Coprocessor User's Manual,
+ Motorola, MC68881UM/AD*.
+CPU Model Dependent Features
+This section presents the set of features which vary across m68k/Coldfire
+implementations that are of importance to RTEMS. The set of CPU model feature
+macros are defined in the file :file:`cpukit/score/cpu/m68k/m68k.h` based upon
+the particular CPU model selected on the compilation command line.
+The macro ``M68K_HAS_BFFFO`` is set to 1 to indicate that this CPU model has
+the bfffo instruction.
+Vector Base Register
+The macro ``M68K_HAS_VBR`` is set to 1 to indicate that this CPU model has a
+vector base register (vbr).
+The macro ``M68K_HAS_SEPARATE_STACKS`` is set to 1 to indicate that this CPU
+model has separate interrupt, user, and supervisor mode stacks.
+Pre-Indexing Address Mode
+The macro ``M68K_HAS_PREINDEXING`` is set to 1 to indicate that this CPU model
+has the pre-indexing address mode.
+Extend Byte to Long Instruction
+The macro ``M68K_HAS_EXTB_L`` is set to 1 to indicate that this CPU model has
+the extb.l instruction. This instruction is supposed to be available in all
+models based on the cpu32 core as well as mc68020 and up models.
+The MC68xxx architecture supports a simple yet effective call and return
+mechanism. A subroutine is invoked via the branch to subroutine (``bsr``) or
+the jump to subroutine (``jsr``) instructions. These instructions push the
+return address on the current stack. The return from subroutine (``rts``)
+instruction pops the return address off the current stack and transfers control
+to that instruction. It is is important to note that the MC68xxx call and
+return mechanism does not automatically save or restore any registers. It is
+the responsibility of the high-level language compiler to define the register
+preservation and usage convention.
+All RTEMS directives are invoked using either a ``bsr`` or ``jsr`` instruction
+and return to the user application via the rts instruction.
+As discussed above, the ``bsr`` and ``jsr`` instructions do not automatically
+save any registers. RTEMS uses the registers D0, D1, A0, and A1 as scratch
+registers. These registers are not preserved by RTEMS directives therefore,
+the contents of these registers should not be assumed upon return from any
+RTEMS assumes that arguments are placed on the current stack before the
+directive is invoked via the bsr or jsr instruction. The first argument is
+assumed to be closest to the return address on the stack. This means that the
+first argument of the C calling sequence is pushed last. The following
+pseudo-code illustrates the typical sequence used to call a RTEMS directive
+with three (3) arguments:
+.. code-block:: c
+ push third argument
+ push second argument
+ push first argument
+ invoke directive
+ remove arguments from the stack
+The arguments to RTEMS are typically pushed onto the stack using a move
+instruction with a pre-decremented stack pointer as the destination. These
+arguments must be removed from the stack after control is returned to the
+caller. This removal is typically accomplished by adding the size of the
+argument list in bytes to the current stack pointer.
+The MC68xxx family supports a flat 32-bit address space with addresses ranging
+from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is represented by a
+32-bit value and is byte addressable. The address may be used to reference a
+single byte, word (2-bytes), or long word (4 bytes). Memory accesses within
+this address space are performed in big endian fashion by the processors in
+Some of the MC68xxx family members such as the MC68020, MC68030, and MC68040
+support virtual memory and segmentation. The MC68020 requires external
+hardware support such as the MC68851 Paged Memory Management Unit coprocessor
+which is typically used to perform address translations for these systems.
+RTEMS does not support virtual memory or segmentation on any of the MC68xxx
+Discussed in this section are the MC68xxx's interrupt response and control
+mechanisms as they pertain to RTEMS.
+Vectoring of an Interrupt Handler
+Depending on whether or not the particular CPU supports a separate interrupt
+stack, the MC68xxx family has two different interrupt handling models.
+Models Without Separate Interrupt Stacks
+Upon receipt of an interrupt the MC68xxx family members without separate
+interrupt stacks automatically use software to switch stacks.
+Models With Separate Interrupt Stacks
+Upon receipt of an interrupt the MC68xxx family members with separate interrupt
+stacks automatically perform the following actions:
+- saves the current status register (SR),
+- clears the master/interrupt (M) bit of the SR to indicate the switch from
+ master state to interrupt state,
+- sets the privilege mode to supervisor,
+- suppresses tracing,
+- sets the interrupt mask level equal to the level of the interrupt being
+- pushes an interrupt stack frame (ISF), which includes the program counter
+ (PC), the status register (SR), and the format/exception vector offset (FVO)
+ word, onto the supervisor and interrupt stacks,
+- switches the current stack to the interrupt stack and vectors to an interrupt
+ service routine (ISR). If the ISR was installed with the interrupt_catch
+ directive, then the RTEMS interrupt handler will begin execution. The RTEMS
+ interrupt handler saves all registers which are not preserved according to
+ the calling conventions and invokes the application's ISR.
+A nested interrupt is processed similarly by these CPU models with the
+exception that only a single ISF is placed on the interrupt stack and the
+current stack need not be switched.
+The FVO word in the Interrupt Stack Frame is examined by RTEMS to determine
+when an outer most interrupt is being exited. Since the FVO is used by RTEMS
+for this purpose, the user application code MUST NOT modify this field.
+The following shows the Interrupt Stack Frame for MC68xxx CPU models with
+separate interrupt stacks:
+| Status Register | 0x0 |
+| Program Counter High | 0x2 |
+| Program Counter Low | 0x4 |
+| Format/Vector Offset | 0x6 |
+CPU Models Without VBR and RAM at 0
+This is from a post by Zoltan Kocsi <email@example.com> and is a nice trick
+in certain situations. In his words:
+I think somebody on this list asked about the interupt vector handling w/o VBR
+and RAM at 0. The usual trick is to initialise the vector table (except the
+first 2 two entries, of course) to point to the same location BUT you also add
+the vector number times 0x1000000 to them. That is, bits 31-24 contain the
+vector number and 23-0 the address of the common handler. Since the PC is 32
+bit wide but the actual address bus is only 24, the top byte will be in the PC
+but will be ignored when jumping onto your routine.
+Then your common interrupt routine gets this info by loading the PC into some
+register and based on that info, you can jump to a vector in a vector table
+pointed by a virtual VBR:
+.. code-block:: c
+ // Real vector table at 0
+ .long initial_sp
+ .long initial_pc
+ .long myhandler+0x02000000
+ .long myhandler+0x03000000
+ .long myhandler+0x04000000
+ .long myhandler+0xff000000
+ // This handler will jump to the interrupt routine of which
+ // the address is stored at VBR[ vector_no ]
+ // The registers and stackframe will be intact, the interrupt
+ // routine will see exactly what it would see if it was called
+ // directly from the HW vector table at 0.
+ .comm VBR,4,2 // This defines the 'virtual' VBR
+ // From C: extern void *VBR;
+ myhandler: // At entry, PC contains the full vector
+ move.l %d0,-(%sp) // Save d0
+ move.l %a0,-(%sp) // Save a0
+ lea 0(%pc),%a0 // Get the value of the PC
+ move.l %a0,%d0 // Copy it to a data reg, d0 is VV??????
+ swap %d0 // Now d0 is ????VV??
+ and.w #0xff00,%d0 // Now d0 is ????VV00 (1)
+ lsr.w #6,%d0 // Now d0.w contains the VBR table offset
+ move.l VBR,%a0 // Get the address from VBR to a0
+ move.l (%a0,%d0.w),%a0 // Fetch the vector
+ move.l 4(%sp),%d0 // Restore d0
+ move.l %a0,4(%sp) // Place target address to the stack
+ move.l (%sp)+,%a0 // Restore a0, target address is on TOS
+ ret // This will jump to the handler and
+ // restore the stack
+(1) If 'myhandler' is guaranteed to be in the first 64K, e.g. just
+ after the vector table then that insn is not needed.
+There are probably shorter ways to do this, but it I believe is enough to
+illustrate the trick. Optimisation is left as an exercise to the reader :-)
+Eight levels (0-7) of interrupt priorities are supported by MC68xxx family
+members with level seven (7) being the highest priority. Level zero (0)
+indicates that interrupts are fully enabled. Interrupt requests for interrupts
+with priorities less than or equal to the current interrupt mask level are
+Although RTEMS supports 256 interrupt levels, the MC68xxx family only supports
+eight. RTEMS interrupt levels 0 through 7 directly correspond to MC68xxx
+interrupt levels. All other RTEMS interrupt levels are undefined and their
+behavior is unpredictable.
+Default Fatal Error Processing
+The default fatal error handler for this architecture disables processor
+interrupts to level 7, places the error code in D0, and executes a ``stop``
+instruction to simulate a halt processor instruction.
+SMP is not supported.
+Thread-local storage is supported.
+Board Support Packages
+An RTEMS based application is initiated or re-initiated when the MC68020
+processor is reset. When the MC68020 is reset, the processor performs the
+- The tracing bits of the status register are cleared to disable tracing.
+- The supervisor interrupt state is entered by setting the supervisor (S) bit
+ and clearing the master/interrupt (M) bit of the status register.
+- The interrupt mask of the status register is set to level 7 to effectively
+ disable all maskable interrupts.
+- The vector base register (VBR) is set to zero.
+- The cache control register (CACR) is set to zero to disable and freeze the
+ processor cache.
+- The interrupt stack pointer (ISP) is set to the value stored at vector 0
+ (bytes 0-3) of the exception vector table (EVT).
+- The program counter (PC) is set to the value stored at vector 1 (bytes 4-7)
+ of the EVT.
+- The processor begins execution at the address stored in the PC.
+The address of the application's initialization code should be stored in the
+first vector of the EVT which will allow the immediate vectoring to the
+application code. If the application requires that the VBR be some value
+besides zero, then it should be set to the required value at this point. All
+tasks share the same MC68020's VBR value. Because interrupts are enabled
+automatically by RTEMS as part of the context switch to the first task, the VBR
+MUST be set by either RTEMS of the BSP before this occurs ensure correct
+interrupt vectoring. If processor caching is to be utilized, then it should be
+enabled during the reset application initialization code.
+In addition to the requirements described in the Board Support Packages chapter
+of the Applications User's Manual for the reset code which is executed before
+the call to initialize executive, the MC68020 version has the following
+- Must leave the S bit of the status register set so that the MC68020 remains
+ in the supervisor state.
+- Must set the M bit of the status register to remove the MC68020 from the
+ interrupt state.
+- Must set the master stack pointer (MSP) such that a minimum stack size of
+ MINIMUM_STACK_SIZE bytes is provided for the initialize executive directive.
+- Must initialize the MC68020's vector table.