From 83fb86f32b73942be758c22423c0bfe506fd4ff6 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Wed, 23 Aug 2006 19:11:14 +0000 Subject: 2006-08-23 Joel Sherrill * Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi, common/cpright.texi: Merging CPU Supplements into a single document. As part of this removed the obsolete and impossible to maintain size and timing information. * cpu_supplement/.cvsignore, cpu_supplement/Makefile.am, cpu_supplement/arm.t, cpu_supplement/i386.t, cpu_supplement/m68k.t, cpu_supplement/mips.t, cpu_supplement/powerpc.t, cpu_supplement/preface.texi, cpu_supplement/sh.t, cpu_supplement/sparc.t, cpu_supplement/tic4x.t: New files. * supplements/.cvsignore, supplements/Makefile.am, supplements/supplement.am, supplements/arm/.cvsignore, supplements/arm/BSP_TIMES, supplements/arm/ChangeLog, supplements/arm/Makefile.am, supplements/arm/arm.texi, supplements/arm/bsp.t, supplements/arm/callconv.t, supplements/arm/cpumodel.t, supplements/arm/cputable.t, supplements/arm/fatalerr.t, supplements/arm/intr_NOTIMES.t, supplements/arm/memmodel.t, supplements/arm/preface.texi, supplements/arm/timeBSP.t, supplements/c4x/.cvsignore, supplements/c4x/BSP_TIMES, supplements/c4x/ChangeLog, supplements/c4x/Makefile.am, supplements/c4x/bsp.t, supplements/c4x/c4x.texi, supplements/c4x/callconv.t, supplements/c4x/cpumodel.t, supplements/c4x/cputable.t, supplements/c4x/fatalerr.t, supplements/c4x/intr_NOTIMES.t, supplements/c4x/memmodel.t, supplements/c4x/preface.texi, supplements/c4x/timeBSP.t, supplements/i386/.cvsignore, supplements/i386/ChangeLog, supplements/i386/FORCE386_TIMES, supplements/i386/Makefile.am, supplements/i386/bsp.t, supplements/i386/callconv.t, supplements/i386/cpumodel.t, supplements/i386/cputable.t, supplements/i386/fatalerr.t, supplements/i386/i386.texi, supplements/i386/intr_NOTIMES.t, supplements/i386/memmodel.t, supplements/i386/preface.texi, supplements/i386/timeFORCE386.t, supplements/m68k/.cvsignore, supplements/m68k/ChangeLog, supplements/m68k/MVME136_TIMES, supplements/m68k/Makefile.am, supplements/m68k/bsp.t, supplements/m68k/callconv.t, supplements/m68k/cpumodel.t, supplements/m68k/cputable.t, supplements/m68k/fatalerr.t, supplements/m68k/intr_NOTIMES.t, supplements/m68k/m68k.texi, supplements/m68k/memmodel.t, supplements/m68k/preface.texi, supplements/m68k/timeMVME136.t, supplements/m68k/timedata.t, supplements/mips/.cvsignore, supplements/mips/BSP_TIMES, supplements/mips/ChangeLog, supplements/mips/Makefile.am, supplements/mips/bsp.t, supplements/mips/callconv.t, supplements/mips/cpumodel.t, supplements/mips/cputable.t, supplements/mips/fatalerr.t, supplements/mips/intr_NOTIMES.t, supplements/mips/memmodel.t, supplements/mips/mips.texi, supplements/mips/preface.texi, supplements/mips/timeBSP.t, supplements/powerpc/.cvsignore, supplements/powerpc/ChangeLog, supplements/powerpc/DMV177_TIMES, supplements/powerpc/Makefile.am, supplements/powerpc/PSIM_TIMES, supplements/powerpc/bsp.t, supplements/powerpc/callconv.t, supplements/powerpc/cpumodel.t, supplements/powerpc/cputable.t, supplements/powerpc/fatalerr.t, supplements/powerpc/intr_NOTIMES.t, supplements/powerpc/memmodel.t, supplements/powerpc/powerpc.texi, supplements/powerpc/preface.texi, supplements/powerpc/timeDMV177.t, supplements/powerpc/timePSIM.t, supplements/sh/.cvsignore, supplements/sh/BSP_TIMES, supplements/sh/ChangeLog, supplements/sh/Makefile.am, supplements/sh/bsp.t, supplements/sh/callconv.t, supplements/sh/cpumodel.t, supplements/sh/cputable.t, supplements/sh/fatalerr.t, supplements/sh/intr_NOTIMES.t, supplements/sh/memmodel.t, supplements/sh/preface.texi, supplements/sh/sh.texi, supplements/sh/timeBSP.t, supplements/sparc/.cvsignore, supplements/sparc/ChangeLog, supplements/sparc/ERC32_TIMES, supplements/sparc/Makefile.am, supplements/sparc/bsp.t, supplements/sparc/callconv.t, supplements/sparc/cpumodel.t, supplements/sparc/cputable.t, supplements/sparc/fatalerr.t, supplements/sparc/intr_NOTIMES.t, supplements/sparc/memmodel.t, supplements/sparc/preface.texi, supplements/sparc/sparc.texi, supplements/sparc/timeERC32.t, supplements/template/.cvsignore, supplements/template/BSP_TIMES, supplements/template/ChangeLog, supplements/template/Makefile.am, supplements/template/bsp.t, supplements/template/callconv.t, supplements/template/cpumodel.t, supplements/template/cputable.t, supplements/template/fatalerr.t, supplements/template/intr_NOTIMES.t, supplements/template/memmodel.t, supplements/template/preface.texi, supplements/template/template.texi, supplements/template/timeBSP.t: Removed. --- doc/supplements/m68k/intr_NOTIMES.t | 266 ------------------------------------ 1 file changed, 266 deletions(-) delete mode 100644 doc/supplements/m68k/intr_NOTIMES.t (limited to 'doc/supplements/m68k/intr_NOTIMES.t') diff --git a/doc/supplements/m68k/intr_NOTIMES.t b/doc/supplements/m68k/intr_NOTIMES.t deleted file mode 100644 index 2568c9f5fa..0000000000 --- a/doc/supplements/m68k/intr_NOTIMES.t +++ /dev/null @@ -1,266 +0,0 @@ -@c -@c Interrupt Stack Frame Picture -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Interrupt Processing - -@section Introduction - -Different types of processors respond to the -occurrence of an interrupt in its own unique fashion. In -addition, each processor type provides a control mechanism to -allow for the proper handling of an interrupt. The processor -dependent response to the interrupt modifies the current -execution state and results in a change in the execution stream. -Most processors require that an interrupt handler utilize some -special control mechanisms to return to the normal processing -stream. Although RTEMS hides many of the processor dependent -details of interrupt processing, it is important to understand -how the RTEMS interrupt manager is mapped onto the processor's -unique architecture. Discussed in this chapter are the MC68xxx's -interrupt response and control mechanisms as they pertain to -RTEMS. - -@section 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. - -@subsection Models Without Separate Interrupt Stacks - -Upon receipt of an interrupt the MC68xxx family -members without separate interrupt stacks automatically perform -the following actions: - -@itemize @bullet -@item To Be Written -@end itemize - -@subsection Models With Separate Interrupt Stacks - -Upon receipt of an interrupt the MC68xxx family -members with separate interrupt stacks automatically perform the -following actions: - -@itemize @bullet -@item saves the current status register (SR), - -@item clears the master/interrupt (M) bit of the SR to -indicate the switch from master state to interrupt state, - -@item sets the privilege mode to supervisor, - -@item suppresses tracing, - -@item sets the interrupt mask level equal to the level of the -interrupt being serviced, - -@item 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, - -@item 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. -@end itemize - -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: - -@ifset use-ascii -@example -@group - +----------------------+ - | Status Register | 0x0 - +----------------------+ - | Program Counter High | 0x2 - +----------------------+ - | Program Counter Low | 0x4 - +----------------------+ - | Format/Vector Offset | 0x6 - +----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\strut\vrule#& -\hbox to 2.00in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 0.50in{\enskip\hfil#\hfil} -\cr -\multispan{3}\hrulefill\cr -& Status Register && 0x0\cr -\multispan{3}\hrulefill\cr -& Program Counter High && 0x2\cr -\multispan{3}\hrulefill\cr -& Program Counter Low && 0x4\cr -\multispan{3}\hrulefill\cr -& Format/Vector Offset && 0x6\cr -\multispan{3}\hrulefill\cr -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - -
Status Register0x0
Program Counter High0x2
Program Counter Low0x4
Format/Vector Offset0x6
-
-@end html -@end ifset - -@section CPU Models Without VBR and RAM at 0 - -This is from a post by Zoltan Kocsi 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: - -@example -// -// 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. - -@end example - -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 :-) - - -@section Interrupt Levels - -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 ignored. - -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. - -@section Disabling of Interrupts by RTEMS - -During the execution of directive calls, critical -sections of code may be executed. When these sections are -encountered, RTEMS disables interrupts to level seven (7) before -the execution of this section and restores them to the previous -level upon completion of the section. RTEMS has been optimized -to insure that interrupts are disabled for less than -RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz MC68020 with -zero wait states. These numbers will vary based the -number of wait states and processor speed present on the target board. -[NOTE: The maximum period with interrupts disabled is hand calculated. This -calculation was last performed for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -Non-maskable interrupts (NMI) cannot be disabled, and -ISRs which execute at this level MUST NEVER issue RTEMS system -calls. If a directive is invoked, unpredictable results may -occur due to the inability of RTEMS to protect its critical -sections. However, ISRs that make no system calls may safely -execute as non-maskable interrupts. - -@section Interrupt Stack - -RTEMS allocates the interrupt stack from the -Workspace Area. The amount of memory allocated for the -interrupt stack is determined by the interrupt_stack_size field -in the CPU Configuration Table. During the initialization -process, RTEMS will install its interrupt stack. - -The MC68xxx port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - -- cgit v1.2.3