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/ChangeLog | 78 +++ doc/FAQ/stamp-vti | 4 +- doc/FAQ/version.texi | 4 +- doc/Makefile.am | 2 +- doc/common/cpright.texi | 4 +- doc/configure.ac | 11 +- doc/cpu_supplement/.cvsignore | 28 + doc/cpu_supplement/Makefile.am | 81 +++ doc/cpu_supplement/arm.t | 595 ++++++++++++++++ doc/cpu_supplement/i386.t | 694 +++++++++++++++++++ doc/cpu_supplement/m68k.t | 773 +++++++++++++++++++++ doc/cpu_supplement/mips.t | 677 +++++++++++++++++++ doc/cpu_supplement/powerpc.t | 1043 ++++++++++++++++++++++++++++ doc/cpu_supplement/preface.texi | 25 + doc/cpu_supplement/sh.t | 685 +++++++++++++++++++ doc/cpu_supplement/sparc.t | 1127 +++++++++++++++++++++++++++++++ doc/cpu_supplement/tic4x.t | 888 ++++++++++++++++++++++++ doc/supplements/.cvsignore | 2 - doc/supplements/Makefile.am | 13 - doc/supplements/arm/.cvsignore | 31 - doc/supplements/arm/BSP_TIMES | 247 ------- doc/supplements/arm/ChangeLog | 83 --- doc/supplements/arm/Makefile.am | 110 --- doc/supplements/arm/arm.texi | 115 ---- doc/supplements/arm/bsp.t | 93 --- doc/supplements/arm/callconv.t | 73 -- doc/supplements/arm/cpumodel.t | 82 --- doc/supplements/arm/cputable.t | 109 --- doc/supplements/arm/fatalerr.t | 37 - doc/supplements/arm/intr_NOTIMES.t | 122 ---- doc/supplements/arm/memmodel.t | 38 -- doc/supplements/arm/preface.texi | 49 -- doc/supplements/arm/timeBSP.t | 113 ---- doc/supplements/c4x/.cvsignore | 31 - doc/supplements/c4x/BSP_TIMES | 247 ------- doc/supplements/c4x/ChangeLog | 49 -- doc/supplements/c4x/Makefile.am | 108 --- doc/supplements/c4x/bsp.t | 93 --- doc/supplements/c4x/c4x.texi | 116 ---- doc/supplements/c4x/callconv.t | 161 ----- doc/supplements/c4x/cpumodel.t | 82 --- doc/supplements/c4x/cputable.t | 109 --- doc/supplements/c4x/fatalerr.t | 31 - doc/supplements/c4x/intr_NOTIMES.t | 196 ------ doc/supplements/c4x/memmodel.t | 160 ----- doc/supplements/c4x/preface.texi | 64 -- doc/supplements/c4x/timeBSP.t | 108 --- doc/supplements/i386/.cvsignore | 31 - doc/supplements/i386/ChangeLog | 72 -- doc/supplements/i386/FORCE386_TIMES | 247 ------- doc/supplements/i386/Makefile.am | 111 --- doc/supplements/i386/bsp.t | 109 --- doc/supplements/i386/callconv.t | 90 --- doc/supplements/i386/cpumodel.t | 72 -- doc/supplements/i386/cputable.t | 119 ---- doc/supplements/i386/fatalerr.t | 31 - doc/supplements/i386/i386.texi | 114 ---- doc/supplements/i386/intr_NOTIMES.t | 168 ----- doc/supplements/i386/memmodel.t | 72 -- doc/supplements/i386/preface.texi | 41 -- doc/supplements/i386/timeFORCE386.t | 101 --- doc/supplements/m68k/.cvsignore | 31 - doc/supplements/m68k/ChangeLog | 86 --- doc/supplements/m68k/MVME136_TIMES | 247 ------- doc/supplements/m68k/Makefile.am | 111 --- doc/supplements/m68k/bsp.t | 93 --- doc/supplements/m68k/callconv.t | 92 --- doc/supplements/m68k/cpumodel.t | 91 --- doc/supplements/m68k/cputable.t | 109 --- doc/supplements/m68k/fatalerr.t | 31 - doc/supplements/m68k/intr_NOTIMES.t | 266 -------- doc/supplements/m68k/m68k.texi | 115 ---- doc/supplements/m68k/memmodel.t | 39 -- doc/supplements/m68k/preface.texi | 60 -- doc/supplements/m68k/timeMVME136.t | 112 --- doc/supplements/m68k/timedata.t | 154 ----- doc/supplements/mips/.cvsignore | 31 - doc/supplements/mips/BSP_TIMES | 247 ------- doc/supplements/mips/ChangeLog | 76 --- doc/supplements/mips/Makefile.am | 111 --- doc/supplements/mips/bsp.t | 93 --- doc/supplements/mips/callconv.t | 92 --- doc/supplements/mips/cpumodel.t | 68 -- doc/supplements/mips/cputable.t | 109 --- doc/supplements/mips/fatalerr.t | 31 - doc/supplements/mips/intr_NOTIMES.t | 196 ------ doc/supplements/mips/memmodel.t | 39 -- doc/supplements/mips/mips.texi | 114 ---- doc/supplements/mips/preface.texi | 57 -- doc/supplements/mips/timeBSP.t | 112 --- doc/supplements/powerpc/.cvsignore | 32 - doc/supplements/powerpc/ChangeLog | 72 -- doc/supplements/powerpc/DMV177_TIMES | 248 ------- doc/supplements/powerpc/Makefile.am | 125 ---- doc/supplements/powerpc/PSIM_TIMES | 248 ------- doc/supplements/powerpc/bsp.t | 76 --- doc/supplements/powerpc/callconv.t | 229 ------- doc/supplements/powerpc/cpumodel.t | 156 ----- doc/supplements/powerpc/cputable.t | 155 ----- doc/supplements/powerpc/fatalerr.t | 47 -- doc/supplements/powerpc/intr_NOTIMES.t | 184 ----- doc/supplements/powerpc/memmodel.t | 110 --- doc/supplements/powerpc/powerpc.texi | 115 ---- doc/supplements/powerpc/preface.texi | 94 --- doc/supplements/powerpc/timeDMV177.t | 113 ---- doc/supplements/powerpc/timePSIM.t | 97 --- doc/supplements/sh/.cvsignore | 31 - doc/supplements/sh/BSP_TIMES | 247 ------- doc/supplements/sh/ChangeLog | 76 --- doc/supplements/sh/Makefile.am | 111 --- doc/supplements/sh/bsp.t | 93 --- doc/supplements/sh/callconv.t | 102 --- doc/supplements/sh/cpumodel.t | 68 -- doc/supplements/sh/cputable.t | 109 --- doc/supplements/sh/fatalerr.t | 31 - doc/supplements/sh/intr_NOTIMES.t | 196 ------ doc/supplements/sh/memmodel.t | 39 -- doc/supplements/sh/preface.texi | 55 -- doc/supplements/sh/sh.texi | 114 ---- doc/supplements/sh/timeBSP.t | 112 --- doc/supplements/sparc/.cvsignore | 31 - doc/supplements/sparc/ChangeLog | 72 -- doc/supplements/sparc/ERC32_TIMES | 247 ------- doc/supplements/sparc/Makefile.am | 108 --- doc/supplements/sparc/bsp.t | 87 --- doc/supplements/sparc/callconv.t | 392 ----------- doc/supplements/sparc/cpumodel.t | 128 ---- doc/supplements/sparc/cputable.t | 102 --- doc/supplements/sparc/fatalerr.t | 32 - doc/supplements/sparc/intr_NOTIMES.t | 199 ------ doc/supplements/sparc/memmodel.t | 104 --- doc/supplements/sparc/preface.texi | 91 --- doc/supplements/sparc/sparc.texi | 113 ---- doc/supplements/sparc/timeERC32.t | 120 ---- doc/supplements/supplement.am | 16 - doc/supplements/template/.cvsignore | 31 - doc/supplements/template/BSP_TIMES | 247 ------- doc/supplements/template/ChangeLog | 76 --- doc/supplements/template/Makefile.am | 110 --- doc/supplements/template/bsp.t | 93 --- doc/supplements/template/callconv.t | 92 --- doc/supplements/template/cpumodel.t | 68 -- doc/supplements/template/cputable.t | 109 --- doc/supplements/template/fatalerr.t | 31 - doc/supplements/template/intr_NOTIMES.t | 196 ------ doc/supplements/template/memmodel.t | 39 -- doc/supplements/template/preface.texi | 55 -- doc/supplements/template/template.texi | 115 ---- doc/supplements/template/timeBSP.t | 112 --- 149 files changed, 6702 insertions(+), 13981 deletions(-) create mode 100644 doc/cpu_supplement/.cvsignore create mode 100644 doc/cpu_supplement/Makefile.am create mode 100644 doc/cpu_supplement/arm.t create mode 100644 doc/cpu_supplement/i386.t create mode 100644 doc/cpu_supplement/m68k.t create mode 100644 doc/cpu_supplement/mips.t create mode 100644 doc/cpu_supplement/powerpc.t create mode 100644 doc/cpu_supplement/preface.texi create mode 100644 doc/cpu_supplement/sh.t create mode 100644 doc/cpu_supplement/sparc.t create mode 100644 doc/cpu_supplement/tic4x.t delete mode 100644 doc/supplements/.cvsignore delete mode 100644 doc/supplements/Makefile.am delete mode 100644 doc/supplements/arm/.cvsignore delete mode 100644 doc/supplements/arm/BSP_TIMES delete mode 100644 doc/supplements/arm/ChangeLog delete mode 100644 doc/supplements/arm/Makefile.am delete mode 100644 doc/supplements/arm/arm.texi delete mode 100644 doc/supplements/arm/bsp.t delete mode 100644 doc/supplements/arm/callconv.t delete mode 100644 doc/supplements/arm/cpumodel.t delete mode 100644 doc/supplements/arm/cputable.t delete mode 100644 doc/supplements/arm/fatalerr.t delete mode 100644 doc/supplements/arm/intr_NOTIMES.t delete mode 100644 doc/supplements/arm/memmodel.t delete mode 100644 doc/supplements/arm/preface.texi delete mode 100644 doc/supplements/arm/timeBSP.t delete mode 100644 doc/supplements/c4x/.cvsignore delete mode 100644 doc/supplements/c4x/BSP_TIMES delete mode 100644 doc/supplements/c4x/ChangeLog delete mode 100644 doc/supplements/c4x/Makefile.am delete mode 100644 doc/supplements/c4x/bsp.t delete mode 100644 doc/supplements/c4x/c4x.texi delete mode 100644 doc/supplements/c4x/callconv.t delete mode 100644 doc/supplements/c4x/cpumodel.t delete mode 100644 doc/supplements/c4x/cputable.t delete mode 100644 doc/supplements/c4x/fatalerr.t delete mode 100644 doc/supplements/c4x/intr_NOTIMES.t delete mode 100644 doc/supplements/c4x/memmodel.t delete mode 100644 doc/supplements/c4x/preface.texi delete mode 100644 doc/supplements/c4x/timeBSP.t delete mode 100644 doc/supplements/i386/.cvsignore delete mode 100644 doc/supplements/i386/ChangeLog delete mode 100644 doc/supplements/i386/FORCE386_TIMES delete mode 100644 doc/supplements/i386/Makefile.am delete mode 100644 doc/supplements/i386/bsp.t delete mode 100644 doc/supplements/i386/callconv.t delete mode 100644 doc/supplements/i386/cpumodel.t delete mode 100644 doc/supplements/i386/cputable.t delete mode 100644 doc/supplements/i386/fatalerr.t delete mode 100644 doc/supplements/i386/i386.texi delete mode 100644 doc/supplements/i386/intr_NOTIMES.t delete mode 100644 doc/supplements/i386/memmodel.t delete mode 100644 doc/supplements/i386/preface.texi delete mode 100644 doc/supplements/i386/timeFORCE386.t delete mode 100644 doc/supplements/m68k/.cvsignore delete mode 100644 doc/supplements/m68k/ChangeLog delete mode 100644 doc/supplements/m68k/MVME136_TIMES delete mode 100644 doc/supplements/m68k/Makefile.am delete mode 100644 doc/supplements/m68k/bsp.t delete mode 100644 doc/supplements/m68k/callconv.t delete mode 100644 doc/supplements/m68k/cpumodel.t delete mode 100644 doc/supplements/m68k/cputable.t delete mode 100644 doc/supplements/m68k/fatalerr.t delete mode 100644 doc/supplements/m68k/intr_NOTIMES.t delete mode 100644 doc/supplements/m68k/m68k.texi delete mode 100644 doc/supplements/m68k/memmodel.t delete mode 100644 doc/supplements/m68k/preface.texi delete mode 100644 doc/supplements/m68k/timeMVME136.t delete mode 100644 doc/supplements/m68k/timedata.t delete mode 100644 doc/supplements/mips/.cvsignore delete mode 100644 doc/supplements/mips/BSP_TIMES delete mode 100644 doc/supplements/mips/ChangeLog delete mode 100644 doc/supplements/mips/Makefile.am delete mode 100644 doc/supplements/mips/bsp.t delete mode 100644 doc/supplements/mips/callconv.t delete mode 100644 doc/supplements/mips/cpumodel.t delete mode 100644 doc/supplements/mips/cputable.t delete mode 100644 doc/supplements/mips/fatalerr.t delete mode 100644 doc/supplements/mips/intr_NOTIMES.t delete mode 100644 doc/supplements/mips/memmodel.t delete mode 100644 doc/supplements/mips/mips.texi delete mode 100644 doc/supplements/mips/preface.texi delete mode 100644 doc/supplements/mips/timeBSP.t delete mode 100644 doc/supplements/powerpc/.cvsignore delete mode 100644 doc/supplements/powerpc/ChangeLog delete mode 100644 doc/supplements/powerpc/DMV177_TIMES delete mode 100644 doc/supplements/powerpc/Makefile.am delete mode 100644 doc/supplements/powerpc/PSIM_TIMES delete mode 100644 doc/supplements/powerpc/bsp.t delete mode 100644 doc/supplements/powerpc/callconv.t delete mode 100644 doc/supplements/powerpc/cpumodel.t delete mode 100644 doc/supplements/powerpc/cputable.t delete mode 100644 doc/supplements/powerpc/fatalerr.t delete mode 100644 doc/supplements/powerpc/intr_NOTIMES.t delete mode 100644 doc/supplements/powerpc/memmodel.t delete mode 100644 doc/supplements/powerpc/powerpc.texi delete mode 100644 doc/supplements/powerpc/preface.texi delete mode 100644 doc/supplements/powerpc/timeDMV177.t delete mode 100644 doc/supplements/powerpc/timePSIM.t delete mode 100644 doc/supplements/sh/.cvsignore delete mode 100644 doc/supplements/sh/BSP_TIMES delete mode 100644 doc/supplements/sh/ChangeLog delete mode 100644 doc/supplements/sh/Makefile.am delete mode 100644 doc/supplements/sh/bsp.t delete mode 100644 doc/supplements/sh/callconv.t delete mode 100644 doc/supplements/sh/cpumodel.t delete mode 100644 doc/supplements/sh/cputable.t delete mode 100644 doc/supplements/sh/fatalerr.t delete mode 100644 doc/supplements/sh/intr_NOTIMES.t delete mode 100644 doc/supplements/sh/memmodel.t delete mode 100644 doc/supplements/sh/preface.texi delete mode 100644 doc/supplements/sh/sh.texi delete mode 100644 doc/supplements/sh/timeBSP.t delete mode 100644 doc/supplements/sparc/.cvsignore delete mode 100644 doc/supplements/sparc/ChangeLog delete mode 100644 doc/supplements/sparc/ERC32_TIMES delete mode 100644 doc/supplements/sparc/Makefile.am delete mode 100644 doc/supplements/sparc/bsp.t delete mode 100644 doc/supplements/sparc/callconv.t delete mode 100644 doc/supplements/sparc/cpumodel.t delete mode 100644 doc/supplements/sparc/cputable.t delete mode 100644 doc/supplements/sparc/fatalerr.t delete mode 100644 doc/supplements/sparc/intr_NOTIMES.t delete mode 100644 doc/supplements/sparc/memmodel.t delete mode 100644 doc/supplements/sparc/preface.texi delete mode 100644 doc/supplements/sparc/sparc.texi delete mode 100644 doc/supplements/sparc/timeERC32.t delete mode 100644 doc/supplements/supplement.am delete mode 100644 doc/supplements/template/.cvsignore delete mode 100644 doc/supplements/template/BSP_TIMES delete mode 100644 doc/supplements/template/ChangeLog delete mode 100644 doc/supplements/template/Makefile.am delete mode 100644 doc/supplements/template/bsp.t delete mode 100644 doc/supplements/template/callconv.t delete mode 100644 doc/supplements/template/cpumodel.t delete mode 100644 doc/supplements/template/cputable.t delete mode 100644 doc/supplements/template/fatalerr.t delete mode 100644 doc/supplements/template/intr_NOTIMES.t delete mode 100644 doc/supplements/template/memmodel.t delete mode 100644 doc/supplements/template/preface.texi delete mode 100644 doc/supplements/template/template.texi delete mode 100644 doc/supplements/template/timeBSP.t diff --git a/doc/ChangeLog b/doc/ChangeLog index 08bc850ad5..df17b1c2d2 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,81 @@ +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. + 2006-01-20 Ralf Corsepius * user/rtemsarc.gif, user/states.gif, user/rtemspie.gif: diff --git a/doc/FAQ/stamp-vti b/doc/FAQ/stamp-vti index 576aa38173..e9b27c6743 100644 --- a/doc/FAQ/stamp-vti +++ b/doc/FAQ/stamp-vti @@ -1,4 +1,4 @@ @set UPDATED 5 March 2004 @set UPDATED-MONTH March 2004 -@set EDITION 4.6.99.2 -@set VERSION 4.6.99.2 +@set EDITION 4.6.99.3 +@set VERSION 4.6.99.3 diff --git a/doc/FAQ/version.texi b/doc/FAQ/version.texi index 576aa38173..e9b27c6743 100644 --- a/doc/FAQ/version.texi +++ b/doc/FAQ/version.texi @@ -1,4 +1,4 @@ @set UPDATED 5 March 2004 @set UPDATED-MONTH March 2004 -@set EDITION 4.6.99.2 -@set VERSION 4.6.99.2 +@set EDITION 4.6.99.3 +@set VERSION 4.6.99.3 diff --git a/doc/Makefile.am b/doc/Makefile.am index 237b956b19..412a1e976a 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -9,7 +9,7 @@ ACLOCAL_AMFLAGS = -I ../aclocal SUBDIRS = tools FAQ started user bsp_howto porting develenv posix_users \ posix1003.1 filesystem itron3.0 networking ada_user started_ada \ - rtems_gdb rgdb_specs new_chapters relnotes supplements gnu_docs + rtems_gdb rgdb_specs new_chapters relnotes cpu_supplement gnu_docs if USE_HTML html_DATA = index.html HELP.html diff --git a/doc/common/cpright.texi b/doc/common/cpright.texi index 8a93b9eefe..1d1be2f8bf 100644 --- a/doc/common/cpright.texi +++ b/doc/common/cpright.texi @@ -1,5 +1,5 @@ @c -@c COPYRIGHT (c) 1988-2002. +@c COPYRIGHT (c) 1988-2006. @c On-Line Applications Research Corporation (OAR). @c All rights reserved. @c @@ -17,7 +17,7 @@ @end tex @vskip 0pt plus 1filll -COPYRIGHT @copyright{} 1988 - 2003.@* +COPYRIGHT @copyright{} 1988 - 2006.@* On-Line Applications Research Corporation (OAR).@* The authors have used their best efforts in preparing diff --git a/doc/configure.ac b/doc/configure.ac index 4c6a67c9aa..e875e31a13 100644 --- a/doc/configure.ac +++ b/doc/configure.ac @@ -214,16 +214,7 @@ rtems_gdb/Makefile rgdb_specs/Makefile relnotes/Makefile new_chapters/Makefile -supplements/Makefile -supplements/arm/Makefile -supplements/c4x/Makefile -supplements/i386/Makefile -supplements/m68k/Makefile -supplements/mips/Makefile -supplements/powerpc/Makefile -supplements/sh/Makefile -supplements/sparc/Makefile -supplements/template/Makefile +cpu_supplement/Makefile gnu_docs/Makefile ]) AC_OUTPUT diff --git a/doc/cpu_supplement/.cvsignore b/doc/cpu_supplement/.cvsignore new file mode 100644 index 0000000000..19d01d9c94 --- /dev/null +++ b/doc/cpu_supplement/.cvsignore @@ -0,0 +1,28 @@ +cpu_supplement +cpu_supplement-? +cpu_supplement-?? +cpu_supplement.aux +cpu_supplement.cp +cpu_supplement.cps +cpu_supplement.dvi +cpu_supplement.fn +cpu_supplement.fns +cpu_supplement*.html +cpu_supplement.ky +cpu_supplement.log +cpu_supplement.pdf +cpu_supplement.pg +cpu_supplement.ps +cpu_supplement.toc +cpu_supplement.tp +cpu_supplement.vr +index.html +Makefile +Makefile.in +mdate-sh +rtems_footer.html +rtems_header.html +rtemspie.pdf +stamp-vti +states.pdf +version.texi diff --git a/doc/cpu_supplement/Makefile.am b/doc/cpu_supplement/Makefile.am new file mode 100644 index 0000000000..02d5be27af --- /dev/null +++ b/doc/cpu_supplement/Makefile.am @@ -0,0 +1,81 @@ +# +# COPYRIGHT (c) 1988-2002. +# On-Line Applications Research Corporation (OAR). +# All rights reserved. +# +# $Id$ +# + +PROJECT = cpu_supplement +EDITION = 1 + +include $(top_srcdir)/project.am + +REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2 + +html_projectdir = $(htmldir)/$(PROJECT) + +TEXI2WWW_ARGS=\ +-I $(srcdir) -I $(top_srcdir) -I $(top_builddir) \ +-dirfile ../index.html \ +-header rtems_header.html \ +-footer rtems_footer.html \ +-icons ../images +GENERATED_FILES = arm.texi i386.texi m68k.texi mips.texi powerpc.texi \ + sh.texi sparc.texi tic4x.texi + +COMMON_FILES += $(top_srcdir)/common/cpright.texi + +FILES = preface.texi + +info_TEXINFOS = cpu_supplement.texi +cpu_supplement_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) + +# +# Chapters which get automatic processing +# + +arm.texi: arm.t + $(BMENU2) -p "Preface" \ + -u "Top" \ + -n "" < $< > $@ + +i386.texi: i386.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +m68k.texi: m68k.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +mips.texi: mips.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +powerpc.texi: powerpc.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +sh.texi: sh.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +sparc.texi: sparc.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +tic4x.texi: tic4x.t + $(BMENU2) -p "" \ + -u "Top" \ + -n "" < $< > $@ + +CLEANFILES += cpu_supplement.info +CLEANFILES += cpu_supplement.info-1 +CLEANFILES += cpu_supplement.info-2 + diff --git a/doc/cpu_supplement/arm.t b/doc/cpu_supplement/arm.t new file mode 100644 index 0000000000..91e9f23286 --- /dev/null +++ b/doc/cpu_supplement/arm.t @@ -0,0 +1,595 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter ARM Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the ARM architecture dependencies +in this port of RTEMS. The ARM family has a wide variety +of implementations by a wide range of vendors. Consequently, +there are 100's of CPU models within it. + +It is highly recommended that the ARM +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the ARM architecture as a whole. + +@subheading Architecture Documents + +For information on the ARM architecture, +refer to the following documents available from Arm, Limited +(@file{http//www.arm.com/}). There does not appear to +be an electronic version of a manual on the architecture +in general on that site. The following book is a good +resource: + +@itemize @bullet +@item @cite{David Seal. "ARM Architecture Reference Manual." +Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.} + +@end itemize + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +ARM, SPARC, and PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across ARM implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro @code{CPU_MODEL_NAME} is a string which designates +the architectural level of this CPU model. The following is +a list of the settings for this string based upon @code{gcc} +CPU model predefines: + +@example +__ARM_ARCH4__ "ARMv4" +__ARM_ARCH4T__ "ARMv4T" +__ARM_ARCH5__ "ARMv5" +__ARM_ARCH5T__ "ARMv5T" +__ARM_ARCH5E__ "ARMv5E" +__ARM_ARCH5TE__ "ARMv5TE" +@end example + +@subsection Count Leading Zeroes Instruction + +The ARMv5 and later has the count leading zeroes (@code{clz}) +instruction which could be used to speed up the find first bit +operation. The use of this instruction should significantly speed up +the scheduling associated with a thread blocking. + +@subsection Floating Point Unit + +The macro ARM_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Processor Background + +The ARM architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch and link (@code{bl}) instruction. This instruction +saves the return address in the @code{lr} register. Returning +from a subroutine only requires that the return address be +moved into the program counter (@code{pc}), possibly with +an offset. It is is important to +note that the @code{bl} instruction 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. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using the @code{bl} +instruction and return to the user application via the +mechanism described above. + +@subsection Register Usage + +As discussed above, the ARM's call and return mechanism dos +not automatically save any registers. RTEMS uses the registers +@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and +per ARM calling convention, the @code{lr} register is altered +as well. These registers are not preserved by RTEMS directives +therefore, the contents of these registers should not be assumed +upon return from any RTEMS directive. + +@subsection Parameter Passing + +RTEMS assumes that ARM calling conventions are followed and that +the first four arguments are placed in registers @code{r0} through +@code{r3}. If there are more arguments, than that, then they +are place on the stack. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +Members of the ARM family newer than Version 3 support 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 the endian +mode that the processor is configured for. In general, ARM +processors are used in little endian mode. + +Some of the ARM family members such as the +920 and 720 include an MMU and thus support virtual memory and +segmentation. RTEMS does not support virtual memory or +segmentation on any of the ARM family members. + +@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 + +@section Interrupt Processing + + +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 ARM's +interrupt response and control mechanisms as they pertain to +RTEMS. + +The ARM has 7 exception types: +@itemize @bullet + +@item Reset +@item Undefined instruction +@item Software interrupt (SWI) +@item Prefetch Abort +@item Data Abort +@item Interrupt (IRQ) +@item Fast Interrupt (FIQ) + +@end itemize + +Of these types, only IRQ and FIQ are handled through RTEMS's interrupt +vectoring. + +@subsection Vectoring of an Interrupt Handler + + +Unlike many other architectures, the ARM has seperate stacks for each +interrupt. When the CPU receives an interrupt, it: + +@itemize @bullet +@item switches to the exception mode corresponding to the interrupt, + +@item saves the Current Processor Status Register (CPSR) to the +exception mode's Saved Processor Status Register (SPSR), + +@item masks off the IRQ and if the interrupt source was FIQ, the FIQ +is masked off as well, + +@item saves the Program Counter (PC) to the exception mode's Link +Register (LR - same as R14), + +@item and sets the PC to the exception's vector address. + +@end itemize + +The vectors for both IRQ and FIQ point to the _ISR_Handler function. +_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before +calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so +that it is safe to call C functions. Even ExecuteITHandler() can be written +in C. + +@subsection Interrupt Levels + +The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ +has a higher priority than IRQ, and has its own version of register R8 - R14, +however RTEMS does not take advantage of them. Both interrupts are enabled +through the CPSR. + +The RTEMS interrupt level mapping scheme for the AEM is not a numeric level +as on most RTEMS ports. It is a bit mapping that corresponds the enable +bits's postions in the CPSR: + +@table @b +@item FIQ +Setting bit 6 (0 is least significant bit) disables the FIQ. + +@item IRQ +Setting bit 7 (0 is least significant bit) disables the IRQ. + +@end table + + +@subsection 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 processor 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. + +@subsection Interrupt Stack + +RTEMS expects the interrupt stacks to be set up in bsp_start(). The memory +for the stacks is reserved in the linker script. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler performs the +following actions: + +@itemize @bullet +@item disables processor interrupts, +@item places the error code in @b{r0}, and +@item executes an infinite loop (@code{while(0);} to +simulate a halt processor instruction. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +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 XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure 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 XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item 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. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table diff --git a/doc/cpu_supplement/i386.t b/doc/cpu_supplement/i386.t new file mode 100644 index 0000000000..1b153dd240 --- /dev/null +++ b/doc/cpu_supplement/i386.t @@ -0,0 +1,694 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter Intel/AMD x86 Specific Information + +The Real Time Executive for Multiprocessor Systems +(RTEMS) is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +For information on the i386 processor, refer to the +following documents: + +@itemize @bullet +@item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}. + +@item @cite{386 Microprocessor Hardware Reference Manual, Intel, +Order No. 231732-003}. + +@item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}. + +@item @cite{80387 Programmer's Reference Manual, Intel, Order No. 231917-001}. +@end itemize + +It is highly recommended that the i386 RTEMS +application developer obtain and become familiar with Intel's +386 Programmer's Reference Manual. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across i386 implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/i386/i386.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the Intel i386 without an +i387 coprocessor, this macro is set to the string "i386 with i387". + +@subsection bswap Instruction + +The macro I386_HAS_BSWAP is set to 1 to indicate that +this CPU model has the @code{bswap} instruction which +endian swaps a thirty-two bit quantity. This instruction +appears to be present in all CPU models +i486's and above. + +@subsection Floating Point Unit + +The macro I386_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. The hardware floating point may be on-chip (as in the +case of an i486DX or Pentium) or as a coprocessor (as in the case of +an i386/i387 combination). +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Processor Background + +The i386 architecture supports a simple yet effective +call and return mechanism. A subroutine is invoked via the call +(call) instruction. This instruction pushes the return address +on the stack. The return from subroutine (ret) instruction pops +the return address off the current stack and transfers control +to that instruction. It is is important to note that the i386 +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. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using a call +instruction and return to the user application via the ret +instruction. + +@subsection Register Usage + +As discussed above, the call instruction does not +automatically save any registers. RTEMS uses the registers EAX, +ECX, and EDX 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 +directive. + +@subsection Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the call +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: + +@example +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a push instruction. 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 stack pointer. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +RTEMS supports the i386 protected mode, flat memory +model with paging disabled. In this mode, the i386 +automatically converts every address from a logical to a +physical address each time it is used. The i386 uses +information provided in the segment registers and the Global +Descriptor Table to convert these addresses. RTEMS assumes the +existence of the following segments: + +@itemize @bullet +@item a single code segment at protection level (0) which +contains all application and executive code. + +@item a single data segment at protection level zero (0) which +contains all application and executive data. +@end itemize + +The i386 segment registers and associated selectors +must be initialized when the initialize_executive directive is +invoked. RTEMS treats the segment registers as system registers +and does not modify or context switch them. + +This i386 memory model 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, half-word (2-bytes), or word (4 bytes). + +RTEMS does not require that logical addresses map +directly to physical addresses, although it is desirable in many +applications to do so. If logical and physical addresses are +not the same, then an additional selector will be required so +RTEMS can access the Interrupt Descriptor Table to install +interrupt service routines. The selector number of this segment +is provided to RTEMS in the CPU Dependent Information Table. + +By not requiring that logical addresses map directly +to physical addresses, the memory space of an RTEMS application +can be separated from that of a ROM monitor. For example, on +the Force Computers CPU386, the ROM monitor loads application +programs into a logical address space where logical address +0x00000000 corresponds to physical address 0x0002000. On this +board, RTEMS and the application use virtual addresses which do +not map to physical addresses. + +RTEMS assumes that the DS and ES registers contain +the selector for the single data segment when a directive is +invoked. This assumption is especially important when +developing interrupt service routines. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + + +Different types of processors respond to the +occurrence of an interrupt in their own unique fashion. In +addition, each processor type provides a control mechanism to +allow the proper handling of an interrupt. The processor +dependent response to the interrupt modifies the execution state +and results in the modification of the execution stream. This +modification usually requires that an interrupt handler utilize +the provided 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 the processor's response and control mechanisms as they +pertain to RTEMS. + +@subsection Vectoring of Interrupt Handler + +Although the i386 supports multiple privilege levels, +RTEMS and all user software executes at privilege level 0. This +decision was made by the RTEMS designers to enhance +compatibility with processors which do not provide sophisticated +protection facilities like those of the i386. This decision +greatly simplifies the discussion of i386 processing, as one +need only consider interrupts without privilege transitions. + +Upon receipt of an interrupt the i386 automatically +performs the following actions: + +@itemize @bullet +@item pushes the EFLAGS register + +@item pushes the far address of the interrupted instruction + +@item vectors to the interrupt service routine (ISR). +@end itemize + +A nested interrupt is processed similarly by the +i386. + +@subsection Interrupt Stack Frame + +The structure of the Interrupt Stack Frame for the +i386 which is placed on the interrupt stack by the processor in +response to an interrupt is as follows: + +@ifset use-ascii +@example +@group + +----------------------+ + | Old EFLAGS Register | ESP+8 + +----------+-----------+ + | UNUSED | Old CS | ESP+4 + +----------+-----------+ + | Old EIP | ESP + +----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\strut\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.00in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 0.75in{\enskip\hfil#\hfil} +\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr +\multispan{4}\hrulefill\cr +&UNUSED &&Old CS &&ESP+4\cr +\multispan{4}\hrulefill\cr +& \multispan{3} Old EIP && ESP\cr +\multispan{4}\hrulefill\cr +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + +
Old EFLAGS Register0x0
UNUSEDOld CS0x2
Old EIP0x4
+
+@end html +@end ifset + +@subsection Interrupt Levels + +Although RTEMS supports 256 interrupt levels, the +i386 only supports two -- enabled and disabled. Interrupts are +enabled when the interrupt-enable flag (IF) in the extended +flags (EFLAGS) is set. Conversely, interrupt processing is +inhibited when the IF is cleared. During a non-maskable +interrupt, all other interrupts, including other non-maskable +ones, are inhibited. + +RTEMS interrupt levels 0 and 1 such that level zero +(0) indicates that interrupts are fully enabled and level one +that interrupts are disabled. All other RTEMS interrupt levels +are undefined and their behavior is unpredictable. + +@subsection 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 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 i386 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 within RTEMS was last calculated 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. + +@subsection Interrupt Stack + +The i386 family does not support a dedicated hardware +interrupt stack. On this processor, RTEMS allocates and manages +a dedicated interrupt stack. As part of vectoring a non-nested +interrupt service routine, RTEMS switches from the stack of the +interrupted task to a dedicated interrupt stack. When a +non-nested interrupt returns, RTEMS switches back to the stack +of the interrupted stack. The current stack pointer is not +altered by RTEMS on nested interrupt. + +Without a dedicated interrupt stack, every task in +the system MUST have enough stack space to accommodate the worst +case stack usage of that particular task and the interrupt +service routines COMBINED. By supporting a dedicated interrupt +stack, RTEMS significantly lowers the stack requirements for +each task. + +RTEMS allocates the dedicated 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. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts, +places the error code in EAX, and executes a HLT instruction to +halt the processor. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed to support a +particular processor and target board combination. This chapter presents a +discussion of i386 specific BSP issues. For more information on developing +a BSP, refer to the chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated when the i386 +processor is reset. When the i386 is reset, + +@itemize @bullet + +@item The EAX register is set to indicate the results of the processor's +power-up self test. If the self-test was not executed, the contents of +this register are undefined. Otherwise, a non-zero value indicates the +processor is faulty and a zero value indicates a successful self-test. + +@item The DX register holds a component identifier and revision level. DH +contains 3 to indicate an i386 component and DL contains a unique revision +level indicator. + +@item Control register zero (CR0) is set such that the processor is in real +mode with paging disabled. Other portions of CR0 are used to indicate the +presence of a numeric coprocessor. + +@item All bits in the extended flags register (EFLAG) which are not +permanently set are cleared. This inhibits all maskable interrupts. + +@item The Interrupt Descriptor Register (IDTR) is set to point at address +zero. + +@item All segment registers are set to zero. + +@item The instruction pointer is set to 0x0000FFF0. The first instruction +executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts +the upper twelve address until the first intersegment (FAR) JMP or CALL +instruction. When a JMP or CALL is executed, the upper twelve address +lines are lowered and the processor begins executing in the first megabyte +of memory. + +@end itemize + +Typically, an intersegment JMP to the application's initialization code is +placed at address 0xFFFFFFF0. + +@subsection Processor Initialization + +This initialization code is responsible for initializing all data +structures required by the i386 in protected mode and for actually entering +protected mode. The i386 must be placed in protected mode and the segment +registers and associated selectors must be initialized before the +initialize_executive directive is invoked. + +The initialization code is responsible for initializing the Global +Descriptor Table such that the i386 is in the thirty-two bit flat memory +model with paging disabled. In this mode, the i386 automatically converts +every address from a logical to a physical address each time it is used. +For more information on the memory model used by RTEMS, please refer to the +Memory Model chapter in this document. + +Since the processor is in real mode upon reset, the processor must be +switched to protected mode before RTEMS can execute. Before switching to +protected mode, at least one descriptor table and two descriptors must be +created. Descriptors are needed for a code segment and a data segment. ( +This will give you the flat memory model.) The stack can be placed in a +normal read/write data segment, so no descriptor for the stack is needed. +Before the GDT can be used, the base address and limit must be loaded into +the GDTR register using an LGDT instruction. + +If the hardware allows an NMI to be generated, you need to create the IDT +and a gate for the NMI interrupt handler. Before the IDT can be used, the +base address and limit for the idt must be loaded into the IDTR register +using an LIDT instruction. + +Protected mode is entered by setting thye PE bit in the CR0 register. +Either a LMSW or MOV CR0 instruction may be used to set this bit. Because +the processor overlaps the interpretation of several instructions, it is +necessary to discard the instructions from the read-ahead cache. A JMP +instruction immediately after the LMSW changes the flow and empties the +processor if intructions which have been pre-fetched and/or decoded. At +this point, the processor is in protected mode and begins to perform +protected mode application initialization. + +If the application requires that the IDTR be some value besides zero, then +it should set it to the required value at this point. All tasks share the +same i386 IDTR value. Because interrupts are enabled automatically by +RTEMS as part of the initialize_executive directive, the IDTR MUST be set +properly before this directive is invoked to insure correct interrupt +vectoring. If processor caching is to be utilized, then it should be +enabled during the reset application initialization code. The reset code +which is executed before the call to initialize_executive has the following +requirements: + +For more information regarding the i386s data structures and their +contents, refer to Intel's 386 Programmer's Reference Manual. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The i386 version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the i386. This information +is provided to allow RTEMS to interoperate effectively with the +BSP. The C structure definition is given here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + unsigned32 interrupt_segment; + void *interrupt_vector_table; +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_segment +is the value of the selector which should be placed in a segment +register to access the Interrupt Descriptor Table. + +@item interrupt_vector_table +is the base address of the Interrupt Descriptor Table relative to the +interrupt_segment. + +@end table + +The contents of the i386 Interrupt Descriptor Table +are discussed in Intel's i386 User's Manual. Structure +definitions for the i386 IDT is provided by including the file +rtems.h. + diff --git a/doc/cpu_supplement/m68k.t b/doc/cpu_supplement/m68k.t new file mode 100644 index 0000000000..d684328277 --- /dev/null +++ b/doc/cpu_supplement/m68k.t @@ -0,0 +1,773 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter Motorola M68xxx and Coldfire Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the Motorola MC68xxx +architecture dependencies in this port of RTEMS. The MC68xxx +family has a wide variety of CPU models within it. 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. + +It is highly recommended that the Motorola MC68xxx +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the family as a whole. + +@subheading Architecture Documents + +For information on the Motorola MC68xxx architecture, +refer to the following documents available from Motorola +(@file{http//www.moto.com/}): + +@itemize @bullet +@item @cite{M68000 Family Reference, Motorola, FR68K/D}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}. + +@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's +Manual, Motorola, MC68881UM/AD}. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/m68k/m68k.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the MC68020 +processor, this macro is set to the string "mc68020". + +@subsection Floating Point Unit + +The macro M68K_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@subsection BFFFO Instruction + +The macro M68K_HAS_BFFFO is set to 1 to indicate that +this CPU model has the bfffo instruction. + +@subsection Vector Base Register + +The macro M68K_HAS_VBR is set to 1 to indicate that +this CPU model has a vector base register (vbr). + +@subsection Separate Stacks + +The macro M68K_HAS_SEPARATE_STACKS is set to 1 to +indicate that this CPU model has separate interrupt, user, and +supervisor mode stacks. + +@subsection 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. + +@subsection 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. +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Processor Background + +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. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using either a bsr +or jsr instruction and return to the user application via the +rts instruction. + +@subsection Register Usage + +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 +directive. + +@subsection Parameter Passing + +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: + +@example +@group +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end group +@end example + +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. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +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 this family. + +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 family members. + +@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 + +@section Interrupt Processing + + +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. + +@subsection 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. + +@subsubsection 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 + +@subsubsection 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 + +@subsection 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 :-) + + +@subsection 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. + +@subsection 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. + +@subsection 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. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 7, places the error code in D0, and executes a stop +instruction to simulate a halt processor instruction. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of MC68020 specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the MC68020 processor is reset. When the +MC68020 is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +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 initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure 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 +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the MC68020 remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +MC68020 from the interrupt state. + +@item 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. + +@item Must initialize the MC68020's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The MC68xxx version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the MC68xxx. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + m68k_isr *interrupt_vector_table; +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item interrupt_vector_table +is the base address of the CPU's Exception Vector Table. + +@end table diff --git a/doc/cpu_supplement/mips.t b/doc/cpu_supplement/mips.t new file mode 100644 index 0000000000..2fae46ecc2 --- /dev/null +++ b/doc/cpu_supplement/mips.t @@ -0,0 +1,677 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter MIPS Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the VENDOR XXX +architecture dependencies in this port of RTEMS. The XXX +family has a wide variety of CPU models within it. The part +numbers ... + +XXX fill in some things here + +It is highly recommended that the XXX +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the family as a whole. + +@subheading Architecture Documents + +IDT docs are online at http://www.idt.com/products/risc/Welcome.html + +For information on the XXX architecture, +refer to the following documents available from VENDOR +(@file{http//www.XXX.com/}): + +@itemize @bullet +@item @cite{XXX Family Reference, VENDOR, PART NUMBER}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. +@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/XXX/XXX.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the MODEL +processor, this macro is set to the string "XXX". + +@subsection Floating Point Unit + +The macro XXX_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@subsection Another Optional Feature + +The macro XXX +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Processor Background + +The MC68xxx architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch to subroutine (@code{XXX}) or the jump to subroutine +(@code{XXX}) instructions. These instructions push the return address +on the current stack. The return from subroutine (@code{XXX}) +instruction pops the return address off the current stack and +transfers control to that instruction. It is is important to +note that the XXX 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. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using either a @code{XXX} +or @code{XXX} instruction and return to the user application via the +@code{XXX} instruction. + +@subsection Register Usage + +As discussed above, the @code{XXX} and @code{XXX} instructions do +not automatically save any registers. RTEMS uses the registers +@b{D0}, @b{D1}, @b{A0}, and @b{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 +directive. + +@subsection Parameter Passing + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the @code{XXX} or @code{XXX} +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: + +@example +@group +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end group +@end example + +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. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +The XXX 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 this family. + +Some of the XXX family members such as the +XXX, XXX, and XXX support virtual memory and +segmentation. The XXX requires external hardware support +such as the XXX 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 XXX family members. + +@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 + +@section Interrupt Processing + + +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 XXX's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@subsection Vectoring of an Interrupt Handler + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the XXX family has two +different interrupt handling models. + +@subsubsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@subsubsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX 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 +XXX 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 + +@subsection Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by XXX 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 +XXX family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to XXX interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@subsection 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 processor 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. + +@subsection 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 mips port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler disables processor interrupts, +places the error code in @b{XXX}, and executes a @code{XXX} +instruction to simulate a halt processor instruction. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +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 XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure 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 XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item 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. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table diff --git a/doc/cpu_supplement/powerpc.t b/doc/cpu_supplement/powerpc.t new file mode 100644 index 0000000000..98828c4eed --- /dev/null +++ b/doc/cpu_supplement/powerpc.t @@ -0,0 +1,1043 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter PowerPC Specific Information + +The Real Time Executive for Multiprocessor Systems +(RTEMS) is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the PowerPC architecture +dependencies in this port of RTEMS. + +It is highly recommended that the PowerPC RTEMS +application developer obtain and become familiar with the +documentation for the processor being used as well as the +specification for the revision of the PowerPC architecture which +corresponds to that processor. + +@subheading PowerPC Architecture Documents + +For information on the PowerPC architecture, refer to +the following documents available from Motorola and IBM: + +@itemize @bullet + +@item @cite{PowerPC Microprocessor Family: The Programming Environment} +(Motorola Document MPRPPCFPE-01). + +@item @cite{IBM PPC403GB Embedded Controller User's Manual}. + +@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing +Unit Reference Manual} (Motorola Document RCPUURM/AD). + +@item @cite{PowerPC 601 RISC Microprocessor User's Manual} +(Motorola Document MPR601UM/AD). + +@item @cite{PowerPC 603 RISC Microprocessor User's Manual} +(Motorola Document MPR603UM/AD). + +@item @cite{PowerPC 603e RISC Microprocessor User's Manual} +(Motorola Document MPR603EUM/AD). + +@item @cite{PowerPC 604 RISC Microprocessor User's Manual} +(Motorola Document MPR604UM/AD). + +@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual} +(Motorola Document MPC821UM/AD). + +@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD). + + +@end itemize + +Motorola maintains an on-line electronic library for the PowerPC +at the following URL: + +@itemize @code{ } +@item @cite{http://www.mot.com/powerpc/library/library.html} +@end itemize + +This site has a a wealth of information and examples. Many of the +manuals are available from that site in electronic format. + +@subheading PowerPC Processor Simulator Information + +PSIM is a program which emulates the Instruction Set Architecture +of the PowerPC microprocessor family. It is reely available in source +code form under the terms of the GNU General Public License (version +2 or later). PSIM can be integrated with the GNU Debugger (gdb) to +execute and debug PowerPC executables on non-PowerPC hosts. PSIM +supports the addition of user provided device models which can be +used to allow one to develop and debug embedded applications using +the simulator. + +The latest version of PSIM is made available to the public via +anonymous ftp at ftp://ftp.ci.com.au/pub/psim or +ftp://cambridge.cygnus.com/pub/psim. There is also a mailing list +at powerpc-psim@@ci.com.au. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC, and PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. + +@subsection CPU Model Feature Flags + +Each processor family supported by RTEMS has a +list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This section presents the set of features which vary +across PowerPC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/ppc/ppc.h based upon the particular CPU +model defined on the compilation command line. + +@subsubsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the PowerPC 603e +model, this macro is set to the string "PowerPC 603e". + +@subsubsection Floating Point Unit + +The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model +has a hardware floating point unit and 0 otherwise. + +@subsubsection Alignment + +The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment +requirement for data types on a byte boundary. This value is used +to derive the alignment restrictions for memory allocated from +regions and partitions. + +@subsubsection Cache Alignment + +The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is +used to align the entry point of critical routines so that as much code +as possible can be retrieved with the initial read into cache. This +is done for the interrupt handler as well as the context switch routines. + +In addition, the "shortcut" data structure used by the PowerPC implementation +to ease access to data elements frequently accessed by RTEMS routines +implemented in assembly language is aligned using this value. + +@subsubsection Maximum Interrupts + +The macro PPC_INTERRUPT_MAX is set to the number of exception sources +supported by this PowerPC model. + +@subsubsection Has Double Precision Floating Point + +The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model +has support for double precision floating point numbers. This is +important because the floating point registers need only be four bytes +wide (not eight) if double precision is not supported. + +@subsubsection Critical Interrupts + +The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model +has the Critical Interrupt capability as defined by the IBM 403 models. + +@subsubsection Use Multiword Load/Store Instructions + +The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and +store instructions should be used to perform context switch operations. +The relative efficiency of multiword load and store instructions versus +an equivalent set of single word load and store instructions varies based +upon the PowerPC model. + +@subsubsection Instruction Cache Size + +The macro PPC_I_CACHE is set to the size in bytes of the instruction cache. + +@subsubsection Data Cache Size + +The macro PPC_D_CACHE is set to the size in bytes of the data cache. + +@subsubsection Debug Model + +The macro PPC_DEBUG_MODEL is set to indicate the debug support features +present in this CPU model. The following debug support feature sets +are currently supported: + +@table @b + +@item @code{PPC_DEBUG_MODEL_STANDARD} +indicates that the single-step trace enable (SE) and branch trace +enable (BE) bits in the MSR are supported by this CPU model. + +@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY} +indicates that only the single-step trace enable (SE) bit in the MSR +is supported by this CPU model. + +@item @code{PPC_DEBUG_MODEL_IBM4xx} +indicates that the debug exception enable (DE) bit in the MSR is supported +by this CPU model. At this time, this particular debug feature set +has only been seen in the IBM 4xx series. + +@end table + +@subsubsection Low Power Model + +The macro PPC_LOW_POWER_MODE is set to indicate the low power model +supported by this CPU model. The following low power modes are currently +supported. + +@table @b + +@item @code{PPC_LOW_POWER_MODE_NONE} +indicates that this CPU model has no low power mode support. + +@item @code{PPC_LOW_POWER_MODE_STANDARD} +indicates that this CPU model follows the low power model defined for +the PPC603e. + +@end table +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +RTEMS supports the Embedded Application Binary Interface (EABI) +calling convention. Documentation for EABI is available by sending +a message with a subject line of "EABI" to eabi@@goth.sis.mot.com. + +@subsection Programming Model + +This section discusses the programming model for the +PowerPC architecture. + +@subsubsection Non-Floating Point Registers + +The PowerPC architecture defines thirty-two non-floating point registers +directly visible to the programmer. In thirty-two bit implementations, each +register is thirty-two bits wide. In sixty-four bit implementations, each +register is sixty-four bits wide. + +These registers are referred to as @code{gpr0} to @code{gpr31}. + +Some of the registers serve defined roles in the EABI programming model. +The following table describes the role of each of these registers: + +@ifset use-ascii +@example +@group + +---------------+----------------+------------------------------+ + | Register Name | Alternate Name | Description | + +---------------+----------------+------------------------------+ + | r1 | sp | stack pointer | + +---------------+----------------+------------------------------+ + | | | global pointer to the Small | + | r2 | na | Constant Area (SDA2) | + +---------------+----------------+------------------------------+ + | r3 - r12 | na | parameter and result passing | + +---------------+----------------+------------------------------+ + | | | global pointer to the Small | + | r13 | na | Data Area (SDA) | + +---------------+----------------+------------------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 2.50in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} +&r1&&sp&&stack pointer&\cr\noalign{\hrule} +&r2&&NA&&global pointer to the Small&\cr +&&&&&Constant Area (SDA2)&\cr\noalign{\hrule} +&r3 - r12&&NA&¶meter and result passing&\cr\noalign{\hrule} +&r13&&NA&&global pointer to the Small&\cr +&&&&&Data Area (SDA2)&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + + + + +
Register NameAlternate NameDescription
r1spstack pointer
r2naglobal pointer to the Small Constant Area (SDA2)
r3 - r12NAparameter and result passing
r13NAglobal pointer to the Small Data Area (SDA)
+
+@end html +@end ifset + + +@subsubsection Floating Point Registers + +The PowerPC architecture includes thirty-two, sixty-four bit +floating point registers. All PowerPC floating point instructions +interpret these registers as 32 double precision floating point registers, +regardless of whether the processor has 64-bit or 32-bit implementation. + +The floating point status and control register (fpscr) records exceptions +and the type of result generated by floating-point operations. +Additionally, it controls the rounding mode of operations and allows the +reporting of floating exceptions to be enabled or disabled. + +@subsubsection Special Registers + +The PowerPC architecture includes a number of special registers +which are critical to the programming model: + +@table @b + +@item Machine State Register + +The MSR contains the processor mode, power management mode, endian mode, +exception information, privilege level, floating point available and +floating point excepiton mode, address translation information and +the exception prefix. + +@item Link Register + +The LR contains the return address after a function call. This register +must be saved before a subsequent subroutine call can be made. The +use of this register is discussed further in the @b{Call and Return +Mechanism} section below. + +@item Count Register + +The CTR contains the iteration variable for some loops. It may also be used +for indirect function calls and jumps. + +@end table + +@subsection Call and Return Mechanism + +The PowerPC architecture supports a simple yet effective call +and return mechanism. A subroutine is invoked +via the "branch and link" (@code{bl}) and +"brank and link absolute" (@code{bla}) +instructions. This instructions place the return address +in the Link Register (LR). The callee returns to the caller by +executing a "branch unconditional to the link register" (@code{blr}) +instruction. Thus the callee returns to the caller via a jump +to the return address which is stored in the LR. + +The previous contents of the LR are not automatically saved +by either the @code{bl} or @code{bla}. It is the responsibility +of the callee to save the contents of the LR before invoking +another subroutine. If the callee invokes another subroutine, +it must restore the LR before executing the @code{blr} instruction +to return to the caller. + +It is important to note that the PowerPC subroutine +call and return mechanism does not automatically save and +restore any registers. + +The LR may be accessed as special purpose register 8 (@code{SPR8}) using the +"move from special register" (@code{mfspr}) and +"move to special register" (@code{mtspr}) instructions. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using the regular +PowerPC EABI calling convention via the @code{bl} or +@code{bla} instructions. + +@subsection Register Usage + +As discussed above, the call instruction does not +automatically save any registers. It is the responsibility +of the callee to save and restore any registers which must be preserved +across subroutine calls. The callee is responsible for saving +callee-preserved registers to the program stack and restoring them +before returning to the caller. + +@subsection Parameter Passing + +RTEMS assumes that arguments are placed in the +general purpose registers with the first argument in +register 3 (@code{r3}), the second argument in general purpose +register 4 (@code{r4}), and so forth until the seventh +argument is in general purpose register 10 (@code{r10}). +If there are more than seven arguments, then subsequent arguments +are placed on the program stack. The following pseudo-code +illustrates the typical sequence used to call a RTEMS directive +with three (3) arguments: + +@example +load third argument into r5 +load second argument into r4 +load first argument into r3 +invoke directive +@end example + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these same calling conventions. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +The PowerPC architecture supports a variety of memory models. +RTEMS supports the PowerPC using a flat memory model with +paging disabled. In this mode, the PowerPC automatically +converts every address from a logical to a physical address +each time it is used. The PowerPC uses information provided +in the Block Address Translation (BAT) to convert these addresses. + +Implementations of the PowerPC architecture may be thirty-two or sixty-four bit. +The PowerPC architecture supports a flat thirty-two or sixty-four bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF +in sixty-four bit implementations. Each address is represented +by either a thirty-two bit or sixty-four bit value and is byte addressable. +The address may be used to reference a single byte, half-word +(2-bytes), word (4 bytes), or in sixty-four bit implementations a +doubleword (8 bytes). Memory accesses within the address space are +performed in big or little endian fashion by the PowerPC based +upon the current setting of the Little-endian mode enable bit (LE) +in the Machine State Register (MSR). While the processor is in +big endian mode, memory accesses which are not properly aligned +generate an "alignment exception" (vector offset 0x00600). In +little endian mode, the PowerPC architecture does not require +the processor to generate alignment exceptions. + +The following table lists the alignment requirements for a variety +of data accesses: + +@ifset use-ascii +@example +@group + +--------------+-----------------------+ + | Data Type | Alignment Requirement | + +--------------+-----------------------+ + | byte | 1 | + | half-word | 2 | + | word | 4 | + | doubleword | 8 | + +--------------+-----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} +&byte&&1&\cr\noalign{\hrule} +&half-word&&2&\cr\noalign{\hrule} +&word&&4&\cr\noalign{\hrule} +&doubleword&&8&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + +
Data TypeAlignment Requirement
byte1
half-word2
word4
doubleword8
+
+@end html +@end ifset + +Doubleword load and store operations are only available in +PowerPC CPU models which are sixty-four bit implementations. + +RTEMS does not directly support any PowerPC Memory Management +Units, therefore, virtual memory or segmentation systems +involving the PowerPC are not supported. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + + +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 PowerPC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +RTEMS and associated documentation uses the terms +interrupt and vector. In the PowerPC architecture, these terms +correspond to exception and exception handler, respectively. The terms will +be used interchangeably in this manual. + +@subsection Synchronous Versus Asynchronous Exceptions + +In the PowerPC architecture exceptions can be either precise or +imprecise and either synchronous or asynchronous. Asynchronous +exceptions occur when an external event interrupts the processor. +Synchronous exceptions are caused by the actions of an +instruction. During an exception SRR0 is used to calculate where +instruction processing should resume. All instructions prior to +the resume instruction will have completed execution. SRR1 is used to +store the machine status. + +There are two asynchronous nonmaskable, highest-priority exceptions +system reset and machine check. There are two asynchrononous maskable +low-priority exceptions external interrupt and decrementer. Nonmaskable +execptions are never delayed, therefore if two nonmaskable, asynchronous +exceptions occur in immediate succession, the state information saved by +the first exception may be overwritten when the subsequent exception occurs. + +The PowerPC arcitecure defines one imprecise exception, the imprecise +floating point enabled exception. All other synchronous exceptions are +precise. The synchronization occuring during asynchronous precise +exceptions conforms to the requirements for context synchronization. + +@subsection Vectoring of Interrupt Handler + +Upon determining that an exception can be taken the PowerPC automatically +performs the following actions: + +@itemize @bullet +@item an instruction address is loaded into SRR0 + +@item bits 33-36 and 42-47 of SRR1 are loaded with information +specific to the exception. + +@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding +bits from the MSR. + +@item the MSR is set based upon the exception type. + +@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. + +@end itemize + +If the interrupt handler was installed as an RTEMS +interrupt handler, then upon receipt of the interrupt, the +processor passes control to the RTEMS interrupt handler which +performs the following actions: + +@itemize @bullet +@item saves the state of the interrupted task on it's stack, + +@item saves all registers which are not normally preserved +by the calling sequence so the user's interrupt service +routine can be written in a high-level language. + +@item if this is the outermost (i.e. non-nested) interrupt, +then the RTEMS interrupt handler switches from the current stack +to the interrupt stack, + +@item enables exceptions, + +@item invokes the vectors to a user interrupt service routine (ISR). +@end itemize + +Asynchronous interrupts are ignored while exceptions are +disabled. Synchronous interrupts which occur while are +disabled result in the CPU being forced into an error mode. + +A nested interrupt is processed similarly with the +exception that the current stack need not be switched to the +interrupt stack. + +@subsection Interrupt Levels + +The PowerPC architecture supports only a single external +asynchronous interrupt source. This interrupt source +may be enabled and disabled via the External Interrupt Enable (EE) +bit in the Machine State Register (MSR). Thus only two level (enabled +and disabled) of external device interrupt priorities are +directly supported by the PowerPC architecture. + +Some PowerPC implementations include a Critical Interrupt capability +which is often used to receive interrupts from high priority external +devices. + +The RTEMS interrupt level mapping scheme for the PowerPC is not +a numeric level as on most RTEMS ports. It is a bit mapping in +which the least three significiant bits of the interrupt level +are mapped directly to the enabling of specific interrupt +sources as follows: + +@table @b + +@item Critical Interrupt +Setting bit 0 (the least significant bit) of the interrupt level +enables the Critical Interrupt source, if it is available on this +CPU model. + +@item Machine Check +Setting bit 1 of the interrupt level enables Machine Check execptions. + +@item External Interrupt +Setting bit 2 of the interrupt level enables External Interrupt execptions. + +@end table + +All other bits in the RTEMS task interrupt level are ignored. + +@subsection 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 Critical Interrupts, External Interrupts +and Machine Checks 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 PowerPC 603e 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.] + +If a PowerPC implementation provides non-maskable interrupts (NMI) +which cannot be disabled, ISRs which process these interrupts +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. + +@subsection Interrupt Stack + +The PowerPC architecture does not provide for a +dedicated interrupt stack. Thus by default, exception handlers would +execute on the stack of the RTEMS task which they interrupted. +This artificially inflates the stack requirements for each task +since EVERY task stack would have to include enough space to +account for the worst case interrupt stack requirements in +addition to it's own worst case usage. RTEMS addresses this +problem on the PowerPC by providing a dedicated interrupt stack +managed by software. + +During system initialization, 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. As +part of processing a non-nested interrupt, RTEMS will switch to +the interrupt stack before invoking the installed handler. + + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler performs the following actions: + +@itemize @bullet + +@item places the error code in r3, and + +@item executes a trap instruction which results in a Program Exception. + +@end itemize + +If the Program Exception returns, then the following actions are performed: + +@itemize @bullet + +@item disables all processor exceptions by loading a 0 into the MSR, and + +@item goes into an infinite loop to simulate a halt processor instruction. + +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of PowerPC specific BSP issues. +For more information on developing a BSP, refer to the chapter +titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the PowerPC processor is reset. The PowerPC +architecture defines a Reset Exception, but leaves the +details of the CPU state as implementation specific. Please +refer to the User's Manual for the CPU model in question. + +In general, at power-up the PowerPC begin execution at address +0xFFF00100 in supervisor mode with all exceptions disabled. For +soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100 +depending upon the setting of the Exception Prefix bit in the MSR. +If during a soft reset, a Machine Check Exception occurs, then the +CPU may execute a hard reset. + +@subsection Processor Initialization + +It is the responsibility of the application's +initialization code to initialize the CPU and board +to a quiescent state before invoking the @code{rtems_initialize_executive} +directive. It is recommended that the BSP utilize the @code{predriver_hook} +to install default handlers for all exceptions. These default handlers +may be overwritten as various device drivers and subsystems install +their own exception handlers. Upon completion of RTEMS executive +initialization, all interrupts are enabled. + +If this PowerPC implementation supports on-chip caching +and this is to be utilized, then it should be enabled during the +reset application initialization code. On-chip caching has been +observed to prevent some emulators from working properly, so it +may be necessary to run with caching disabled to use these emulators. + +In addition to the requirements described in the +@b{Board Support Packages} chapter of the RTEMS C +Applications User's Manual for the reset code +which is executed before the call to @code{rtems_initialize_executive}, +the PowrePC version has the following specific requirements: + +@itemize @bullet +@item Must leave the PR bit of the Machine State Register (MSR) set +to 0 so the PowerPC remains in the supervisor state. + +@item Must set stack pointer (sp or r1) such that a minimum stack +size of MINIMUM_STACK_SIZE bytes is provided for the +@code{rtems_initialize_executive} directive. + +@item Must disable all external interrupts (i.e. clear the EI (EE) +bit of the machine state register). + +@item Must enable traps so window overflow and underflow +conditions can be properly handled. + +@item Must initialize the PowerPC's initial Exception Table with default +handlers. + +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The PowerPC version of the RTEMS CPU Dependent +Information Table is given by the C structure definition is +shown below: + +@example +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + unsigned32 clicks_per_usec; /* Timer clicks per microsecond */ + void (*spurious_handler)( + unsigned32 vector, CPU_Interrupt_frame *); + boolean exceptions_in_RAM; /* TRUE if in RAM */ + +#if defined(ppc403) + unsigned32 serial_per_sec; /* Serial clocks per second */ + boolean serial_external_clock; + boolean serial_xon_xoff; + boolean serial_cts_rts; + unsigned32 serial_rate; + unsigned32 timer_average_overhead; /* in ticks */ + unsigned32 timer_least_valid; /* Least valid number from timer */ +#endif +@}; +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item clicks_per_usec +is the number of decrementer interupts that occur each microsecond. + +@item spurious_handler +is the address of the +routine which is invoked when a spurious interrupt occurs. + +@item exceptions_in_RAM +indicates whether the exception vectors are located in RAM or ROM. If +they are located in RAM dynamic vector installation occurs, otherwise +it does not. + +@item serial_per_sec +is a PPC403 specific field which specifies the number of clock +ticks per second for the PPC403 serial timer. + +@item serial_rate +is a PPC403 specific field which specifies the baud rate for the +PPC403 serial port. + +@item serial_external_clock +is a PPC403 specific field which indicates whether or not to mask in a 0x2 into +the Input/Output Configuration Register (IOCR) during initialization of the +PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?) + +@item serial_xon_xoff +is a PPC403 specific field which indicates whether or not +XON/XOFF flow control is supported for the PPC403 serial port. + +@item serial_cts_rts +is a PPC403 specific field which indicates whether or not to set the +least significant bit of the Input/Output Configuration Register +(IOCR) during initialization of the PPC403 console. (NOTE: This +bit is defined as "reserved" 6-12?) + +@item timer_average_overhead +is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer. + +@item timer_least_valid +is a PPC403 specific field which specifies the maximum valid PPC403 timer value. + +@end table + diff --git a/doc/cpu_supplement/preface.texi b/doc/cpu_supplement/preface.texi new file mode 100644 index 0000000000..75c3e386d9 --- /dev/null +++ b/doc/cpu_supplement/preface.texi @@ -0,0 +1,25 @@ +@c +@c COPYRIGHT (c) 1988-2006. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@node Preface, ARM Specific Information, Top, Top +@end ifinfo +@unnumbered Preface + +The Real Time Executive for Multiprocessor Systems +(RTEMS) is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +Each chapter in this document discusses the details of how +RTEMS was ported. diff --git a/doc/cpu_supplement/sh.t b/doc/cpu_supplement/sh.t new file mode 100644 index 0000000000..d3ce913457 --- /dev/null +++ b/doc/cpu_supplement/sh.t @@ -0,0 +1,685 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter SuperH Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the VENDOR XXX +architecture dependencies in this port of RTEMS. The XXX +family has a wide variety of CPU models within it. The part +numbers ... + +XXX fill in some things here + +It is highly recommended that the XXX +RTEMS application developer obtain and become familiar with the +documentation for the processor being used as well as the +documentation for the family as a whole. + +@subheading Architecture Documents + +For information on the XXX architecture, +refer to the following documents available from VENDOR +(@file{http//www.XXX.com/}): + +@itemize @bullet +@item @cite{XXX Family Reference, VENDOR, PART NUMBER}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. +@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/XXX/XXX.h based upon the particular CPU +model defined on the compilation command line. + +@subsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the MODEL +processor, this macro is set to the string "XXX". + +@subsection Floating Point Unit + +The macro XXX_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. It does not matter whether the hardware floating +point support is incorporated on-chip or is an external +coprocessor. + +@subsection Another Optional Feature + +The macro XXX +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +The Hitachi SH architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch to subroutine (XXX) or the jump to subroutine +(XXX) 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. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using either a bsr +or jsr instruction and return to the user application via the +rts instruction. + +@subsection Register Usage + +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 +directive. + + +> > The SH1 has 16 general registers (r0..r15) +> > r0..r3 used as general volatile registers +> > r4..r7 used to pass up to 4 arguments to functions, arguments above 4 are +> > passed via the stack) +> > r8..13 caller saved registers (i.e. push them to the stack if you need them +> > inside of a function) +> > r14 frame pointer +> > r15 stack pointer +> + + +@subsection Parameter Passing + +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: + +@example +@group +push third argument +push second argument +push first argument +invoke directive +remove arguments from the stack +@end group +@end example + +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. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +The XXX 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 this family. + +Some of the XXX family members such as the +XXX, XXX, and XXX support virtual memory and +segmentation. The XXX requires external hardware support +such as the XXX 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 XXX family members. + +@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 + +@section Interrupt Processing + + +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 SH's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@subsection Vectoring of an Interrupt Handler + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the SH family has two +different interrupt handling models. + +@subsubsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the SH family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@subsubsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the SH 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 +XXX 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 + +@subsection Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by XXX 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 +XXX family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to XXX interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@subsection 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 XXX 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. + +@subsection 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 XXX port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler disables processor interrupts, +places the error code in @b{XXX}, and executes a @code{XXX} +instruction to simulate a halt processor instruction. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +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 XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure 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 XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item 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. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table diff --git a/doc/cpu_supplement/sparc.t b/doc/cpu_supplement/sparc.t new file mode 100644 index 0000000000..c8fc03ba30 --- /dev/null +++ b/doc/cpu_supplement/sparc.t @@ -0,0 +1,1127 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter SPARC Specific Information + +The Real Time Executive for Multiprocessor Systems +(RTEMS) is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the SPARC architecture +dependencies in this port of RTEMS. Currently, only +implementations of SPARC Version 7 are supported by RTEMS. + +It is highly recommended that the SPARC RTEMS +application developer obtain and become familiar with the +documentation for the processor being used as well as the +specification for the revision of the SPARC architecture which +corresponds to that processor. + +@subheading SPARC Architecture Documents + +For information on the SPARC architecture, refer to +the following documents available from SPARC International, Inc. +(http://www.sparc.com): + +@itemize @bullet +@item SPARC Standard Version 7. + +@item SPARC Standard Version 8. + +@item SPARC Standard Version 9. +@end itemize + +@subheading ERC32 Specific Information + +The European Space Agency's ERC32 is a three chip +computing core implementing a SPARC V7 processor and associated +support circuitry for embedded space applications. The integer +and floating-point units (90C601E & 90C602E) are based on the +Cypress 7C601 and 7C602, with additional error-detection and +recovery functions. The memory controller (MEC) implements +system support functions such as address decoding, memory +interface, DMA interface, UARTs, timers, interrupt control, +write-protection, memory reconfiguration and error-detection. +The core is designed to work at 25MHz, but using space qualified +memories limits the system frequency to around 15 MHz, resulting +in a performance of 10 MIPS and 2 MFLOPS. + +Information on the ERC32 and a number of development +support tools, such as the SPARC Instruction Simulator (SIS), +are freely available on the Internet. The following documents +and SIS are available via anonymous ftp or pointing your web +browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. + +@itemize @bullet +@item ERC32 System Design Document + +@item MEC Device Specification +@end itemize + +Additionally, the SPARC RISC User's Guide from Matra +MHS documents the functionality of the integer and floating +point units including the instruction set information. To +obtain this document as well as ERC32 components and VHDL models +contact: + +@example +Matra MHS SA +3 Avenue du Centre, BP 309, +78054 St-Quentin-en-Yvelines, +Cedex, France +VOICE: +31-1-30607087 +FAX: +31-1-30640693 +@end example + +Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. + +@subsection CPU Model Feature Flags + +Each processor family supported by RTEMS has a +list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This section presents the set of features which vary +across SPARC implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file +cpukit/score/cpu/sparc/sparc.h based upon the particular CPU +model defined on the compilation command line. + +@subsubsection CPU Model Name + +The macro CPU_MODEL_NAME is a string which designates +the name of this CPU model. For example, for the European Space +Agency's ERC32 SPARC model, this macro is set to the string +"erc32". + +@subsubsection Floating Point Unit + +The macro SPARC_HAS_FPU is set to 1 to indicate that +this CPU model has a hardware floating point unit and 0 +otherwise. + +@subsubsection Bitscan Instruction + +The macro SPARC_HAS_BITSCAN is set to 1 to indicate +that this CPU model has the bitscan instruction. For example, +this instruction is supported by the Fujitsu SPARClite family. + +@subsubsection Number of Register Windows + +The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to +indicate the number of register window sets implemented by this +CPU model. The SPARC architecture allows a for a maximum of +thirty-two register window sets although most implementations +only include eight. + +@subsubsection Low Power Mode + +The macro SPARC_HAS_LOW_POWER_MODE is set to one to +indicate that this CPU model has a low power mode. If low power +is enabled, then there must be CPU model specific implementation +of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low +power mode IDLE task should be of the form: + +@example +while ( TRUE ) @{ + enter low power mode +@} +@end example + +The code required to enter low power mode is CPU model specific. + +@subsection CPU Model Implementation Notes + +The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602 +chipset. This CPU has a number of on-board peripherals and was developed by +the European Space Agency to target space applications. RTEMS currently +provides support for the following peripherals: + +@itemize @bullet +@item UART Channels A and B +@item General Purpose Timer +@item Real Time Clock +@item Watchdog Timer (so it can be disabled) +@item Control Register (so powerdown mode can be enabled) +@item Memory Control Register +@item Interrupt Control +@end itemize + +The General Purpose Timer and Real Time Clock Timer provided with the ERC32 +share the Timer Control Register. Because the Timer Control Register is write +only, we must mirror it in software and insure that writes to one timer do not +alter the current settings and status of the other timer. Routines are +provided in erc32.h which promote the view that the two timers are completely +independent. By exclusively using these routines to access the Timer Control +Register, the application can view the system as having a General Purpose +Timer Control Register and a Real Time Clock Timer Control Register +rather than the single shared value. + +The RTEMS Idle thread take advantage of the low power mode provided by the +ERC32. Low power mode is entered during idle loops and is enabled at +initialization time. +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage + +@item parameter passing + +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +@subsection Programming Model + +This section discusses the programming model for the +SPARC architecture. + +@subsubsection Non-Floating Point Registers + +The SPARC architecture defines thirty-two +non-floating point registers directly visible to the programmer. +These are divided into four sets: + +@itemize @bullet +@item input registers + +@item local registers + +@item output registers + +@item global registers +@end itemize + +Each register is referred to by either two or three +names in the SPARC reference manuals. First, the registers are +referred to as r0 through r31 or with the alternate notation +r[0] through r[31]. Second, each register is a member of one of +the four sets listed above. Finally, some registers have an +architecturally defined role in the programming model which +provides an alternate name. The following table describes the +mapping between the 32 registers and the register sets: + +@ifset use-ascii +@example +@group + +-----------------+----------------+------------------+ + | Register Number | Register Names | Description | + +-----------------+----------------+------------------+ + | 0 - 7 | g0 - g7 | Global Registers | + +-----------------+----------------+------------------+ + | 8 - 15 | o0 - o7 | Output Registers | + +-----------------+----------------+------------------+ + | 16 - 23 | l0 - l7 | Local Registers | + +-----------------+----------------+------------------+ + | 24 - 31 | i0 - i7 | Input Registers | + +-----------------+----------------+------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} +&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} +&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} +&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} +&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + + + + +
Register NumberRegister NamesDescription
0 - 7g0 - g7Global Registers
8 - 15o0 - o7Output Registers
16 - 23l0 - l7Local Registers
24 - 31i0 - i7Input Registers
+
+@end html +@end ifset + +As mentioned above, some of the registers serve +defined roles in the programming model. The following table +describes the role of each of these registers: + +@ifset use-ascii +@example +@group + +---------------+----------------+----------------------+ + | Register Name | Alternate Name | Description | + +---------------+----------------+----------------------+ + | g0 | na | reads return 0 | + | | | writes are ignored | + +---------------+----------------+----------------------+ + | o6 | sp | stack pointer | + +---------------+----------------+----------------------+ + | i6 | fp | frame pointer | + +---------------+----------------+----------------------+ + | i7 | na | return address | + +---------------+----------------+----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} +&g0&&NA&&reads return 0; &\cr +&&&&&writes are ignored&\cr\noalign{\hrule} +&o6&&sp&&stack pointer&\cr\noalign{\hrule} +&i6&&fp&&frame pointer&\cr\noalign{\hrule} +&i7&&NA&&return address&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + + + + + + +
Register NameAlternate NameDescription
g0NAreads return 0 ; writes are ignored
o6spstack pointer
i6fpframe pointer
i7NAreturn address
+
+@end html +@end ifset + + +@subsubsection Floating Point Registers + +The SPARC V7 architecture includes thirty-two, +thirty-two bit registers. These registers may be viewed as +follows: + +@itemize @bullet +@item 32 single precision floating point or integer registers +(f0, f1, ... f31) + +@item 16 double precision floating point registers (f0, f2, +f4, ... f30) + +@item 8 extended precision floating point registers (f0, f4, +f8, ... f28) +@end itemize + +The floating point status register (fpsr) specifies +the behavior of the floating point unit for rounding, contains +its condition codes, version specification, and trap information. + +A queue of the floating point instructions which have +started execution but not yet completed is maintained. This +queue is needed to support the multiple cycle nature of floating +point operations and to aid floating point exception trap +handlers. Once a floating point exception has been encountered, +the queue is frozen until it is emptied by the trap handler. +The floating point queue is loaded by launching instructions. +It is emptied normally when the floating point completes all +outstanding instructions and by floating point exception +handlers with the store double floating point queue (stdfq) +instruction. + +@subsubsection Special Registers + +The SPARC architecture includes two special registers +which are critical to the programming model: the Processor State +Register (psr) and the Window Invalid Mask (wim). The psr +contains the condition codes, processor interrupt level, trap +enable bit, supervisor mode and previous supervisor mode bits, +version information, floating point unit and coprocessor enable +bits, and the current window pointer (cwp). The cwp field of +the psr and wim register are used to manage the register windows +in the SPARC architecture. The register windows are discussed +in more detail below. + +@subsection Register Windows + +The SPARC architecture includes the concept of +register windows. An overly simplistic way to think of these +windows is to imagine them as being an infinite supply of +"fresh" register sets available for each subroutine to use. In +reality, they are much more complicated. + +The save instruction is used to obtain a new register +window. This instruction decrements the current window pointer, +thus providing a new set of registers for use. This register +set includes eight fresh local registers for use exclusively by +this subroutine. When done with a register set, the restore +instruction increments the current window pointer and the +previous register set is once again available. + +The two primary issues complicating the use of +register windows are that (1) the set of register windows is +finite, and (2) some registers are shared between adjacent +registers windows. + +Because the set of register windows is finite, it is +possible to execute enough save instructions without +corresponding restore's to consume all of the register windows. +This is easily accomplished in a high level language because +each subroutine typically performs a save instruction upon +entry. Thus having a subroutine call depth greater than the +number of register windows will result in a window overflow +condition. The window overflow condition generates a trap which +must be handled in software. The window overflow trap handler +is responsible for saving the contents of the oldest register +window on the program stack. + +Similarly, the subroutines will eventually complete +and begin to perform restore's. If the restore results in the +need for a register window which has previously been written to +memory as part of an overflow, then a window underflow condition +results. Just like the window overflow, the window underflow +condition must be handled in software by a trap handler. The +window underflow trap handler is responsible for reloading the +contents of the register window requested by the restore +instruction from the program stack. + +The Window Invalid Mask (wim) and the Current Window +Pointer (cwp) field in the psr are used in conjunction to manage +the finite set of register windows and detect the window +overflow and underflow conditions. The cwp contains the index +of the register window currently in use. The save instruction +decrements the cwp modulo the number of register windows. +Similarly, the restore instruction increments the cwp modulo the +number of register windows. Each bit in the wim represents +represents whether a register window contains valid information. +The value of 0 indicates the register window is valid and 1 +indicates it is invalid. When a save instruction causes the cwp +to point to a register window which is marked as invalid, a +window overflow condition results. Conversely, the restore +instruction may result in a window underflow condition. + +Other than the assumption that a register window is +always available for trap (i.e. interrupt) handlers, the SPARC +architecture places no limits on the number of register windows +simultaneously marked as invalid (i.e. number of bits set in the +wim). However, RTEMS assumes that only one register window is +marked invalid at a time (i.e. only one bit set in the wim). +This makes the maximum possible number of register windows +available to the user while still meeting the requirement that +window overflow and underflow conditions can be detected. + +The window overflow and window underflow trap +handlers are a critical part of the run-time environment for a +SPARC application. The SPARC architectural specification allows +for the number of register windows to be any power of two less +than or equal to 32. The most common choice for SPARC +implementations appears to be 8 register windows. This results +in the cwp ranging in value from 0 to 7 on most implementations. + + +The second complicating factor is the sharing of +registers between adjacent register windows. While each +register window has its own set of local registers, the input +and output registers are shared between adjacent windows. The +output registers for register window N are the same as the input +registers for register window ((N - 1) modulo RW) where RW is +the number of register windows. An alternative way to think of +this is to remember how parameters are passed to a subroutine on +the SPARC. The caller loads values into what are its output +registers. Then after the callee executes a save instruction, +those parameters are available in its input registers. This is +a very efficient way to pass parameters as no data is actually +moved by the save or restore instructions. + +@subsection Call and Return Mechanism + +The SPARC architecture supports a simple yet +effective call and return mechanism. A subroutine is invoked +via the call (call) instruction. This instruction places the +return address in the caller's output register 7 (o7). After +the callee executes a save instruction, this value is available +in input register 7 (i7) until the corresponding restore +instruction is executed. + +The callee returns to the caller via a jmp to the +return address. There is a delay slot following this +instruction which is commonly used to execute a restore +instruction -- if a register window was allocated by this +subroutine. + +It is important to note that the SPARC subroutine +call and return mechanism does not automatically save and +restore any registers. This is accomplished via the save and +restore instructions which manage the set of registers windows. + +@subsection Calling Mechanism + +All RTEMS directives are invoked using the regular +SPARC calling convention via the call instruction. + +@subsection Register Usage + +As discussed above, the call instruction does not +automatically save any registers. The save and restore +instructions are used to allocate and deallocate register +windows. When a register window is allocated, the new set of +local registers are available for the exclusive use of the +subroutine which allocated this register set. + +@subsection Parameter Passing + +RTEMS assumes that arguments are placed in the +caller's output registers with the first argument in output +register 0 (o0), the second argument in output register 1 (o1), +and so forth. Until the callee executes a save instruction, the +parameters are still visible in the output registers. After the +callee executes a save instruction, the parameters are visible +in the corresponding input registers. The following pseudo-code +illustrates the typical sequence used to call a RTEMS directive +with three (3) arguments: + +@example +load third argument into o2 +load second argument into o1 +load first argument into o0 +invoke directive +@end example + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Flat Memory Model + +The SPARC architecture 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, half-word (2-bytes), word (4 bytes), or doubleword +(8 bytes). Memory accesses within this address space are +performed in big endian fashion by the SPARC. Memory accesses +which are not properly aligned generate a "memory address not +aligned" trap (type number 7). The following table lists the +alignment requirements for a variety of data accesses: + +@ifset use-ascii +@example +@group + +--------------+-----------------------+ + | Data Type | Alignment Requirement | + +--------------+-----------------------+ + | byte | 1 | + | half-word | 2 | + | word | 4 | + | doubleword | 8 | + +--------------+-----------------------+ +@end group +@end example +@end ifset + +@ifset use-tex +@sp 1 +@tex +\centerline{\vbox{\offinterlineskip\halign{ +\vrule\strut#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#& +\hbox to 1.75in{\enskip\hfil#\hfil}& +\vrule#\cr +\noalign{\hrule} +&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} +&byte&&1&\cr\noalign{\hrule} +&half-word&&2&\cr\noalign{\hrule} +&word&&4&\cr\noalign{\hrule} +&doubleword&&8&\cr\noalign{\hrule} +}}\hfil} +@end tex +@end ifset + +@ifset use-html +@html +
+ + + + + + + + + + + +
Data TypeAlignment Requirement
byte1
half-word2
word4
doubleword8
+
+@end html +@end ifset + +Doubleword load and store operations must use a pair +of registers as their source or destination. This pair of +registers must be an adjacent pair of registers with the first +of the pair being even numbered. For example, a valid +destination for a doubleword load might be input registers 0 and +1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: +Some assemblers for the SPARC do not generate an error if an odd +numbered register is specified as the beginning register of the +pair. In this case, the assembler assumes that what the +programmer meant was to use the even-odd pair which ends at the +specified register. This may or may not have been a correct +assumption.] + +RTEMS does not support any SPARC Memory Management +Units, therefore, virtual memory or segmentation systems +involving the SPARC are not supported. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + + +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 SPARC's +interrupt response and control mechanisms as they pertain to +RTEMS. + +RTEMS and associated documentation uses the terms +interrupt and vector. In the SPARC architecture, these terms +correspond to traps and trap type, respectively. The terms will +be used interchangeably in this manual. + +@subsection Synchronous Versus Asynchronous Traps + +The SPARC architecture includes two classes of traps: +synchronous and asynchronous. Asynchronous traps occur when an +external event interrupts the processor. These traps are not +associated with any instruction executed by the processor and +logically occur between instructions. The instruction currently +in the execute stage of the processor is allowed to complete +although subsequent instructions are annulled. The return +address reported by the processor for asynchronous traps is the +pair of instructions following the current instruction. + +Synchronous traps are caused by the actions of an +instruction. The trap stimulus in this case either occurs +internally to the processor or is from an external signal that +was provoked by the instruction. These traps are taken +immediately and the instruction that caused the trap is aborted +before any state changes occur in the processor itself. The +return address reported by the processor for synchronous traps +is the instruction which caused the trap and the following +instruction. + +@subsection Vectoring of Interrupt Handler + +Upon receipt of an interrupt the SPARC automatically +performs the following actions: + +@itemize @bullet +@item disables traps (sets the ET bit of the psr to 0), + +@item the S bit of the psr is copied into the Previous +Supervisor Mode (PS) bit of the psr, + +@item the cwp is decremented by one (modulo the number of +register windows) to activate a trap window, + +@item the PC and nPC are loaded into local register 1 and 2 +(l0 and l1), + +@item the trap type (tt) field of the Trap Base Register (TBR) +is set to the appropriate value, and + +@item if the trap is not a reset, then the PC is written with +the contents of the TBR and the nPC is written with TBR + 4. If +the trap is a reset, then the PC is set to zero and the nPC is +set to 4. +@end itemize + +Trap processing on the SPARC has two features which +are noticeably different than interrupt processing on other +architectures. First, the value of psr register in effect +immediately before the trap occurred is not explicitly saved. +Instead only reversible alterations are made to it. Second, the +Processor Interrupt Level (pil) is not set to correspond to that +of the interrupt being processed. When a trap occurs, ALL +subsequent traps are disabled. In order to safely invoke a +subroutine during trap handling, traps must be enabled to allow +for the possibility of register window overflow and underflow +traps. + +If the interrupt handler was installed as an RTEMS +interrupt handler, then upon receipt of the interrupt, the +processor passes control to the RTEMS interrupt handler which +performs the following actions: + +@itemize @bullet +@item saves the state of the interrupted task on it's stack, + +@item insures that a register window is available for +subsequent traps, + +@item if this is the outermost (i.e. non-nested) interrupt, +then the RTEMS interrupt handler switches from the current stack +to the interrupt stack, + +@item enables traps, + +@item invokes the vectors to a user interrupt service routine (ISR). +@end itemize + +Asynchronous interrupts are ignored while traps are +disabled. Synchronous traps which occur while traps are +disabled result in the CPU being forced into an error mode. + +A nested interrupt is processed similarly with the +exception that the current stack need not be switched to the +interrupt stack. + +@subsection Traps and Register Windows + +One of the register windows must be reserved at all +times for trap processing. This is critical to the proper +operation of the trap mechanism in the SPARC architecture. It +is the responsibility of the trap handler to insure that there +is a register window available for a subsequent trap before +re-enabling traps. It is likely that any high level language +routines invoked by the trap handler (such as a user-provided +RTEMS interrupt handler) will allocate a new register window. +The save operation could result in a window overflow trap. This +trap cannot be correctly processed unless (1) traps are enabled +and (2) a register window is reserved for traps. Thus, the +RTEMS interrupt handler insures that a register window is +available for subsequent traps before enabling traps and +invoking the user's interrupt handler. + +@subsection Interrupt Levels + +Sixteen levels (0-15) of interrupt priorities are +supported by the SPARC architecture with level fifteen (15) +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 +SPARC only supports sixteen. RTEMS interrupt levels 0 through +15 directly correspond to SPARC processor interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@subsection 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 (15) +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 ERC32 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.] + +[NOTE: It is thought that the length of time at which +the processor interrupt level is elevated to fifteen by RTEMS is +not anywhere near as long as the length of time ALL traps are +disabled as part of the "flush all register windows" operation.] + +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. + +@subsection Interrupt Stack + +The SPARC architecture does not provide for a +dedicated interrupt stack. Thus by default, trap handlers would +execute on the stack of the RTEMS task which they interrupted. +This artificially inflates the stack requirements for each task +since EVERY task stack would have to include enough space to +account for the worst case interrupt stack requirements in +addition to it's own worst case usage. RTEMS addresses this +problem on the SPARC by providing a dedicated interrupt stack +managed by software. + +During system initialization, 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. As +part of processing a non-nested interrupt, RTEMS will switch to +the interrupt stack before invoking the installed handler. + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the fatal_error_occurred directive when there is no user handler +configured or the user handler returns control to RTEMS. The +default fatal error handler disables processor interrupts to +level 15, places the error code in g1, and goes into an infinite +loop to simulate a halt processor instruction. + + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of SPARC specific BSP issues. +For more information on developing a BSP, refer to the chapter +titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the SPARC processor is reset. When the SPARC +is reset, the processor performs the following actions: + +@itemize @bullet +@item the enable trap (ET) of the psr is set to 0 to disable +traps, + +@item the supervisor bit (S) of the psr is set to 1 to enter +supervisor mode, and + +@item the PC is set 0 and the nPC is set to 4. +@end itemize + +The processor then begins to execute the code at +location 0. It is important to note that all fields in the psr +are not explicitly set by the above steps and all other +registers retain their value from the previous execution mode. +This is true even of the Trap Base Register (TBR) whose contents +reflect the last trap which occurred before the reset. + +@subsection Processor Initialization + +It is the responsibility of the application's +initialization code to initialize the TBR and install trap +handlers for at least the register window overflow and register +window underflow conditions. Traps should be enabled before +invoking any subroutines to allow for register window +management. However, interrupts should be disabled by setting +the Processor Interrupt Level (pil) field of the psr to 15. +RTEMS installs it's own Trap Table as part of initialization +which is initialized with the contents of the Trap Table in +place when the @code{rtems_initialize_executive} directive was invoked. +Upon completion of executive initialization, interrupts are +enabled. + +If this SPARC implementation supports on-chip caching +and this 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 @value{LANGUAGE} +Applications User's Manual for the reset code +which is executed before the call to +@code{rtems_initialize_executive}, the SPARC version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the SPARC remains in the supervisor state. + +@item Must set stack pointer (sp) such that a minimum stack +size of MINIMUM_STACK_SIZE bytes is provided for the +@code{rtems_initialize_executive} directive. + +@item Must disable all external interrupts (i.e. set the pil +to 15). + +@item Must enable traps so window overflow and underflow +conditions can be properly handled. + +@item Must initialize the SPARC's initial trap table with at +least trap handlers for register window overflow and register +window underflow. +@end itemize + +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The SPARC version of the RTEMS CPU Dependent +Information Table is given by the C structure definition is +shown below: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS allocated interrupt stack in bytes. +This value must be at least as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@end table + diff --git a/doc/cpu_supplement/tic4x.t b/doc/cpu_supplement/tic4x.t new file mode 100644 index 0000000000..9c276eae5c --- /dev/null +++ b/doc/cpu_supplement/tic4x.t @@ -0,0 +1,888 @@ +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@ifinfo +@end ifinfo +@chapter Texas Instruments C3x/C4x Specific Information + +The Real Time Executive for Multiprocessor Systems (RTEMS) +is designed to be portable across multiple processor +architectures. However, the nature of real-time systems makes +it essential that the application designer understand certain +processor dependent implementation details. These processor +dependencies include calling convention, board support package +issues, interrupt processing, exact RTEMS memory requirements, +performance data, header files, and the assembly language +interface to the executive. + +This document discusses the Texas Instrument C3x/C4x +architecture dependencies in this port of RTEMS. The C3x/C4x +family has a wide variety of CPU models within it. The following +CPU model numbers could be supported by this port: + +@itemize +@item C30 - TMSXXX +@item C31 - TMSXXX +@item C32 - TMSXXX +@item C41 - TMSXXX +@item C44 - TMSXXX +@end itemize + +Initiially, this port does not include full support for C4x models. +Primarily, the C4x specific implementations of interrupt flag and +mask management routines have not been completed. + +It is highly recommended that the RTEMS application developer obtain +and become familiar with the documentation for the processor being +used as well as the documentation for the family as a whole. + +@subheading Architecture Documents + +For information on the Texas Instruments C3x/C4x architecture, +refer to the following documents available from VENDOR +(@file{http//www.ti.com/}): + +@itemize @bullet +@item @cite{XXX Family Reference, Texas Instruments, PART NUMBER}. +@end itemize + +@subheading MODEL SPECIFIC DOCUMENTS + +For information on specific processor models and +their associated coprocessors, refer to the following documents: + +@itemize @bullet +@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. +@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. +@end itemize + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section CPU Model Dependent Features + + +Microprocessors are generally classified into +families with a variety of CPU models or implementations within +that family. Within a processor family, there is a high level +of binary compatibility. This family may be based on either an +architectural specification or on maintaining compatibility with +a popular processor. Recent microprocessor families such as the +SPARC or PowerPC are based on an architectural specification +which is independent or any particular CPU model or +implementation. Older families such as the M68xxx and the iX86 +evolved as the manufacturer strived to produce higher +performance processor models which maintained binary +compatibility with older models. + +RTEMS takes advantage of the similarity of the +various models within a CPU family. Although the models do vary +in significant ways, the high level of compatibility makes it +possible to share the bulk of the CPU dependent executive code +across the entire family. Each processor family supported by +RTEMS has a list of features which vary between CPU models +within a family. For example, the most common model dependent +feature regardless of CPU family is the presence or absence of a +floating point unit or coprocessor. When defining the list of +features present on a particular CPU model, one simply notes +that floating point hardware is or is not present and defines a +single constant appropriately. Conditional compilation is +utilized to include the appropriate source code for this CPU +model's feature set. It is important to note that this means +that RTEMS is thus compiled using the appropriate feature set +and compilation flags optimal for this CPU model used. The +alternative would be to generate a binary which would execute on +all family members using only the features which were always +present. + +This chapter presents the set of features which vary +across the various implementations of the C3x/C4x architecture +that are of importance to rtems. +the set of cpu model feature macros are defined in the file +cpukit/score/cpu/c4x/rtems/score/c4x.h and are based upon +the particular cpu model defined in the bsp's custom configuration +file as well as the compilation command line. + +@subsection CPU Model Name + +The macro @code{CPU_MODEL_NAME} is a string which designates +the name of this cpu model. for example, for the c32 +processor, this macro is set to the string "c32". + +@subsection Floating Point Unit + +The Texas Instruments C3x/C4x family makes little distinction +between the various cpu registers. Although floating point +operations may only be performed on a subset of the cpu registers, +these same registers may be used for normal integer operations. +as a result of this, this port of rtems makes no distinction +between integer and floating point contexts. The routine +@code{_CPU_Context_switch} saves all of the registers that +comprise a task's context. the routines that initialize, +save, and restore floating point contexts are not present +in this port. + +Moreover, there is no floating point context pointer and +the code in @code{_Thread_Dispatch} that manages the +floating point context switching process is disabled +on this port. + +This not only simplifies the port, it also speeds up context +switches by reducing the code involved and reduces the code +space footprint of the executive on the Texas Instruments +C3x/C4x. + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Calling Conventions + + +Each high-level language compiler generates +subroutine entry and exit code based upon a set of rules known +as the compiler's calling convention. These rules address the +following issues: + +@itemize @bullet +@item register preservation and usage +@item parameter passing +@item call and return mechanism +@end itemize + +A compiler's calling convention is of importance when +interfacing to subroutines written in another language either +assembly or high-level. Even when the high-level language and +target processor are the same, different compilers may use +different calling conventions. As a result, calling conventions +are both processor and compiler dependent. + +The GNU Compiler Suite follows the same calling conventions +as the Texas Instruments toolset. + +@subsection Processor Background + +The TI C3x and C4x processors support a simple yet +effective call and return mechanism. A subroutine is invoked +via the branch to subroutine (@code{XXX}) or the jump to subroutine +(@code{XXX}) instructions. These instructions push the return address +on the current stack. The return from subroutine (@code{XXX}) +instruction pops the return address off the current stack and +transfers control to that instruction. It is important to +note that the call and return mechanism for the C3x/C4x 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. + +XXX other supplements may have "is is". + +@subsection Calling Mechanism + +All subroutines are invoked using either a @code{XXX} +or @code{XXX} instruction and return to the user application via the +@code{XXX} instruction. + +@subsection Register Usage + +XXX + +As discussed above, the @code{XXX} and @code{XXX} instructions do +not automatically save any registers. Subroutines use the registers +@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are +not preserved by subroutines therefore, the contents of +these registers should not be assumed upon return from any subroutine +call including but not limited to an RTEMS directive. + +The GNU and Texas Instruments compilers follow the same conventions +for register usage. + +@subsection Parameter Passing + +Both the GNU and Texas Instruments compilers support two conventions +for passing parameters to subroutines. Arguments may be passed in +memory on the stack or in registers. + +@subsubsection Parameters Passed in Memory + +When passing parameters on the stack, the calling convention assumes +that arguments are placed on the current stack before the subroutine +is invoked via the @code{XXX} 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 +subroutine with three (3) arguments: + +@example +@group +push third argument +push second argument +push first argument +invoke subroutine +remove arguments from the stack +@end group +@end example + +The arguments to RTEMS are typically pushed onto the +stack using a @code{sti} instruction with a pre-incremented 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 subtracting the size of the +argument list in words from the current stack pointer. + +@c XXX XXX instruction .. XXX should be code format. + +With the GNU Compiler Suite, parameter passing via the +stack is selected by invoking the compiler with the +@code{-mmemparm XXX} argument. This argument must be +included when linking the application in order to +ensure that support libraries also compiled assuming +parameter passing via the stack are used. The default +parameter passing mechanism is XXX. + +When this parameter passing mecahanism is selected, the @code{XXX} +symbol is predefined by the C and C++ compilers +and the @code{XXX} symbol is predefined by the assembler. +This behavior is the same for the GNU and Texas Instruments +toolsets. RTEMS uses these predefines to determine how +parameters are passed in to those C3x/C4x specific routines +that were written in assembly language. + +@subsubsection Parameters Passed in Registers + +When passing parameters via registers, the calling convention assumes +that the arguments are placed in particular registers based upon +their position and data type before the subroutine is invoked via +the @code{XXX} instruction. + +The following pseudo-code illustrates +the typical sequence used to call a subroutine with three (3) arguments: + +@example +@group +move third argument to XXX +move second argument to XXX +move first argument to XXX +invoke subroutine +@end group +@end example + +With the GNU Compiler Suite, parameter passing via +registers is selected by invoking the compiler with the +@code{-mregparm XXX} argument. This argument must be +included when linking the application in order to +ensure that support libraries also compiled assuming +parameter passing via the stack are used. The default +parameter passing mechanism is XXX. + +When this parameter passing mecahanism is selected, the @code{XXX} +symbol is predefined by the C and C++ compilers +and the @code{XXX} symbol is predefined by the assembler. +This behavior is the same for the GNU and Texas Instruments +toolsets. RTEMS uses these predefines to determine how +parameters are passed in to those C3x/C4x specific routines +that were written in assembly language. + +@subsection User-Provided Routines + +All user-provided routines invoked by RTEMS, such as +user extensions, device drivers, and MPCI routines, must also +adhere to these calling conventions. + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Memory Model + + +A processor may support any combination of memory +models ranging from pure physical addressing to complex demand +paged virtual memory systems. RTEMS supports a flat memory +model which ranges contiguously over the processor's allowable +address space. RTEMS does not support segmentation or virtual +memory of any kind. The appropriate memory model for RTEMS +provided by the targeted processor and related characteristics +of that model are described in this chapter. + +@subsection Byte Addressable versus Word Addressable + +Processor in the Texas Instruments C3x/C4x family are +word addressable. This is in sharp contrast to CISC and +RISC processors that are typically byte addressable. In a word +addressable architecture, each address points not to an +8-bit byte or octet but to 32 bits. + +On first glance, byte versus word addressability does not +sound like a problem but in fact, this issue can result in +subtle problems in high-level language software that is ported +to a word addressable processor family. The following is a +list of the commonly encountered problems: + +@table @b + +@item String Optimizations +Although each character in a string occupies a single address just +as it does on a byte addressable CPU, each character occupies +32 rather than 8 bits. The most significant 24 bytes are +of each address are ignored. This in and of itself does not +cause problems but it violates the assumption that two +adjacent characters in a string have no intervening bits. +This assumption is often implicit in string and memory comparison +routines that are optimized to compare 4 adjacent characters +with a word oriented operation. This optimization is +invalid on word addressable processors. + +@item Sizeof +The C operation @code{sizeof} returns very different results +on the C3x/C4x than on traditional RISC/CISC processors. +The @code{sizeof(char)}, @code{sizeof(short)}, and @code{sizeof(int)} +are all 1 since each occupies a single addressable unit that is +thirty-two bits wide. On most thirty-two bit processors, +@code{sizeof(char} is one, @code{sizeof(short)} is two, +and @code{sizeof(int)} is four. Just as software makes assumptions +about the sizes of the primitive data types has problems +when ported to a sixty-four bit architecture, these same +assumptions cause problems on the C3x/C4x. + +@item Alignment +Since each addressable unit is thirty-two bit wide, there +are no alignment restrictions. The native integer type +need only be aligned on a "one unit" boundary not a "four +unit" boundary as on numerous other processors. + +@end table + +@subsection Flat Memory Model + +XXX check actual bits on the various processor families. + +The XXX 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 this family. + +@subsection Compiler Memory Models + +The Texas Instruments C3x/C4x processors include a Data Page +(@code{dp}) register that logically is a base address. The +@code{dp} register allows the use of shorter offsets in +instructions. Up to 64K words may be addressed using +offsets from the @code{dp} register. In order to address +words not addressable based on the current value of +@code{dp}, the register must be loaded with a different +value. + +The @code{dp} register is managed automatically by +the high-level language compilers. +The various compilers for this processor family support +two memory models that manage the @code{dp} register +in very different manners. The large and small memory +models are discussed in the following sections. + +NOTE: The C3x/C4x port of RTEMS has been written +so that it should support either memory model. +However, it has only been tested using the +large memory model. + +@subsubsection Small Memory Model + +The small memory model is the simplest and most +efficient. However, it includes a limitation that +make it inappropriate for numerous applications. The +small memory model assumes that the application needs +to access no more than 64K words. Thus the @code{dp} +register can be loaded at application start time +and never reloaded. Thus the compiler will not +even generate instructions to load the @code{dp}. + +This can significantly reduce the code space +required by an application but the application +is limited in the amount of data it can access. + +With the GNU Compiler Suite, small memory model is +selected by invoking the compiler with either the +@code{-msmall} or @code{-msmallmemoryXXX} argument. +This argument must be included when linking the application +in order to ensure that support libraries also compiled +for the large memory model are used. +The default memory model is XXX. + +When this memory model is selected, the @code{XXX} +symbol is predefined by the C and C++ compilers +and the @code{XXX} symbol is predefined by the assembler. +This behavior is the same for the GNU and Texas Instruments +toolsets. RTEMS uses these predefines to determine the proper handling +of the @code{dp} register in those C3x/C4x specific routines +that were written in assembly language. + +@subsubsection Large Memory Model + +The large memory model is more complex and less efficient +than the small memory model. However, it removes the +64K uninitialized data restriction from applications. +The @code{dp} register is reloaded automatically +by the compiler each time data is accessed. This leads +to an increase in the code space requirements for the +application but gives it access to much more data space. + +With the GNU Compiler Suite, large memory model is +selected by invoking the compiler with either the +@code{-mlarge} or @code{-mlargememoryXXX} argument. +This argument must be included when linking the application +in order to ensure that support libraries also compiled +for the large memory model are used. +The default memory model is XXX. + +When this memory model is selected, the @code{XXX} +symbol is predefined by the C and C++ compilers +and the @code{XXX} symbol is predefined by the assembler. +This behavior is the same for the GNU and Texas Instruments +toolsets. RTEMS uses these predefines to determine the proper handling +of the @code{dp} register in those C3x/C4x specific routines +that were written in assembly language. +@c +@c Interrupt Stack Frame Picture +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Interrupt Processing + + +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 XXX's +interrupt response and control mechanisms as they pertain to +RTEMS. + +@subsection Vectoring of an Interrupt Handler + +Depending on whether or not the particular CPU +supports a separate interrupt stack, the XXX family has two +different interrupt handling models. + +@subsubsection Models Without Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX family +members without separate interrupt stacks automatically perform +the following actions: + +@itemize @bullet +@item To Be Written +@end itemize + +@subsubsection Models With Separate Interrupt Stacks + +Upon receipt of an interrupt the XXX 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 +XXX 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 + +@subsection Interrupt Levels + +Eight levels (0-7) of interrupt priorities are +supported by XXX 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 +XXX family only supports eight. RTEMS interrupt levels 0 +through 7 directly correspond to XXX interrupt levels. All +other RTEMS interrupt levels are undefined and their behavior is +unpredictable. + +@subsection 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 XXX 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. + +@subsection 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 XXX port of RTEMS supports a software managed +dedicated interrupt stack on those CPU models which do not +support a separate interrupt stack in hardware. + + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Default Fatal Error Processing + + +Upon detection of a fatal error by either the +application or RTEMS the fatal error manager is invoked. The +fatal error manager will invoke the user-supplied fatal error +handlers. If no user-supplied handlers are configured, the +RTEMS provided default fatal error handler is invoked. If the +user-supplied fatal error handlers return to the executive the +default fatal error handler is then invoked. This chapter +describes the precise operations of the default fatal error +handler. + +@subsection Default Fatal Error Handler Operations + +The default fatal error handler which is invoked by +the @code{rtems_fatal_error_occurred} directive when there is +no user handler configured or the user handler returns control to +RTEMS. The default fatal error handler disables processor interrupts, +places the error code in @b{XXX}, and executes a @code{XXX} +instruction to simulate a halt processor instruction. + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Board Support Packages + + +An RTEMS Board Support Package (BSP) must be designed +to support a particular processor and target board combination. +This chapter presents a discussion of XXX specific BSP +issues. For more information on developing a BSP, refer to the +chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or +re-initiated when the XXX processor is reset. When the +XXX is reset, the processor performs the following actions: + +@itemize @bullet +@item The tracing bits of the status register are cleared to +disable tracing. + +@item The supervisor interrupt state is entered by setting the +supervisor (S) bit and clearing the master/interrupt (M) bit of +the status register. + +@item The interrupt mask of the status register is set to +level 7 to effectively disable all maskable interrupts. + +@item The vector base register (VBR) is set to zero. + +@item The cache control register (CACR) is set to zero to +disable and freeze the processor cache. + +@item The interrupt stack pointer (ISP) is set to the value +stored at vector 0 (bytes 0-3) of the exception vector table +(EVT). + +@item The program counter (PC) is set to the value stored at +vector 1 (bytes 4-7) of the EVT. + +@item The processor begins execution at the address stored in +the PC. +@end itemize + +@subsection Processor Initialization + +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 XXX's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the initialize +executive directive, the VBR MUST be set before this directive +is invoked to insure 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 XXX version has the following +specific requirements: + +@itemize @bullet +@item Must leave the S bit of the status register set so that +the XXX remains in the supervisor state. + +@item Must set the M bit of the status register to remove the +XXX from the interrupt state. + +@item 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. + +@item Must initialize the XXX's vector table. +@end itemize + +Note that the BSP is not responsible for allocating +or installing the interrupt stack. RTEMS does this +automatically as part of initialization. If the BSP does not +install an interrupt stack and -- for whatever reason -- an +interrupt occurs before initialize_executive is invoked, then +the results are unpredictable. + +@c +@c COPYRIGHT (c) 1988-1999. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c + +@section Processor Dependent Information Table + + +Any highly processor dependent information required +to describe a processor to RTEMS is provided in the CPU +Dependent Information Table. This table is not required for all +processors supported by RTEMS. This chapter describes the +contents, if any, for a particular processor type. + +@subsection CPU Dependent Information Table + +The XXX version of the RTEMS CPU Dependent +Information Table contains the information required to interface +a Board Support Package and RTEMS on the XXX. This +information is provided to allow RTEMS to interoperate +effectively with the BSP. The C structure definition is given +here: + +@example +@group +typedef struct @{ + void (*pretasking_hook)( void ); + void (*predriver_hook)( void ); + void (*postdriver_hook)( void ); + void (*idle_task)( void ); + boolean do_zero_of_workspace; + unsigned32 idle_task_stack_size; + unsigned32 interrupt_stack_size; + unsigned32 extra_mpci_receive_server_stack; + void * (*stack_allocate_hook)( unsigned32 ); + void (*stack_free_hook)( void* ); + /* end of fields required on all CPUs */ + + /* XXX CPU family dependent stuff */ +@} rtems_cpu_table; +@end group +@end example + +@table @code +@item pretasking_hook +is the address of the user provided routine which is invoked +once RTEMS APIs are initialized. This routine will be invoked +before any system tasks are created. Interrupts are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item predriver_hook +is the address of the user provided +routine that is invoked immediately before the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item postdriver_hook +is the address of the user provided +routine that is invoked immediately after the +the device drivers and MPCI are initialized. RTEMS +initialization is complete but interrupts and tasking are disabled. +This field may be NULL to indicate that the hook is not utilized. + +@item idle_task +is the address of the optional user +provided routine which is used as the system's IDLE task. If +this field is not NULL, then the RTEMS default IDLE task is not +used. This field may be NULL to indicate that the default IDLE +is to be used. + +@item do_zero_of_workspace +indicates whether RTEMS should +zero the Workspace as part of its initialization. If set to +TRUE, the Workspace is zeroed. Otherwise, it is not. + +@item idle_task_stack_size +is the size of the RTEMS idle task stack in bytes. +If this number is less than MINIMUM_STACK_SIZE, then the +idle task's stack will be MINIMUM_STACK_SIZE in byte. + +@item interrupt_stack_size +is the size of the RTEMS +allocated interrupt stack in bytes. This value must be at least +as large as MINIMUM_STACK_SIZE. + +@item extra_mpci_receive_server_stack +is the extra stack space allocated for the RTEMS MPCI receive server task +in bytes. The MPCI receive server may invoke nearly all directives and +may require extra stack space on some targets. + +@item stack_allocate_hook +is the address of the optional user provided routine which allocates +memory for task stacks. If this hook is not NULL, then a stack_free_hook +must be provided as well. + +@item stack_free_hook +is the address of the optional user provided routine which frees +memory for task stacks. If this hook is not NULL, then a stack_allocate_hook +must be provided as well. + +@item XXX +is where the CPU family dependent stuff goes. + +@end table diff --git a/doc/supplements/.cvsignore b/doc/supplements/.cvsignore deleted file mode 100644 index 282522db03..0000000000 --- a/doc/supplements/.cvsignore +++ /dev/null @@ -1,2 +0,0 @@ -Makefile -Makefile.in diff --git a/doc/supplements/Makefile.am b/doc/supplements/Makefile.am deleted file mode 100644 index 94fcb0e6a4..0000000000 --- a/doc/supplements/Makefile.am +++ /dev/null @@ -1,13 +0,0 @@ -## $Id$ - -SUBDIRS = arm -SUBDIRS += c4x -SUBDIRS += i386 -SUBDIRS += m68k -SUBDIRS += mips -SUBDIRS += powerpc -SUBDIRS += sh -SUBDIRS += sparc -SUBDIRS += template - -EXTRA_DIST = supplement.am diff --git a/doc/supplements/arm/.cvsignore b/doc/supplements/arm/.cvsignore deleted file mode 100644 index 0e010a5559..0000000000 --- a/doc/supplements/arm/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -arm -arm-? -arm-?? -arm.aux -arm.cp -arm.dvi -arm.fn -arm*.html -arm.ky -arm.log -arm.pdf -arm.pg -arm.ps -arm.toc -arm.tp -arm.vr -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -stamp-vti -timeBSP_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/arm/BSP_TIMES b/doc/supplements/arm/BSP_TIMES deleted file mode 100644 index 296602a23f..0000000000 --- a/doc/supplements/arm/BSP_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# CPU MODEL/BSP Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP generic-arm9dtmi -RTEMS_CPU_MODEL arm9dtmi -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD ss-20020301 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 11 -RTEMS_RESTORE_1ST_FP_TASK NA -RTEMS_SAVE_INIT_RESTORE_INIT NA -RTEMS_SAVE_IDLE_RESTORE_INIT NA -RTEMS_SAVE_IDLE_RESTORE_IDLE NA -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 43 -RTEMS_TASK_IDENT_ONLY 85 -RTEMS_TASK_START_ONLY 19 -RTEMS_TASK_RESTART_CALLING_TASK 26 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 23 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 28 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 24 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 35 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 64 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 64 -RTEMS_TASK_DELETE_CALLING_TASK 55 -RTEMS_TASK_DELETE_SUSPENDED_TASK 42 -RTEMS_TASK_DELETE_BLOCKED_TASK 43 -RTEMS_TASK_DELETE_READY_TASK 43 -RTEMS_TASK_SUSPEND_CALLING_TASK 21 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 9 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 10 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 18 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 7 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 15 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 29 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 4 -RTEMS_TASK_MODE_NO_RESCHEDULE 4 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 13 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 30 -RTEMS_TASK_GET_NOTE_ONLY 8 -RTEMS_TASK_SET_NOTE_ONLY 7 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 5 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 17 -RTEMS_TASK_WAKE_WHEN_ONLY 33 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED unavailable -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK unavailable -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK unavailable -RTEMS_INTR_EXIT_RETURNS_TO_NESTED unavailable -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK unavailable -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK unavailable -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 21 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 10 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 8 -RTEMS_TIMER_IDENT_ONLY 83 -RTEMS_TIMER_DELETE_INACTIVE 11 -RTEMS_TIMER_DELETE_ACTIVE 12 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 14 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 15 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 21 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 21 -RTEMS_TIMER_RESET_INACTIVE 14 -RTEMS_TIMER_RESET_ACTIVE 15 -RTEMS_TIMER_CANCEL_INACTIVE 7 -RTEMS_TIMER_CANCEL_ACTIVE 9 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 27 -RTEMS_SEMAPHORE_IDENT_ONLY 97 -RTEMS_SEMAPHORE_DELETE_ONLY 24 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 5 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 5 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 28 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 9 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 14 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 22 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 54 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 83 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 32 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 14 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 16 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 25 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 14 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 16 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 25 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 11 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 35 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 42 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 15 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 10 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 29 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 8 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 9 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 7 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 13 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 22 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 14 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 7 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 24 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 7 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 16 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 29 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 22 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 25 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 27 -RTEMS_PARTITION_IDENT_ONLY 83 -RTEMS_PARTITION_DELETE_ONLY 18 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 14 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 17 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 29 -RTEMS_REGION_IDENT_ONLY 84 -RTEMS_REGION_DELETE_ONLY 17 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 14 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 18 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 56 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 15 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 40 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 58 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 18 -RTEMS_PORT_IDENT_ONLY 83 -RTEMS_PORT_DELETE_ONLY 19 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 6 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 6 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 2 -RTEMS_IO_OPEN_ONLY 1 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 1 -RTEMS_IO_WRITE_ONLY 1 -RTEMS_IO_CONTROL_ONLY 1 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 18 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 83 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 18 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 23 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 21 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 25 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 20 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 13 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE na -RTEMS_MINIMUM_CONFIGURATION na -RTEMS_MAXIMUM_CONFIGURATION na -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE na -RTEMS_INITIALIZATION_CODE_SIZE na -RTEMS_TASK_CODE_SIZE na -RTEMS_INTERRUPT_CODE_SIZE na -RTEMS_CLOCK_CODE_SIZE na -RTEMS_TIMER_CODE_SIZE na -RTEMS_SEMAPHORE_CODE_SIZE na -RTEMS_MESSAGE_CODE_SIZE na -RTEMS_EVENT_CODE_SIZE na -RTEMS_SIGNAL_CODE_SIZE na -RTEMS_PARTITION_CODE_SIZE na -RTEMS_REGION_CODE_SIZE na -RTEMS_DPMEM_CODE_SIZE na -RTEMS_IO_CODE_SIZE na -RTEMS_FATAL_ERROR_CODE_SIZE na -RTEMS_RATE_MONOTONIC_CODE_SIZE na -RTEMS_MULTIPROCESSING_CODE_SIZE na -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE na -RTEMS_SEMAPHORE_CODE_OPTSIZE na -RTEMS_MESSAGE_CODE_OPTSIZE na -RTEMS_EVENT_CODE_OPTSIZE na -RTEMS_SIGNAL_CODE_OPTSIZE na -RTEMS_PARTITION_CODE_OPTSIZE na -RTEMS_REGION_CODE_OPTSIZE na -RTEMS_DPMEM_CODE_OPTSIZE na -RTEMS_IO_CODE_OPTSIZE na -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE na -RTEMS_MULTIPROCESSING_CODE_OPTSIZE na -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK na -RTEMS_BYTES_PER_TIMER na -RTEMS_BYTES_PER_SEMAPHORE na -RTEMS_BYTES_PER_MESSAGE_QUEUE na -RTEMS_BYTES_PER_REGION na -RTEMS_BYTES_PER_PARTITION na -RTEMS_BYTES_PER_PORT na -RTEMS_BYTES_PER_PERIOD na -RTEMS_BYTES_PER_EXTENSION na -RTEMS_BYTES_PER_FP_TASK na -RTEMS_BYTES_PER_NODE na -RTEMS_BYTES_PER_GLOBAL_OBJECT na -RTEMS_BYTES_PER_PROXY na -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS na diff --git a/doc/supplements/arm/ChangeLog b/doc/supplements/arm/ChangeLog deleted file mode 100644 index 74092a8203..0000000000 --- a/doc/supplements/arm/ChangeLog +++ /dev/null @@ -1,83 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * arm.texi: Merge from branch. - -2003-01-25 Ralf Corsepius - - * arm.texi: Set @setfilename arm.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-22 Ralf Corsepius - - * wksheets.texi: Remove from CVS. - * timing.texi: Remove from CVS. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Jay Monkman - - * intr_NOTIMES.t: Real version submitted. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-08-01 Joel Sherrill - - * BSP_TIMES, wksheets.texi: Updated to reflect ARM times - reported by Jay Monkman . These - times are subject to change as he tunes the ARM port and their BSP. - -2002-07-30 Joel Sherrill - - * .cvsignore: Corrected by tailoring for the ARM. - -2002-07-30 Joel Sherrill - - * .cvsignore: New file. - -2002-07-30 Joel Sherrill - - * BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t, - cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, - preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, - wksheets.texi: New files as ARM supplement initial version added. - diff --git a/doc/supplements/arm/Makefile.am b/doc/supplements/arm/Makefile.am deleted file mode 100644 index 3a83e7184d..0000000000 --- a/doc/supplements/arm/Makefile.am +++ /dev/null @@ -1,110 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = arm -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ - timeBSP.texi -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = arm.texi -arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure - -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "MYBSP Timing Data" < $< > $@ - -# Timing Data for BSP BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t - cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t - @echo >>timeBSP_.t - @echo "@tex" >>timeBSP_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t - @echo "@end tex" >>timeBSP_.t - ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeBSP_.t - -EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeBSP.t - -CLEANFILES += arm.info diff --git a/doc/supplements/arm/arm.texi b/doc/supplements/arm/arm.texi deleted file mode 100644 index 32c3dcab18..0000000000 --- a/doc/supplements/arm/arm.texi +++ /dev/null @@ -1,115 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename arm.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the ARM Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS ARM Applications Supplement: (arm). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS ARM Applications Supplement - -@setchapternewpage odd -@settitle RTEMS ARM Applications Supplement -@titlepage -@finalout - -@title RTEMS ARM Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeBSP.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top arm - -This is the online version of the RTEMS ARM -Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* MYBSP Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/arm/bsp.t b/doc/supplements/arm/bsp.t deleted file mode 100644 index 657c359a96..0000000000 --- a/doc/supplements/arm/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of XXX specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the XXX processor is reset. When the -XXX is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 XXX's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 XXX version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the XXX remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -XXX from the interrupt state. - -@item 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. - -@item Must initialize the XXX's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/arm/callconv.t b/doc/supplements/arm/callconv.t deleted file mode 100644 index 167f5b8fa5..0000000000 --- a/doc/supplements/arm/callconv.t +++ /dev/null @@ -1,73 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Processor Background - -The ARM architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch and link (@code{bl}) instruction. This instruction -saves the return address in the @code{lr} register. Returning -from a subroutine only requires that the return address be -moved into the program counter (@code{pc}), possibly with -an offset. It is is important to -note that the @code{bl} instruction 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. - -@section Calling Mechanism - -All RTEMS directives are invoked using the @code{bl} -instruction and return to the user application via the -mechanism described above. - -@section Register Usage - -As discussed above, the ARM's call and return mechanism dos -not automatically save any registers. RTEMS uses the registers -@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and -per ARM calling convention, the @code{lr} register is altered -as well. These registers are not preserved by RTEMS directives -therefore, the contents of these registers should not be assumed -upon return from any RTEMS directive. - -@section Parameter Passing - -RTEMS assumes that ARM calling conventions are followed and that -the first four arguments are placed in registers @code{r0} through -@code{r3}. If there are more arguments, than that, then they -are place on the stack. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/arm/cpumodel.t b/doc/supplements/arm/cpumodel.t deleted file mode 100644 index af45d1a77b..0000000000 --- a/doc/supplements/arm/cpumodel.t +++ /dev/null @@ -1,82 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -ARM, SPARC, and PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across ARM implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro @code{CPU_MODEL_NAME} is a string which designates -the architectural level of this CPU model. The following is -a list of the settings for this string based upon @code{gcc} -CPU model predefines: - -@example -__ARM_ARCH4__ "ARMv4" -__ARM_ARCH4T__ "ARMv4T" -__ARM_ARCH5__ "ARMv5" -__ARM_ARCH5T__ "ARMv5T" -__ARM_ARCH5E__ "ARMv5E" -__ARM_ARCH5TE__ "ARMv5TE" -@end example - -@section Count Leading Zeroes Instruction - -The ARMv5 and later has the count leading zeroes (@code{clz}) -instruction which could be used to speed up the find first bit -operation. The use of this instruction should significantly speed up -the scheduling associated with a thread blocking. - -@section Floating Point Unit - -The macro ARM_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. - diff --git a/doc/supplements/arm/cputable.t b/doc/supplements/arm/cputable.t deleted file mode 100644 index 75d0fc15f6..0000000000 --- a/doc/supplements/arm/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The XXX version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the XXX. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - /* XXX CPU family dependent stuff */ -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item XXX -is where the CPU family dependent stuff goes. - -@end table diff --git a/doc/supplements/arm/fatalerr.t b/doc/supplements/arm/fatalerr.t deleted file mode 100644 index 8a703718ea..0000000000 --- a/doc/supplements/arm/fatalerr.t +++ /dev/null @@ -1,37 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is -no user handler configured or the user handler returns control to -RTEMS. The default fatal error handler performs the -following actions: - -@itemize @bullet -@item disables processor interrupts, -@item places the error code in @b{r0}, and -@item executes an infinite loop (@code{while(0);} to -simulate a halt processor instruction. -@end itemize - diff --git a/doc/supplements/arm/intr_NOTIMES.t b/doc/supplements/arm/intr_NOTIMES.t deleted file mode 100644 index f4c61fa448..0000000000 --- a/doc/supplements/arm/intr_NOTIMES.t +++ /dev/null @@ -1,122 +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 ARM's -interrupt response and control mechanisms as they pertain to -RTEMS. - -The ARM has 7 exception types: -@itemize @bullet - -@item Reset -@item Undefined instruction -@item Software interrupt (SWI) -@item Prefetch Abort -@item Data Abort -@item Interrupt (IRQ) -@item Fast Interrupt (FIQ) - -@end itemize - -Of these types, only IRQ and FIQ are handled through RTEMS's interrupt -vectoring. - -@section Vectoring of an Interrupt Handler - - -Unlike many other architectures, the ARM has seperate stacks for each -interrupt. When the CPU receives an interrupt, it: - -@itemize @bullet -@item switches to the exception mode corresponding to the interrupt, - -@item saves the Current Processor Status Register (CPSR) to the -exception mode's Saved Processor Status Register (SPSR), - -@item masks off the IRQ and if the interrupt source was FIQ, the FIQ -is masked off as well, - -@item saves the Program Counter (PC) to the exception mode's Link -Register (LR - same as R14), - -@item and sets the PC to the exception's vector address. - -@end itemize - -The vectors for both IRQ and FIQ point to the _ISR_Handler function. -_ISR_Handler() calls the BSP specific handler, ExecuteITHandler(). Before -calling ExecuteITHandler(), registers R0-R3, R12, and R14(LR) are saved so -that it is safe to call C functions. Even ExecuteITHandler() can be written -in C. - -@section Interrupt Levels - -The ARM architecture supports two external interrupts - IRQ and FIQ. FIQ -has a higher priority than IRQ, and has its own version of register R8 - R14, -however RTEMS does not take advantage of them. Both interrupts are enabled -through the CPSR. - -The RTEMS interrupt level mapping scheme for the AEM is not a numeric level -as on most RTEMS ports. It is a bit mapping that corresponds the enable -bits's postions in the CPSR: - -@table @b -@item FIQ -Setting bit 6 (0 is least significant bit) disables the FIQ. - -@item IRQ -Setting bit 7 (0 is least significant bit) disables the IRQ. - -@end table - - -@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 processor 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 expects the interrupt stacks to be set up in bsp_start(). The memory -for the stacks is reserved in the linker script. - diff --git a/doc/supplements/arm/memmodel.t b/doc/supplements/arm/memmodel.t deleted file mode 100644 index bf543364c7..0000000000 --- a/doc/supplements/arm/memmodel.t +++ /dev/null @@ -1,38 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -Members of the ARM family newer than Version 3 support 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 the endian -mode that the processor is configured for. In general, ARM -processors are used in little endian mode. - -Some of the ARM family members such as the -920 and 720 include an MMU and thus support virtual memory and -segmentation. RTEMS does not support virtual memory or -segmentation on any of the ARM family members. - diff --git a/doc/supplements/arm/preface.texi b/doc/supplements/arm/preface.texi deleted file mode 100644 index 27bb11a558..0000000000 --- a/doc/supplements/arm/preface.texi +++ /dev/null @@ -1,49 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the ARM architecture dependencies -in this port of RTEMS. The ARM family has a wide variety -of implementations by a wide range of vendors. Consequently, -there are 100's of CPU models within it. - -It is highly recommended that the ARM -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the ARM architecture as a whole. - -@subheading Architecture Documents - -For information on the ARM architecture, -refer to the following documents available from Arm, Limited -(@file{http//www.arm.com/}). There does not appear to -be an electronic version of a manual on the architecture -in general on that site. The following book is a good -resource: - -@itemize @bullet -@item @cite{David Seal. "ARM Architecture Reference Manual." -Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.} - -@end itemize - - diff --git a/doc/supplements/arm/timeBSP.t b/doc/supplements/arm/timeBSP.t deleted file mode 100644 index 742272f775..0000000000 --- a/doc/supplements/arm/timeBSP.t +++ /dev/null @@ -1,113 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter MYBSP Timing Data - -@section Introduction - -The timing data for the ARM version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the ARM version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with SDRAM and no numeric coprocessor. A -countdown timer on this board was used to measure -elapsed time with a 20 nanosecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the ARM microprocessor allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the ARM9DTMI microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by TBD to simulate a TBD Mhz processor. It -should be noted that the worst case instruction times -assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the processor to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor. -The interrupt vector and entry -overhead time was generated on an MYBSP benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the MYBSP benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -The ARM processor benchmarked does not have a floating point -unit and consequently no FPU results are reported. - -@c Since RTEMS was designed specifically for embedded -@c missile applications which are floating point intensive, the -@c executive is optimized to avoid unnecessarily saving and -@c restoring the state of the numeric coprocessor. The state of -@c the numeric coprocessor is only saved when an FLOATING_POINT -@c task is dispatched and that task was not the last task to -@c utilize the coprocessor. In a system with only one -@c FLOATING_POINT task, the state of the numeric coprocessor will -@c never be saved or restored. When the first FLOATING_POINT task -@c is dispatched, RTEMS does not need to save the current state of -@c the numeric coprocessor. - -@c The exact amount of time required to save and restore -@c floating point context is dependent on whether an XXX or -@c XXX is being used as well as the state of the numeric -@c coprocessor. These numeric coprocessors define three operating -@c states: initialized, idle, and busy. RTEMS places the -@c coprocessor in the initialized state when a task is started or -@c restarted. Once the task has utilized the coprocessor, it is in -@c the idle state when floating point instructions are not -@c executing and the busy state when floating point instructions -@c are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the MYBSP benchmark platform: - diff --git a/doc/supplements/c4x/.cvsignore b/doc/supplements/c4x/.cvsignore deleted file mode 100644 index 3585dc8094..0000000000 --- a/doc/supplements/c4x/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -c4x -c4x-? -c4x-?? -c4x.aux -c4x.cp -c4x.dvi -c4x.fn -c4x*.html -c4x.ky -c4x.log -c4x.pdf -c4x.pg -c4x.ps -c4x.toc -c4x.tp -c4x.vr -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -stamp-vti -timeBSP_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/c4x/BSP_TIMES b/doc/supplements/c4x/BSP_TIMES deleted file mode 100644 index c80ed37148..0000000000 --- a/doc/supplements/c4x/BSP_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# CPU MODEL/BSP Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP BSP_FOR_TIMES -RTEMS_CPU_MODEL BSP_CPU_MODEL -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 35 -RTEMS_RESTORE_1ST_FP_TASK 39 -RTEMS_SAVE_INIT_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_IDLE 68 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 148 -RTEMS_TASK_IDENT_ONLY 350 -RTEMS_TASK_START_ONLY 76 -RTEMS_TASK_RESTART_CALLING_TASK 95 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 -RTEMS_TASK_DELETE_CALLING_TASK 170 -RTEMS_TASK_DELETE_SUSPENDED_TASK 138 -RTEMS_TASK_DELETE_BLOCKED_TASK 143 -RTEMS_TASK_DELETE_READY_TASK 144 -RTEMS_TASK_SUSPEND_CALLING_TASK 71 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 -RTEMS_TASK_MODE_NO_RESCHEDULE 16 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 -RTEMS_TASK_GET_NOTE_ONLY 33 -RTEMS_TASK_SET_NOTE_ONLY 33 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 -RTEMS_TASK_WAKE_WHEN_ONLY 117 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 86 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 17 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 28 -RTEMS_TIMER_IDENT_ONLY 343 -RTEMS_TIMER_DELETE_INACTIVE 43 -RTEMS_TIMER_DELETE_ACTIVE 47 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 -RTEMS_TIMER_RESET_INACTIVE 54 -RTEMS_TIMER_RESET_ACTIVE 58 -RTEMS_TIMER_CANCEL_INACTIVE 31 -RTEMS_TIMER_CANCEL_ACTIVE 34 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 60 -RTEMS_SEMAPHORE_IDENT_ONLY 367 -RTEMS_SEMAPHORE_DELETE_ONLY 58 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 24 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 28 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 15 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 70 -RTEMS_PARTITION_IDENT_ONLY 341 -RTEMS_PARTITION_DELETE_ONLY 42 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 63 -RTEMS_REGION_IDENT_ONLY 348 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 35 -RTEMS_PORT_IDENT_ONLY 340 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 2 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 2 -RTEMS_IO_WRITE_ONLY 3 -RTEMS_IO_CONTROL_ONLY 2 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 723 -RTEMS_MINIMUM_CONFIGURATION 18,980 -RTEMS_MAXIMUM_CONFIGURATION 36,438 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 12,674 -RTEMS_INITIALIZATION_CODE_SIZE 970 -RTEMS_TASK_CODE_SIZE 3,562 -RTEMS_INTERRUPT_CODE_SIZE 54 -RTEMS_CLOCK_CODE_SIZE 334 -RTEMS_TIMER_CODE_SIZE 1,110 -RTEMS_SEMAPHORE_CODE_SIZE 1,632 -RTEMS_MESSAGE_CODE_SIZE 1,754 -RTEMS_EVENT_CODE_SIZE 1,000 -RTEMS_SIGNAL_CODE_SIZE 418 -RTEMS_PARTITION_CODE_SIZE 1,164 -RTEMS_REGION_CODE_SIZE 1,494 -RTEMS_DPMEM_CODE_SIZE 724 -RTEMS_IO_CODE_SIZE 686 -RTEMS_FATAL_ERROR_CODE_SIZE 24 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 -RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 184 -RTEMS_SEMAPHORE_CODE_OPTSIZE 172 -RTEMS_MESSAGE_CODE_OPTSIZE 288 -RTEMS_EVENT_CODE_OPTSIZE 56 -RTEMS_SIGNAL_CODE_OPTSIZE 56 -RTEMS_PARTITION_CODE_OPTSIZE 132 -RTEMS_REGION_CODE_OPTSIZE 160 -RTEMS_DPMEM_CODE_OPTSIZE 132 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 400 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 332 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/c4x/ChangeLog b/doc/supplements/c4x/ChangeLog deleted file mode 100644 index d18962cd77..0000000000 --- a/doc/supplements/c4x/ChangeLog +++ /dev/null @@ -1,49 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * c4x.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-28 Joel Sherrill - - * .cvsignore: New file. - -2003-01-25 Ralf Corsepius - - * c4x.texi: Set @setfilename c4x.info. - -2003-01-25 Ralf Corsepius - - * Makefile.am: New. - * c4x.texi, cpumodel.t, timeBSP.t: Various minor changes to get them - building. - -2003-01-24 Joel Sherrill - - * BSP_TIMES, bsp.t, c4x.texi, callconv.t, cpumodel.t, cputable.t, - fatalerr.t, intr_NOTIMES.t, memmodel.t, preface.texi, timeBSP.t: - New files. These should have been added long ago. - diff --git a/doc/supplements/c4x/Makefile.am b/doc/supplements/c4x/Makefile.am deleted file mode 100644 index 55f666f8f5..0000000000 --- a/doc/supplements/c4x/Makefile.am +++ /dev/null @@ -1,108 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = c4x -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timeBSP.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi - -FILES = preface.texi - -info_TEXINFOS = c4x.texi -c4x_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Large Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "BSP_FOR_TIMES Timing Data" < $< > $@ - -# Timing Data for BSP BSP_FOR_TIMES Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t - cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t - @echo >>timeBSP_.t - @echo "@tex" >>timeBSP_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t - @echo "@end tex" >>timeBSP_.t - ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeBSP_.t - -EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeBSP.t - -CLEANFILES += c4x.info c4x.info-? diff --git a/doc/supplements/c4x/bsp.t b/doc/supplements/c4x/bsp.t deleted file mode 100644 index a19aa06129..0000000000 --- a/doc/supplements/c4x/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of XXX specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the XXX processor is reset. When the -XXX is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 XXX's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 XXX version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the XXX remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -XXX from the interrupt state. - -@item 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. - -@item Must initialize the XXX's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/c4x/c4x.texi b/doc/supplements/c4x/c4x.texi deleted file mode 100644 index 49fa76fd34..0000000000 --- a/doc/supplements/c4x/c4x.texi +++ /dev/null @@ -1,116 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename c4x.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c @smallbook -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the TI C3x/C4x Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS TI C3x/C4x Applications Supplement: (c4x). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS TI C3x/C4x Applications Supplement - -@setchapternewpage odd -@settitle RTEMS TI C3x/C4x Applications Supplement -@titlepage -@finalout - -@title RTEMS TI C3x/C4x Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeBSP.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top c4x - -This is the online version of the RTEMS TI C3x/C4x -Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* BSP_FOR_TIMES Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/c4x/callconv.t b/doc/supplements/c4x/callconv.t deleted file mode 100644 index 94d52a05a3..0000000000 --- a/doc/supplements/c4x/callconv.t +++ /dev/null @@ -1,161 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -The GNU Compiler Suite follows the same calling conventions -as the Texas Instruments toolset. - -@section Processor Background - -The TI C3x and C4x processors support a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch to subroutine (@code{XXX}) or the jump to subroutine -(@code{XXX}) instructions. These instructions push the return address -on the current stack. The return from subroutine (@code{XXX}) -instruction pops the return address off the current stack and -transfers control to that instruction. It is important to -note that the call and return mechanism for the C3x/C4x 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. - -XXX other supplements may have "is is". - -@section Calling Mechanism - -All subroutines are invoked using either a @code{XXX} -or @code{XXX} instruction and return to the user application via the -@code{XXX} instruction. - -@section Register Usage - -XXX - -As discussed above, the @code{XXX} and @code{XXX} instructions do -not automatically save any registers. Subroutines use the registers -@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are -not preserved by subroutines therefore, the contents of -these registers should not be assumed upon return from any subroutine -call including but not limited to an RTEMS directive. - -The GNU and Texas Instruments compilers follow the same conventions -for register usage. - -@section Parameter Passing - -Both the GNU and Texas Instruments compilers support two conventions -for passing parameters to subroutines. Arguments may be passed in -memory on the stack or in registers. - -@subsection Parameters Passed in Memory - -When passing parameters on the stack, the calling convention assumes -that arguments are placed on the current stack before the subroutine -is invoked via the @code{XXX} 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 -subroutine with three (3) arguments: - -@example -@group -push third argument -push second argument -push first argument -invoke subroutine -remove arguments from the stack -@end group -@end example - -The arguments to RTEMS are typically pushed onto the -stack using a @code{sti} instruction with a pre-incremented 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 subtracting the size of the -argument list in words from the current stack pointer. - -@c XXX XXX instruction .. XXX should be code format. - -With the GNU Compiler Suite, parameter passing via the -stack is selected by invoking the compiler with the -@code{-mmemparm XXX} argument. This argument must be -included when linking the application in order to -ensure that support libraries also compiled assuming -parameter passing via the stack are used. The default -parameter passing mechanism is XXX. - -When this parameter passing mecahanism is selected, the @code{XXX} -symbol is predefined by the C and C++ compilers -and the @code{XXX} symbol is predefined by the assembler. -This behavior is the same for the GNU and Texas Instruments -toolsets. RTEMS uses these predefines to determine how -parameters are passed in to those C3x/C4x specific routines -that were written in assembly language. - -@subsection Parameters Passed in Registers - -When passing parameters via registers, the calling convention assumes -that the arguments are placed in particular registers based upon -their position and data type before the subroutine is invoked via -the @code{XXX} instruction. - -The following pseudo-code illustrates -the typical sequence used to call a subroutine with three (3) arguments: - -@example -@group -move third argument to XXX -move second argument to XXX -move first argument to XXX -invoke subroutine -@end group -@end example - -With the GNU Compiler Suite, parameter passing via -registers is selected by invoking the compiler with the -@code{-mregparm XXX} argument. This argument must be -included when linking the application in order to -ensure that support libraries also compiled assuming -parameter passing via the stack are used. The default -parameter passing mechanism is XXX. - -When this parameter passing mecahanism is selected, the @code{XXX} -symbol is predefined by the C and C++ compilers -and the @code{XXX} symbol is predefined by the assembler. -This behavior is the same for the GNU and Texas Instruments -toolsets. RTEMS uses these predefines to determine how -parameters are passed in to those C3x/C4x specific routines -that were written in assembly language. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/c4x/cpumodel.t b/doc/supplements/c4x/cpumodel.t deleted file mode 100644 index 079c6e15c7..0000000000 --- a/doc/supplements/c4x/cpumodel.t +++ /dev/null @@ -1,82 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across the various implementations of the C3x/C4x architecture -that are of importance to rtems. -the set of cpu model feature macros are defined in the file -cpukit/score/cpu/c4x/rtems/score/c4x.h and are based upon -the particular cpu model defined in the bsp's custom configuration -file as well as the compilation command line. - -@section CPU Model Name - -The macro @code{CPU_MODEL_NAME} is a string which designates -the name of this cpu model. for example, for the c32 -processor, this macro is set to the string "c32". - -@section Floating Point Unit - -The Texas Instruments C3x/C4x family makes little distinction -between the various cpu registers. Although floating point -operations may only be performed on a subset of the cpu registers, -these same registers may be used for normal integer operations. -as a result of this, this port of rtems makes no distinction -between integer and floating point contexts. The routine -@code{_CPU_Context_switch} saves all of the registers that -comprise a task's context. the routines that initialize, -save, and restore floating point contexts are not present -in this port. - -Moreover, there is no floating point context pointer and -the code in @code{_Thread_Dispatch} that manages the -floating point context switching process is disabled -on this port. - -This not only simplifies the port, it also speeds up context -switches by reducing the code involved and reduces the code -space footprint of the executive on the Texas Instruments -C3x/C4x. - diff --git a/doc/supplements/c4x/cputable.t b/doc/supplements/c4x/cputable.t deleted file mode 100644 index 1a9f1e50d9..0000000000 --- a/doc/supplements/c4x/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The XXX version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the XXX. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - /* XXX CPU family dependent stuff */ -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item XXX -is where the CPU family dependent stuff goes. - -@end table diff --git a/doc/supplements/c4x/fatalerr.t b/doc/supplements/c4x/fatalerr.t deleted file mode 100644 index 0871fa3cb9..0000000000 --- a/doc/supplements/c4x/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is -no user handler configured or the user handler returns control to -RTEMS. The default fatal error handler disables processor interrupts, -places the error code in @b{XXX}, and executes a @code{XXX} -instruction to simulate a halt processor instruction. - diff --git a/doc/supplements/c4x/intr_NOTIMES.t b/doc/supplements/c4x/intr_NOTIMES.t deleted file mode 100644 index 074420f2c9..0000000000 --- a/doc/supplements/c4x/intr_NOTIMES.t +++ /dev/null @@ -1,196 +0,0 @@ -@c -@c Interrupt Stack Frame Picture -@c -@c COPYRIGHT (c) 1988-1999. -@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 XXX'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 XXX family has two -different interrupt handling models. - -@subsection Models Without Separate Interrupt Stacks - -Upon receipt of an interrupt the XXX 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 XXX 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 -XXX 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 Interrupt Levels - -Eight levels (0-7) of interrupt priorities are -supported by XXX 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 -XXX family only supports eight. RTEMS interrupt levels 0 -through 7 directly correspond to XXX 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 XXX 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 XXX port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - diff --git a/doc/supplements/c4x/memmodel.t b/doc/supplements/c4x/memmodel.t deleted file mode 100644 index 0f6189ca26..0000000000 --- a/doc/supplements/c4x/memmodel.t +++ /dev/null @@ -1,160 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Byte Addressable versus Word Addressable - -Processor in the Texas Instruments C3x/C4x family are -word addressable. This is in sharp contrast to CISC and -RISC processors that are typically byte addressable. In a word -addressable architecture, each address points not to an -8-bit byte or octet but to 32 bits. - -On first glance, byte versus word addressability does not -sound like a problem but in fact, this issue can result in -subtle problems in high-level language software that is ported -to a word addressable processor family. The following is a -list of the commonly encountered problems: - -@table @b - -@item String Optimizations -Although each character in a string occupies a single address just -as it does on a byte addressable CPU, each character occupies -32 rather than 8 bits. The most significant 24 bytes are -of each address are ignored. This in and of itself does not -cause problems but it violates the assumption that two -adjacent characters in a string have no intervening bits. -This assumption is often implicit in string and memory comparison -routines that are optimized to compare 4 adjacent characters -with a word oriented operation. This optimization is -invalid on word addressable processors. - -@item Sizeof -The C operation @code{sizeof} returns very different results -on the C3x/C4x than on traditional RISC/CISC processors. -The @code{sizeof(char)}, @code{sizeof(short)}, and @code{sizeof(int)} -are all 1 since each occupies a single addressable unit that is -thirty-two bits wide. On most thirty-two bit processors, -@code{sizeof(char} is one, @code{sizeof(short)} is two, -and @code{sizeof(int)} is four. Just as software makes assumptions -about the sizes of the primitive data types has problems -when ported to a sixty-four bit architecture, these same -assumptions cause problems on the C3x/C4x. - -@item Alignment -Since each addressable unit is thirty-two bit wide, there -are no alignment restrictions. The native integer type -need only be aligned on a "one unit" boundary not a "four -unit" boundary as on numerous other processors. - -@end table - -@section Flat Memory Model - -XXX check actual bits on the various processor families. - -The XXX 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 this family. - -@section Compiler Memory Models - -The Texas Instruments C3x/C4x processors include a Data Page -(@code{dp}) register that logically is a base address. The -@code{dp} register allows the use of shorter offsets in -instructions. Up to 64K words may be addressed using -offsets from the @code{dp} register. In order to address -words not addressable based on the current value of -@code{dp}, the register must be loaded with a different -value. - -The @code{dp} register is managed automatically by -the high-level language compilers. -The various compilers for this processor family support -two memory models that manage the @code{dp} register -in very different manners. The large and small memory -models are discussed in the following sections. - -NOTE: The C3x/C4x port of RTEMS has been written -so that it should support either memory model. -However, it has only been tested using the -large memory model. - -@subsection Small Memory Model - -The small memory model is the simplest and most -efficient. However, it includes a limitation that -make it inappropriate for numerous applications. The -small memory model assumes that the application needs -to access no more than 64K words. Thus the @code{dp} -register can be loaded at application start time -and never reloaded. Thus the compiler will not -even generate instructions to load the @code{dp}. - -This can significantly reduce the code space -required by an application but the application -is limited in the amount of data it can access. - -With the GNU Compiler Suite, small memory model is -selected by invoking the compiler with either the -@code{-msmall} or @code{-msmallmemoryXXX} argument. -This argument must be included when linking the application -in order to ensure that support libraries also compiled -for the large memory model are used. -The default memory model is XXX. - -When this memory model is selected, the @code{XXX} -symbol is predefined by the C and C++ compilers -and the @code{XXX} symbol is predefined by the assembler. -This behavior is the same for the GNU and Texas Instruments -toolsets. RTEMS uses these predefines to determine the proper handling -of the @code{dp} register in those C3x/C4x specific routines -that were written in assembly language. - -@subsection Large Memory Model - -The large memory model is more complex and less efficient -than the small memory model. However, it removes the -64K uninitialized data restriction from applications. -The @code{dp} register is reloaded automatically -by the compiler each time data is accessed. This leads -to an increase in the code space requirements for the -application but gives it access to much more data space. - -With the GNU Compiler Suite, large memory model is -selected by invoking the compiler with either the -@code{-mlarge} or @code{-mlargememoryXXX} argument. -This argument must be included when linking the application -in order to ensure that support libraries also compiled -for the large memory model are used. -The default memory model is XXX. - -When this memory model is selected, the @code{XXX} -symbol is predefined by the C and C++ compilers -and the @code{XXX} symbol is predefined by the assembler. -This behavior is the same for the GNU and Texas Instruments -toolsets. RTEMS uses these predefines to determine the proper handling -of the @code{dp} register in those C3x/C4x specific routines -that were written in assembly language. diff --git a/doc/supplements/c4x/preface.texi b/doc/supplements/c4x/preface.texi deleted file mode 100644 index c0eecf3ff6..0000000000 --- a/doc/supplements/c4x/preface.texi +++ /dev/null @@ -1,64 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the Texas Instrument C3x/C4x -architecture dependencies in this port of RTEMS. The C3x/C4x -family has a wide variety of CPU models within it. The following -CPU model numbers could be supported by this port: - -@itemize -@item C30 - TMSXXX -@item C31 - TMSXXX -@item C32 - TMSXXX -@item C41 - TMSXXX -@item C44 - TMSXXX -@end itemize - -Initiially, this port does not include full support for C4x models. -Primarily, the C4x specific implementations of interrupt flag and -mask management routines have not been completed. - -It is highly recommended that the RTEMS application developer obtain -and become familiar with the documentation for the processor being -used as well as the documentation for the family as a whole. - -@subheading Architecture Documents - -For information on the Texas Instruments C3x/C4x architecture, -refer to the following documents available from VENDOR -(@file{http//www.ti.com/}): - -@itemize @bullet -@item @cite{XXX Family Reference, Texas Instruments, PART NUMBER}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet -@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. -@item @cite{XXX MODEL Manual, Texas Instruments, PART NUMBER}. -@end itemize - diff --git a/doc/supplements/c4x/timeBSP.t b/doc/supplements/c4x/timeBSP.t deleted file mode 100644 index a64dc93ca9..0000000000 --- a/doc/supplements/c4x/timeBSP.t +++ /dev/null @@ -1,108 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-1999. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter BSP_FOR_TIMES Timing Data - -@section Introduction - -The timing data for the XXX version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the XXX version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a 20Mhz board with one wait -state dynamic memory and a XXX numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the XXX allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the XXX microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a 20Mhz XXX. It -should be noted that the worst case instruction times for the -XXX assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the XXX to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at 20Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a 20Mhz XXX. The interrupt vector and entry -overhead time was generated on an BSP_FOR_TIMES benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the BSP_FOR_TIMES benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on whether an XXX or -XXX is being used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the BSP_FOR_TIMES benchmark platform: - diff --git a/doc/supplements/i386/.cvsignore b/doc/supplements/i386/.cvsignore deleted file mode 100644 index 0a0639e981..0000000000 --- a/doc/supplements/i386/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -i386 -i386-? -i386-?? -i386.aux -i386.cp -i386.dvi -i386.fn -i386*.html -i386.ky -i386.log -i386.pdf -i386.pg -i386.ps -i386.toc -i386.tp -i386.vr -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -stamp-vti -timeFORCE386_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/i386/ChangeLog b/doc/supplements/i386/ChangeLog deleted file mode 100644 index 438b5fe127..0000000000 --- a/doc/supplements/i386/ChangeLog +++ /dev/null @@ -1,72 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * i386.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * i386.texi: Set @setfilename i386.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/i386/FORCE386_TIMES b/doc/supplements/i386/FORCE386_TIMES deleted file mode 100644 index b40f8ad50b..0000000000 --- a/doc/supplements/i386/FORCE386_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# Intel i386/Force CPU-386 Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP CPU386 -RTEMS_CPU_MODEL i386 -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD 13.0 -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 16 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.1.0 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 34 -RTEMS_RESTORE_1ST_FP_TASK 57 -RTEMS_SAVE_INIT_RESTORE_INIT 59 -RTEMS_SAVE_IDLE_RESTORE_INIT 59 -RTEMS_SAVE_IDLE_RESTORE_IDLE 83 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 157 -RTEMS_TASK_IDENT_ONLY 748 -RTEMS_TASK_START_ONLY 86 -RTEMS_TASK_RESTART_CALLING_TASK 118 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 138 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 105 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 162 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 156 -RTEMS_TASK_DELETE_CALLING_TASK 187 -RTEMS_TASK_DELETE_SUSPENDED_TASK 147 -RTEMS_TASK_DELETE_BLOCKED_TASK 153 -RTEMS_TASK_DELETE_READY_TASK 157 -RTEMS_TASK_SUSPEND_CALLING_TASK 81 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 46 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 71 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 30 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 67 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 115 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 19 -RTEMS_TASK_MODE_NO_RESCHEDULE 21 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 27 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 66 -RTEMS_TASK_GET_NOTE_ONLY 32 -RTEMS_TASK_SET_NOTE_ONLY 32 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 18 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 63 -RTEMS_TASK_WAKE_WHEN_ONLY 128 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 13 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 12 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED 10 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 13 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 58 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 85 -RTEMS_CLOCK_GET_ONLY 2 -RTEMS_CLOCK_TICK_ONLY 16 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 34 -RTEMS_TIMER_IDENT_ONLY 729 -RTEMS_TIMER_DELETE_INACTIVE 48 -RTEMS_TIMER_DELETE_ACTIVE 52 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 65 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 69 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 92 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 92 -RTEMS_TIMER_RESET_INACTIVE 58 -RTEMS_TIMER_RESET_ACTIVE 63 -RTEMS_TIMER_CANCEL_INACTIVE 32 -RTEMS_TIMER_CANCEL_ACTIVE 37 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 64 -RTEMS_SEMAPHORE_IDENT_ONLY 787 -RTEMS_SEMAPHORE_DELETE_ONLY 60 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 41 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 40 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 47 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 70 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 95 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 294 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 730 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 81 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 117 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 118 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 144 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 117 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 116 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 144 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 122 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 146 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 93 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 45 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 127 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 41 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 26 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 89 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS <1 -RTEMS_EVENT_RECEIVE_AVAILABLE 27 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 25 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 94 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 13 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 34 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 59 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 39 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 60 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 83 -RTEMS_PARTITION_IDENT_ONLY 730 -RTEMS_PARTITION_DELETE_ONLY 40 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 34 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 40 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 68 -RTEMS_REGION_IDENT_ONLY 739 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 45 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 127 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 52 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 113 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 138 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 39 -RTEMS_PORT_IDENT_ONLY 728 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 26 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 1 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY <1 -RTEMS_IO_WRITE_ONLY 1 -RTEMS_IO_CONTROL_ONLY 1 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 36 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 725 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 53 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 49 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 53 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 82 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 30 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 833 -RTEMS_MINIMUM_CONFIGURATION 22,660 -RTEMS_MAXIMUM_CONFIGURATION 39,592 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 16,948 -RTEMS_INITIALIZATION_CODE_SIZE 916 -RTEMS_TASK_CODE_SIZE 3,436 -RTEMS_INTERRUPT_CODE_SIZE 52 -RTEMS_CLOCK_CODE_SIZE 296 -RTEMS_TIMER_CODE_SIZE 1,084 -RTEMS_SEMAPHORE_CODE_SIZE 1,500 -RTEMS_MESSAGE_CODE_SIZE 1,596 -RTEMS_EVENT_CODE_SIZE 1,036 -RTEMS_SIGNAL_CODE_SIZE 396 -RTEMS_PARTITION_CODE_SIZE 1,052 -RTEMS_REGION_CODE_SIZE 1,392 -RTEMS_DPMEM_CODE_SIZE 664 -RTEMS_IO_CODE_SIZE 676 -RTEMS_FATAL_ERROR_CODE_SIZE 20 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,132 -RTEMS_MULTIPROCESSING_CODE_SIZE 6,840 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 144 -RTEMS_SEMAPHORE_CODE_OPTSIZE 136 -RTEMS_MESSAGE_CODE_OPTSIZE 224 -RTEMS_EVENT_CODE_OPTSIZE 44 -RTEMS_SIGNAL_CODE_OPTSIZE 44 -RTEMS_PARTITION_CODE_OPTSIZE 104 -RTEMS_REGION_CODE_OPTSIZE 124 -RTEMS_DPMEM_CODE_OPTSIZE 104 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 136 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 228 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 372 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 108 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 6,768 diff --git a/doc/supplements/i386/Makefile.am b/doc/supplements/i386/Makefile.am deleted file mode 100644 index a8a27d839b..0000000000 --- a/doc/supplements/i386/Makefile.am +++ /dev/null @@ -1,111 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = i386 -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timeFORCE386.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = i386.texi -i386_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure - -intr.texi: intr_NOTIMES.t FORCE386_TIMES - ${REPLACE2} -p $(srcdir)/FORCE386_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t FORCE386_TIMES - ${REPLACE2} -p $(srcdir)/FORCE386_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "CPU386 Timing Data" < $< > $@ - -# Timing Data for BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeFORCE386.texi: $(top_srcdir)/common/timetbl.t timeFORCE386.t - cat $(srcdir)/timeFORCE386.t $(top_srcdir)/common/timetbl.t >timeFORCE386_.t - @echo >>timeFORCE386_.t - @echo "@tex" >>timeFORCE386_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeFORCE386_.t - @echo "@end tex" >>timeFORCE386_.t - ${REPLACE2} -p $(srcdir)/FORCE386_TIMES timeFORCE386_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeFORCE386_.t - -EXTRA_DIST = FORCE386_TIMES bsp.t callconv.t cpumodel.t cputable.t \ - fatalerr.t intr_NOTIMES.t memmodel.t timeFORCE386.t - -CLEANFILES += i386.info i386.info-? diff --git a/doc/supplements/i386/bsp.t b/doc/supplements/i386/bsp.t deleted file mode 100644 index 9ac99901f1..0000000000 --- a/doc/supplements/i386/bsp.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed to support a -particular processor and target board combination. This chapter presents a -discussion of i386 specific BSP issues. For more information on developing -a BSP, refer to the chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated when the i386 -processor is reset. When the i386 is reset, - -@itemize @bullet - -@item The EAX register is set to indicate the results of the processor's -power-up self test. If the self-test was not executed, the contents of -this register are undefined. Otherwise, a non-zero value indicates the -processor is faulty and a zero value indicates a successful self-test. - -@item The DX register holds a component identifier and revision level. DH -contains 3 to indicate an i386 component and DL contains a unique revision -level indicator. - -@item Control register zero (CR0) is set such that the processor is in real -mode with paging disabled. Other portions of CR0 are used to indicate the -presence of a numeric coprocessor. - -@item All bits in the extended flags register (EFLAG) which are not -permanently set are cleared. This inhibits all maskable interrupts. - -@item The Interrupt Descriptor Register (IDTR) is set to point at address -zero. - -@item All segment registers are set to zero. - -@item The instruction pointer is set to 0x0000FFF0. The first instruction -executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts -the upper twelve address until the first intersegment (FAR) JMP or CALL -instruction. When a JMP or CALL is executed, the upper twelve address -lines are lowered and the processor begins executing in the first megabyte -of memory. - -@end itemize - -Typically, an intersegment JMP to the application's initialization code is -placed at address 0xFFFFFFF0. - -@section Processor Initialization - -This initialization code is responsible for initializing all data -structures required by the i386 in protected mode and for actually entering -protected mode. The i386 must be placed in protected mode and the segment -registers and associated selectors must be initialized before the -initialize_executive directive is invoked. - -The initialization code is responsible for initializing the Global -Descriptor Table such that the i386 is in the thirty-two bit flat memory -model with paging disabled. In this mode, the i386 automatically converts -every address from a logical to a physical address each time it is used. -For more information on the memory model used by RTEMS, please refer to the -Memory Model chapter in this document. - -Since the processor is in real mode upon reset, the processor must be -switched to protected mode before RTEMS can execute. Before switching to -protected mode, at least one descriptor table and two descriptors must be -created. Descriptors are needed for a code segment and a data segment. ( -This will give you the flat memory model.) The stack can be placed in a -normal read/write data segment, so no descriptor for the stack is needed. -Before the GDT can be used, the base address and limit must be loaded into -the GDTR register using an LGDT instruction. - -If the hardware allows an NMI to be generated, you need to create the IDT -and a gate for the NMI interrupt handler. Before the IDT can be used, the -base address and limit for the idt must be loaded into the IDTR register -using an LIDT instruction. - -Protected mode is entered by setting thye PE bit in the CR0 register. -Either a LMSW or MOV CR0 instruction may be used to set this bit. Because -the processor overlaps the interpretation of several instructions, it is -necessary to discard the instructions from the read-ahead cache. A JMP -instruction immediately after the LMSW changes the flow and empties the -processor if intructions which have been pre-fetched and/or decoded. At -this point, the processor is in protected mode and begins to perform -protected mode application initialization. - -If the application requires that the IDTR be some value besides zero, then -it should set it to the required value at this point. All tasks share the -same i386 IDTR value. Because interrupts are enabled automatically by -RTEMS as part of the initialize_executive directive, the IDTR MUST be set -properly before this directive is invoked to insure correct interrupt -vectoring. If processor caching is to be utilized, then it should be -enabled during the reset application initialization code. The reset code -which is executed before the call to initialize_executive has the following -requirements: - -For more information regarding the i386s data structures and their -contents, refer to Intel's 386 Programmer's Reference Manual. - diff --git a/doc/supplements/i386/callconv.t b/doc/supplements/i386/callconv.t deleted file mode 100644 index f3e428dfad..0000000000 --- a/doc/supplements/i386/callconv.t +++ /dev/null @@ -1,90 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage - -@item parameter passing - -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Processor Background - -The i386 architecture supports a simple yet effective -call and return mechanism. A subroutine is invoked via the call -(call) instruction. This instruction pushes the return address -on the stack. The return from subroutine (ret) instruction pops -the return address off the current stack and transfers control -to that instruction. It is is important to note that the i386 -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. - -@section Calling Mechanism - -All RTEMS directives are invoked using a call -instruction and return to the user application via the ret -instruction. - -@section Register Usage - -As discussed above, the call instruction does not -automatically save any registers. RTEMS uses the registers EAX, -ECX, and EDX 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 -directive. - -@section Parameter Passing - -RTEMS assumes that arguments are placed on the -current stack before the directive is invoked via the call -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: - -@example -push third argument -push second argument -push first argument -invoke directive -remove arguments from the stack -@end example - -The arguments to RTEMS are typically pushed onto the -stack using a push instruction. 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 stack pointer. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/i386/cpumodel.t b/doc/supplements/i386/cpumodel.t deleted file mode 100644 index 30109f23a2..0000000000 --- a/doc/supplements/i386/cpumodel.t +++ /dev/null @@ -1,72 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across i386 implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/i386/i386.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the Intel i386 without an -i387 coprocessor, this macro is set to the string "i386 with i387". - -@section bswap Instruction - -The macro I386_HAS_BSWAP is set to 1 to indicate that -this CPU model has the @code{bswap} instruction which -endian swaps a thirty-two bit quantity. This instruction -appears to be present in all CPU models -i486's and above. - -@section Floating Point Unit - -The macro I386_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. The hardware floating point may be on-chip (as in the -case of an i486DX or Pentium) or as a coprocessor (as in the case of -an i386/i387 combination). diff --git a/doc/supplements/i386/cputable.t b/doc/supplements/i386/cputable.t deleted file mode 100644 index e7dbf045aa..0000000000 --- a/doc/supplements/i386/cputable.t +++ /dev/null @@ -1,119 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The i386 version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the i386. This information -is provided to allow RTEMS to interoperate effectively with the -BSP. The C structure definition is given here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - unsigned32 interrupt_segment; - void *interrupt_vector_table; -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item interrupt_segment -is the value of the selector which should be placed in a segment -register to access the Interrupt Descriptor Table. - -@item interrupt_vector_table -is the base address of the Interrupt Descriptor Table relative to the -interrupt_segment. - -@end table - -The contents of the i386 Interrupt Descriptor Table -are discussed in Intel's i386 User's Manual. Structure -definitions for the i386 IDT is provided by including the file -rtems.h. - diff --git a/doc/supplements/i386/fatalerr.t b/doc/supplements/i386/fatalerr.t deleted file mode 100644 index add48ab643..0000000000 --- a/doc/supplements/i386/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts, -places the error code in EAX, and executes a HLT instruction to -halt the processor. - diff --git a/doc/supplements/i386/i386.texi b/doc/supplements/i386/i386.texi deleted file mode 100644 index 23c92718bc..0000000000 --- a/doc/supplements/i386/i386.texi +++ /dev/null @@ -1,114 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename i386.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the Intel i386 Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS Intel i386 Applications Supplement: (i386). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS Intel i386 Applications Supplement - -@setchapternewpage odd -@settitle RTEMS Intel i386 Applications Supplement -@titlepage -@finalout - -@title RTEMS Intel i386 Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeFORCE386.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top i386 - -This is the online version of the RTEMS Intel i386 -Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* CPU386 Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, CPU386 Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/i386/intr_NOTIMES.t b/doc/supplements/i386/intr_NOTIMES.t deleted file mode 100644 index 1db03127ec..0000000000 --- a/doc/supplements/i386/intr_NOTIMES.t +++ /dev/null @@ -1,168 +0,0 @@ -@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 their own unique fashion. In -addition, each processor type provides a control mechanism to -allow the proper handling of an interrupt. The processor -dependent response to the interrupt modifies the execution state -and results in the modification of the execution stream. This -modification usually requires that an interrupt handler utilize -the provided 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 the processor's response and control mechanisms as they -pertain to RTEMS. - -@section Vectoring of Interrupt Handler - -Although the i386 supports multiple privilege levels, -RTEMS and all user software executes at privilege level 0. This -decision was made by the RTEMS designers to enhance -compatibility with processors which do not provide sophisticated -protection facilities like those of the i386. This decision -greatly simplifies the discussion of i386 processing, as one -need only consider interrupts without privilege transitions. - -Upon receipt of an interrupt the i386 automatically -performs the following actions: - -@itemize @bullet -@item pushes the EFLAGS register - -@item pushes the far address of the interrupted instruction - -@item vectors to the interrupt service routine (ISR). -@end itemize - -A nested interrupt is processed similarly by the -i386. - -@section Interrupt Stack Frame - -The structure of the Interrupt Stack Frame for the -i386 which is placed on the interrupt stack by the processor in -response to an interrupt is as follows: - -@ifset use-ascii -@example -@group - +----------------------+ - | Old EFLAGS Register | ESP+8 - +----------+-----------+ - | UNUSED | Old CS | ESP+4 - +----------+-----------+ - | Old EIP | ESP - +----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\strut\vrule#& -\hbox to 1.00in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.00in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 0.75in{\enskip\hfil#\hfil} -\cr -\multispan{4}\hrulefill\cr -& \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr -\multispan{4}\hrulefill\cr -&UNUSED &&Old CS &&ESP+4\cr -\multispan{4}\hrulefill\cr -& \multispan{3} Old EIP && ESP\cr -\multispan{4}\hrulefill\cr -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - -
Old EFLAGS Register0x0
UNUSEDOld CS0x2
Old EIP0x4
-
-@end html -@end ifset - -@section Interrupt Levels - -Although RTEMS supports 256 interrupt levels, the -i386 only supports two -- enabled and disabled. Interrupts are -enabled when the interrupt-enable flag (IF) in the extended -flags (EFLAGS) is set. Conversely, interrupt processing is -inhibited when the IF is cleared. During a non-maskable -interrupt, all other interrupts, including other non-maskable -ones, are inhibited. - -RTEMS interrupt levels 0 and 1 such that level zero -(0) indicates that interrupts are fully enabled and level one -that interrupts are disabled. 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 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 i386 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 within RTEMS was last calculated 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 - -The i386 family does not support a dedicated hardware -interrupt stack. On this processor, RTEMS allocates and manages -a dedicated interrupt stack. As part of vectoring a non-nested -interrupt service routine, RTEMS switches from the stack of the -interrupted task to a dedicated interrupt stack. When a -non-nested interrupt returns, RTEMS switches back to the stack -of the interrupted stack. The current stack pointer is not -altered by RTEMS on nested interrupt. - -Without a dedicated interrupt stack, every task in -the system MUST have enough stack space to accommodate the worst -case stack usage of that particular task and the interrupt -service routines COMBINED. By supporting a dedicated interrupt -stack, RTEMS significantly lowers the stack requirements for -each task. - -RTEMS allocates the dedicated 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. - diff --git a/doc/supplements/i386/memmodel.t b/doc/supplements/i386/memmodel.t deleted file mode 100644 index 4ed5c53b7c..0000000000 --- a/doc/supplements/i386/memmodel.t +++ /dev/null @@ -1,72 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -RTEMS supports the i386 protected mode, flat memory -model with paging disabled. In this mode, the i386 -automatically converts every address from a logical to a -physical address each time it is used. The i386 uses -information provided in the segment registers and the Global -Descriptor Table to convert these addresses. RTEMS assumes the -existence of the following segments: - -@itemize @bullet -@item a single code segment at protection level (0) which -contains all application and executive code. - -@item a single data segment at protection level zero (0) which -contains all application and executive data. -@end itemize - -The i386 segment registers and associated selectors -must be initialized when the initialize_executive directive is -invoked. RTEMS treats the segment registers as system registers -and does not modify or context switch them. - -This i386 memory model 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, half-word (2-bytes), or word (4 bytes). - -RTEMS does not require that logical addresses map -directly to physical addresses, although it is desirable in many -applications to do so. If logical and physical addresses are -not the same, then an additional selector will be required so -RTEMS can access the Interrupt Descriptor Table to install -interrupt service routines. The selector number of this segment -is provided to RTEMS in the CPU Dependent Information Table. - -By not requiring that logical addresses map directly -to physical addresses, the memory space of an RTEMS application -can be separated from that of a ROM monitor. For example, on -the Force Computers CPU386, the ROM monitor loads application -programs into a logical address space where logical address -0x00000000 corresponds to physical address 0x0002000. On this -board, RTEMS and the application use virtual addresses which do -not map to physical addresses. - -RTEMS assumes that the DS and ES registers contain -the selector for the single data segment when a directive is -invoked. This assumption is especially important when -developing interrupt service routines. - diff --git a/doc/supplements/i386/preface.texi b/doc/supplements/i386/preface.texi deleted file mode 100644 index b33c0671c6..0000000000 --- a/doc/supplements/i386/preface.texi +++ /dev/null @@ -1,41 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems -(RTEMS) is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -For information on the i386 processor, refer to the -following documents: - -@itemize @bullet -@item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}. - -@item @cite{386 Microprocessor Hardware Reference Manual, Intel, -Order No. 231732-003}. - -@item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}. - -@item @cite{80387 Programmer's Reference Manual, Intel, Order No. 231917-001}. -@end itemize - -It is highly recommended that the i386 RTEMS -application developer obtain and become familiar with Intel's -386 Programmer's Reference Manual. - diff --git a/doc/supplements/i386/timeFORCE386.t b/doc/supplements/i386/timeFORCE386.t deleted file mode 100644 index 56f01ae855..0000000000 --- a/doc/supplements/i386/timeFORCE386.t +++ /dev/null @@ -1,101 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter CPU386 Timing Data - -@section Introduction - -The timing data for the i386 version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context -switch times as they pertain to the i386 version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Force -Computers CPU386 board. The CPU386 is a 16 Mhz board with zero -wait state dynamic memory and an i80387 numeric coprocessor. -One of the count-down timers provided by a Motorola MC68901 was -used to measure elapsed time with one microsecond resolution. -All sources of hardware interrupts are disabled, although the -interrupt level of the i386 allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. Zero wait state memory was assumed. The total CPU -cycles executed with interrupts disabled, including the -instructions to disable and enable interrupts, was divided by 16 -to simulate a i386 executing at 16 Mhz. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD microseconds -including the instructions -which disable and re-enable interrupts. The time required for -the i386 to generate an interrupt using the int instruction, -vectoring to an interrupt handler, and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of 12 microseconds. These combine to yield a worst case -interrupt latency of less -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. [NOTE: The -maximum period with interrupts disabled within RTEMS was last -calculated for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed. The interrupt -vector and entry overhead time was generated on the Force -Computers CPU386 benchmark platform using the int instruction as -the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the Force Computers CPU386 benchmark platform. -This time represents the raw context switch time with no user -extensions configured. Additional execution time is required -when a TASK_SWITCH user extension is configured. The use of the -TASK_SWITCH extension is application dependent. Thus, its -execution time is not considered part of the base context switch -time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when a FLOATING_POINT task -is dispatched and that task was not the last task to utilize the -coprocessor. In a system with only one FLOATING_POINT task, the -state of the numeric coprocessor will never be saved or -restored. When the first FLOATING_POINT task is dispatched, -RTEMS does not need to save the current state of the numeric -coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on the state of the numeric -coprocessor. RTEMS places the coprocessor in the initialized -state when a task is started or restarted. Once the task has -utilized the coprocessor, it is in the idle state when floating -point instructions are not executing and the busy state when -floating point instructions are executing. The state of the -coprocessor is task specific. - -The following table summarizes the context switch -times for the Force Computers CPU386 benchmark platform: - diff --git a/doc/supplements/m68k/.cvsignore b/doc/supplements/m68k/.cvsignore deleted file mode 100644 index 9325d2bc53..0000000000 --- a/doc/supplements/m68k/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -m68k -m68k-? -m68k-?? -m68k.aux -m68k.cp -m68k.dvi -m68k.fn -m68k*.html -m68k.ky -m68k.log -m68k.pdf -m68k.pg -m68k.ps -m68k.toc -m68k.tp -m68k.vr -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -stamp-vti -timeMVME136_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/m68k/ChangeLog b/doc/supplements/m68k/ChangeLog deleted file mode 100644 index 5d5375e336..0000000000 --- a/doc/supplements/m68k/ChangeLog +++ /dev/null @@ -1,86 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * m68k.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * m68k.texi: Set @setfilename m68k.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-07-30 Joel Sherrill - - * timeMVME136.t, timedata.t: Replaced XXX's with real info. - -2002-07-26 Joel Sherrill - - * intr_NOTIMES.t: Per PR258, changed single @ to double @ in email - address to make texinfo happy. - -2002-06-28 Joel Sherrill - - * intr_NOTIMES.t: Per PR70 incorporate the posting by - Zoltan Kocsi explaining a m68k vectoring trick. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/m68k/MVME136_TIMES b/doc/supplements/m68k/MVME136_TIMES deleted file mode 100644 index 5b0dfe6fda..0000000000 --- a/doc/supplements/m68k/MVME136_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# M68020/MVME136 Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP MVME136 -RTEMS_CPU_MODEL MC68020 -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 3.2.1 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 35 -RTEMS_RESTORE_1ST_FP_TASK 39 -RTEMS_SAVE_INIT_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_IDLE 68 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 148 -RTEMS_TASK_IDENT_ONLY 350 -RTEMS_TASK_START_ONLY 76 -RTEMS_TASK_RESTART_CALLING_TASK 95 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 -RTEMS_TASK_DELETE_CALLING_TASK 170 -RTEMS_TASK_DELETE_SUSPENDED_TASK 138 -RTEMS_TASK_DELETE_BLOCKED_TASK 143 -RTEMS_TASK_DELETE_READY_TASK 144 -RTEMS_TASK_SUSPEND_CALLING_TASK 71 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 -RTEMS_TASK_MODE_NO_RESCHEDULE 16 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 -RTEMS_TASK_GET_NOTE_ONLY 33 -RTEMS_TASK_SET_NOTE_ONLY 33 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 -RTEMS_TASK_WAKE_WHEN_ONLY 117 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 86 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 17 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 28 -RTEMS_TIMER_IDENT_ONLY 343 -RTEMS_TIMER_DELETE_INACTIVE 43 -RTEMS_TIMER_DELETE_ACTIVE 47 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 -RTEMS_TIMER_RESET_INACTIVE 54 -RTEMS_TIMER_RESET_ACTIVE 58 -RTEMS_TIMER_CANCEL_INACTIVE 31 -RTEMS_TIMER_CANCEL_ACTIVE 34 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 60 -RTEMS_SEMAPHORE_IDENT_ONLY 367 -RTEMS_SEMAPHORE_DELETE_ONLY 58 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 24 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 28 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 15 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 70 -RTEMS_PARTITION_IDENT_ONLY 341 -RTEMS_PARTITION_DELETE_ONLY 42 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 63 -RTEMS_REGION_IDENT_ONLY 348 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 35 -RTEMS_PORT_IDENT_ONLY 340 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 2 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 2 -RTEMS_IO_WRITE_ONLY 3 -RTEMS_IO_CONTROL_ONLY 2 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 723 -RTEMS_MINIMUM_CONFIGURATION 18,980 -RTEMS_MAXIMUM_CONFIGURATION 36,438 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 12,674 -RTEMS_INITIALIZATION_CODE_SIZE 970 -RTEMS_TASK_CODE_SIZE 3,562 -RTEMS_INTERRUPT_CODE_SIZE 54 -RTEMS_CLOCK_CODE_SIZE 334 -RTEMS_TIMER_CODE_SIZE 1,110 -RTEMS_SEMAPHORE_CODE_SIZE 1,632 -RTEMS_MESSAGE_CODE_SIZE 1,754 -RTEMS_EVENT_CODE_SIZE 1,000 -RTEMS_SIGNAL_CODE_SIZE 418 -RTEMS_PARTITION_CODE_SIZE 1,164 -RTEMS_REGION_CODE_SIZE 1,494 -RTEMS_DPMEM_CODE_SIZE 724 -RTEMS_IO_CODE_SIZE 686 -RTEMS_FATAL_ERROR_CODE_SIZE 24 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 -RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 184 -RTEMS_SEMAPHORE_CODE_OPTSIZE 172 -RTEMS_MESSAGE_CODE_OPTSIZE 288 -RTEMS_EVENT_CODE_OPTSIZE 56 -RTEMS_SIGNAL_CODE_OPTSIZE 56 -RTEMS_PARTITION_CODE_OPTSIZE 132 -RTEMS_REGION_CODE_OPTSIZE 160 -RTEMS_DPMEM_CODE_OPTSIZE 132 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 400 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 332 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/m68k/Makefile.am b/doc/supplements/m68k/Makefile.am deleted file mode 100644 index 31752d1548..0000000000 --- a/doc/supplements/m68k/Makefile.am +++ /dev/null @@ -1,111 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = m68k -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timeMVME136.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = m68k.texi -m68k_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Extend Byte to Long Instruction" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t MVME136_TIMES - ${REPLACE2} -p $(srcdir)/MVME136_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t MVME136_TIMES - ${REPLACE2} -p $(srcdir)/MVME136_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure - -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "MVME136 Timing Data" < $< > $@ - -# Timing Data for BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeMVME136.texi: $(top_srcdir)/common/timetbl.t timeMVME136.t - cat $(srcdir)/timeMVME136.t $(top_srcdir)/common/timetbl.t >timeMVME136_.t - @echo >>timeMVME136_.t - @echo "@tex" >>timeMVME136_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeMVME136_.t - @echo "@end tex" >>timeMVME136_.t - ${REPLACE2} -p $(srcdir)/MVME136_TIMES timeMVME136_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeMVME136_.t - -EXTRA_DIST = MVME136_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeMVME136.t timedata.t - -CLEANFILES += m68k.info m68k.info-? diff --git a/doc/supplements/m68k/bsp.t b/doc/supplements/m68k/bsp.t deleted file mode 100644 index 3d245c7719..0000000000 --- a/doc/supplements/m68k/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of MC68020 specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the MC68020 processor is reset. When the -MC68020 is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the MC68020 remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -MC68020 from the interrupt state. - -@item 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. - -@item Must initialize the MC68020's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/m68k/callconv.t b/doc/supplements/m68k/callconv.t deleted file mode 100644 index e572fb4e64..0000000000 --- a/doc/supplements/m68k/callconv.t +++ /dev/null @@ -1,92 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Processor Background - -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. - -@section Calling Mechanism - -All RTEMS directives are invoked using either a bsr -or jsr instruction and return to the user application via the -rts instruction. - -@section Register Usage - -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 -directive. - -@section Parameter Passing - -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: - -@example -@group -push third argument -push second argument -push first argument -invoke directive -remove arguments from the stack -@end group -@end example - -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. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/m68k/cpumodel.t b/doc/supplements/m68k/cpumodel.t deleted file mode 100644 index 1566b322b5..0000000000 --- a/doc/supplements/m68k/cpumodel.t +++ /dev/null @@ -1,91 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/m68k/m68k.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the MC68020 -processor, this macro is set to the string "mc68020". - -@section Floating Point Unit - -The macro M68K_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. - -@section BFFFO Instruction - -The macro M68K_HAS_BFFFO is set to 1 to indicate that -this CPU model has the bfffo instruction. - -@section Vector Base Register - -The macro M68K_HAS_VBR is set to 1 to indicate that -this CPU model has a vector base register (vbr). - -@section Separate Stacks - -The macro M68K_HAS_SEPARATE_STACKS is set to 1 to -indicate that this CPU model has separate interrupt, user, and -supervisor mode stacks. - -@section 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. - -@section 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. diff --git a/doc/supplements/m68k/cputable.t b/doc/supplements/m68k/cputable.t deleted file mode 100644 index a70e89929f..0000000000 --- a/doc/supplements/m68k/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The MC68xxx version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the MC68xxx. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - m68k_isr *interrupt_vector_table; -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item interrupt_vector_table -is the base address of the CPU's Exception Vector Table. - -@end table diff --git a/doc/supplements/m68k/fatalerr.t b/doc/supplements/m68k/fatalerr.t deleted file mode 100644 index 728d149f37..0000000000 --- a/doc/supplements/m68k/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts to -level 7, places the error code in D0, and executes a stop -instruction to simulate a halt processor instruction. - 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. - - diff --git a/doc/supplements/m68k/m68k.texi b/doc/supplements/m68k/m68k.texi deleted file mode 100644 index b14c58e62f..0000000000 --- a/doc/supplements/m68k/m68k.texi +++ /dev/null @@ -1,115 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename m68k.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the Motorola MC68xxx Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS Motorola MC68xxx Applications Supplement: (m68k). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS Motorola MC68xxx Applications Supplement - -@setchapternewpage odd -@settitle RTEMS Motorola MC68xxx Applications Supplement -@titlepage -@finalout - -@title RTEMS Motorola MC68xxx Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeMVME136.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top m68k - -This is the online version of the RTEMS Motorola MC68xxx -Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* MVME136 Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, MVME136 Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/m68k/memmodel.t b/doc/supplements/m68k/memmodel.t deleted file mode 100644 index 7b7776050c..0000000000 --- a/doc/supplements/m68k/memmodel.t +++ /dev/null @@ -1,39 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -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 this family. - -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 family members. - diff --git a/doc/supplements/m68k/preface.texi b/doc/supplements/m68k/preface.texi deleted file mode 100644 index e37038f439..0000000000 --- a/doc/supplements/m68k/preface.texi +++ /dev/null @@ -1,60 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the Motorola MC68xxx -architecture dependencies in this port of RTEMS. The MC68xxx -family has a wide variety of CPU models within it. 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. - -It is highly recommended that the Motorola MC68xxx -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the family as a whole. - -@subheading Architecture Documents - -For information on the Motorola MC68xxx architecture, -refer to the following documents available from Motorola -(@file{http//www.moto.com/}): - -@itemize @bullet -@item @cite{M68000 Family Reference, Motorola, FR68K/D}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet -@item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}. - -@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's -Manual, Motorola, MC68881UM/AD}. -@end itemize - diff --git a/doc/supplements/m68k/timeMVME136.t b/doc/supplements/m68k/timeMVME136.t deleted file mode 100644 index 16933e8055..0000000000 --- a/doc/supplements/m68k/timeMVME136.t +++ /dev/null @@ -1,112 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter MVME136 Timing Data - -@section Introduction - -The timing data for the MC68020 version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the MC68020 version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -MVME135 CPU board. The MVME135 is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with one wait -state dynamic memory and a MC68881 numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the MC68020 allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the MC68020 microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz MC68020. It -should be noted that the worst case instruction times for the -MC68020 assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the MC68020 to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz MC68020. The interrupt vector and entry -overhead time was generated on an MVME135 benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the MVME135 benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on whether an MC68881 or -MC68882 is being used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the MVME135 benchmark platform: - diff --git a/doc/supplements/m68k/timedata.t b/doc/supplements/m68k/timedata.t deleted file mode 100644 index 72171445ab..0000000000 --- a/doc/supplements/m68k/timedata.t +++ /dev/null @@ -1,154 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@ifinfo -@node MVME136 Timing Data, MVME136 Timing Data Introduction, Timing Specification Terminology, Top -@end ifinfo -@chapter MVME136 Timing Data -@ifinfo -@menu -* MVME136 Timing Data Introduction:: -* MVME136 Timing Data Hardware Platform:: -* MVME136 Timing Data Interrupt Latency:: -* MVME136 Timing Data Context Switch:: -* MVME136 Timing Data Directive Times:: -* MVME136 Timing Data Task Manager:: -* MVME136 Timing Data Interrupt Manager:: -* MVME136 Timing Data Clock Manager:: -* MVME136 Timing Data Timer Manager:: -* MVME136 Timing Data Semaphore Manager:: -* MVME136 Timing Data Message Manager:: -* MVME136 Timing Data Event Manager:: -* MVME136 Timing Data Signal Manager:: -* MVME136 Timing Data Partition Manager:: -* MVME136 Timing Data Region Manager:: -* MVME136 Timing Data Dual-Ported Memory Manager:: -* MVME136 Timing Data I/O Manager:: -* MVME136 Timing Data Rate Monotonic Manager:: -@end menu -@end ifinfo - -@ifinfo -@node MVME136 Timing Data Introduction, MVME136 Timing Data Hardware Platform, MVME136 Timing Data, MVME136 Timing Data -@end ifinfo -@section Introduction - -The timing data for the MC68020 version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the MC68020 version of RTEMS. - -@ifinfo -@node MVME136 Timing Data Hardware Platform, MVME136 Timing Data Interrupt Latency, MVME136 Timing Data Introduction, MVME136 Timing Data -@end ifinfo -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -MVME135 CPU board. The MVME135 is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with one wait -state dynamic memory and a MC68881 numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the MC68020 allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the MC68020 microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz MC68020. It -should be noted that the worst case instruction times for the -MC68020 assume that the internal cache is disabled and that no -instructions overlap. - -@ifinfo -@node MVME136 Timing Data Interrupt Latency, MVME136 Timing Data Context Switch, MVME136 Timing Data Hardware Platform, MVME136 Timing Data -@end ifinfo -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the MC68020 to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz MC68020. The interrupt vector and entry -overhead time was generated on an MVME135 benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@ifinfo -@node MVME136 Timing Data Context Switch, MVME136 Timing Data Directive Times, MVME136 Timing Data Interrupt Latency, MVME136 Timing Data -@end ifinfo -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the MVME135 benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on whether an MC68881 or -MC68882 is being used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the MVME135 benchmark platform: - -@include timetbl.texi - -@tex -\global\advance \smallskipamount by 4pt -@end tex diff --git a/doc/supplements/mips/.cvsignore b/doc/supplements/mips/.cvsignore deleted file mode 100644 index 9ab9e0fec7..0000000000 --- a/doc/supplements/mips/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -mips -mips-? -mips-?? -mips.aux -mips.cp -mips.dvi -mips.fn -mips*.html -mips.ky -mips.log -mips.pdf -mips.pg -mips.ps -mips.toc -mips.tp -mips.vr -rtems_footer.html -rtems_header.html -stamp-vti -timeBSP_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/mips/BSP_TIMES b/doc/supplements/mips/BSP_TIMES deleted file mode 100644 index 82b8160aa5..0000000000 --- a/doc/supplements/mips/BSP_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# CPU MODEL/BSP Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP BSPFORTIMES -RTEMS_CPU_MODEL BSP_CPU_MODEL -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 35 -RTEMS_RESTORE_1ST_FP_TASK 39 -RTEMS_SAVE_INIT_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_IDLE 68 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 148 -RTEMS_TASK_IDENT_ONLY 350 -RTEMS_TASK_START_ONLY 76 -RTEMS_TASK_RESTART_CALLING_TASK 95 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 -RTEMS_TASK_DELETE_CALLING_TASK 170 -RTEMS_TASK_DELETE_SUSPENDED_TASK 138 -RTEMS_TASK_DELETE_BLOCKED_TASK 143 -RTEMS_TASK_DELETE_READY_TASK 144 -RTEMS_TASK_SUSPEND_CALLING_TASK 71 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 -RTEMS_TASK_MODE_NO_RESCHEDULE 16 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 -RTEMS_TASK_GET_NOTE_ONLY 33 -RTEMS_TASK_SET_NOTE_ONLY 33 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 -RTEMS_TASK_WAKE_WHEN_ONLY 117 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 86 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 17 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 28 -RTEMS_TIMER_IDENT_ONLY 343 -RTEMS_TIMER_DELETE_INACTIVE 43 -RTEMS_TIMER_DELETE_ACTIVE 47 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 -RTEMS_TIMER_RESET_INACTIVE 54 -RTEMS_TIMER_RESET_ACTIVE 58 -RTEMS_TIMER_CANCEL_INACTIVE 31 -RTEMS_TIMER_CANCEL_ACTIVE 34 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 60 -RTEMS_SEMAPHORE_IDENT_ONLY 367 -RTEMS_SEMAPHORE_DELETE_ONLY 58 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 24 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 28 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 15 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 70 -RTEMS_PARTITION_IDENT_ONLY 341 -RTEMS_PARTITION_DELETE_ONLY 42 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 63 -RTEMS_REGION_IDENT_ONLY 348 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 35 -RTEMS_PORT_IDENT_ONLY 340 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 2 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 2 -RTEMS_IO_WRITE_ONLY 3 -RTEMS_IO_CONTROL_ONLY 2 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 723 -RTEMS_MINIMUM_CONFIGURATION 18,980 -RTEMS_MAXIMUM_CONFIGURATION 36,438 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 12,674 -RTEMS_INITIALIZATION_CODE_SIZE 970 -RTEMS_TASK_CODE_SIZE 3,562 -RTEMS_INTERRUPT_CODE_SIZE 54 -RTEMS_CLOCK_CODE_SIZE 334 -RTEMS_TIMER_CODE_SIZE 1,110 -RTEMS_SEMAPHORE_CODE_SIZE 1,632 -RTEMS_MESSAGE_CODE_SIZE 1,754 -RTEMS_EVENT_CODE_SIZE 1,000 -RTEMS_SIGNAL_CODE_SIZE 418 -RTEMS_PARTITION_CODE_SIZE 1,164 -RTEMS_REGION_CODE_SIZE 1,494 -RTEMS_DPMEM_CODE_SIZE 724 -RTEMS_IO_CODE_SIZE 686 -RTEMS_FATAL_ERROR_CODE_SIZE 24 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 -RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 184 -RTEMS_SEMAPHORE_CODE_OPTSIZE 172 -RTEMS_MESSAGE_CODE_OPTSIZE 288 -RTEMS_EVENT_CODE_OPTSIZE 56 -RTEMS_SIGNAL_CODE_OPTSIZE 56 -RTEMS_PARTITION_CODE_OPTSIZE 132 -RTEMS_REGION_CODE_OPTSIZE 160 -RTEMS_DPMEM_CODE_OPTSIZE 132 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 400 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 332 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/mips/ChangeLog b/doc/supplements/mips/ChangeLog deleted file mode 100644 index 1b34f35c37..0000000000 --- a/doc/supplements/mips/ChangeLog +++ /dev/null @@ -1,76 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * mips.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * mips.texi: Set @setfilename mips.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-07-30 Joel Sherrill - - * .cvsignore: Corrected some errors. - * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2001-03-01 Joel Sherrill - - * .cvsignore: New file. - -2002-02-04 Joel Sherrill - - * bsp.t, BSP_TIMES, callconv.t, ChangeLog, cpumodel.t, cputable.t, - fatalerr.t, intr_NOTIMES.t, Makefile.am, memmodel.t, mips.texi, - preface.texi, stamp-vti, timeBSP.t, version.texi: New files. - diff --git a/doc/supplements/mips/Makefile.am b/doc/supplements/mips/Makefile.am deleted file mode 100644 index e45ba428fa..0000000000 --- a/doc/supplements/mips/Makefile.am +++ /dev/null @@ -1,111 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = mips -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ - timeBSP.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = mips.texi -mips_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure - -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "BSP_FOR_TIMES Timing Data" < $< > $@ - -# Timing Data for BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t - cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t - @echo >>timeBSP_.t - @echo "@tex" >>timeBSP_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t - @echo "@end tex" >>timeBSP_.t - ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeBSP_.t - -EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeBSP.t - -CLEANFILES += mips.info mips.info-? diff --git a/doc/supplements/mips/bsp.t b/doc/supplements/mips/bsp.t deleted file mode 100644 index 657c359a96..0000000000 --- a/doc/supplements/mips/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of XXX specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the XXX processor is reset. When the -XXX is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 XXX's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 XXX version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the XXX remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -XXX from the interrupt state. - -@item 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. - -@item Must initialize the XXX's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/mips/callconv.t b/doc/supplements/mips/callconv.t deleted file mode 100644 index 5387032c60..0000000000 --- a/doc/supplements/mips/callconv.t +++ /dev/null @@ -1,92 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Processor Background - -The MC68xxx architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch to subroutine (@code{XXX}) or the jump to subroutine -(@code{XXX}) instructions. These instructions push the return address -on the current stack. The return from subroutine (@code{XXX}) -instruction pops the return address off the current stack and -transfers control to that instruction. It is is important to -note that the XXX 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. - -@section Calling Mechanism - -All RTEMS directives are invoked using either a @code{XXX} -or @code{XXX} instruction and return to the user application via the -@code{XXX} instruction. - -@section Register Usage - -As discussed above, the @code{XXX} and @code{XXX} instructions do -not automatically save any registers. RTEMS uses the registers -@b{D0}, @b{D1}, @b{A0}, and @b{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 -directive. - -@section Parameter Passing - -RTEMS assumes that arguments are placed on the -current stack before the directive is invoked via the @code{XXX} or @code{XXX} -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: - -@example -@group -push third argument -push second argument -push first argument -invoke directive -remove arguments from the stack -@end group -@end example - -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. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/mips/cpumodel.t b/doc/supplements/mips/cpumodel.t deleted file mode 100644 index c366970ae1..0000000000 --- a/doc/supplements/mips/cpumodel.t +++ /dev/null @@ -1,68 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/XXX/XXX.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the MODEL -processor, this macro is set to the string "XXX". - -@section Floating Point Unit - -The macro XXX_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. - -@section Another Optional Feature - -The macro XXX diff --git a/doc/supplements/mips/cputable.t b/doc/supplements/mips/cputable.t deleted file mode 100644 index 75d0fc15f6..0000000000 --- a/doc/supplements/mips/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The XXX version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the XXX. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - /* XXX CPU family dependent stuff */ -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item XXX -is where the CPU family dependent stuff goes. - -@end table diff --git a/doc/supplements/mips/fatalerr.t b/doc/supplements/mips/fatalerr.t deleted file mode 100644 index 53efad0435..0000000000 --- a/doc/supplements/mips/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is -no user handler configured or the user handler returns control to -RTEMS. The default fatal error handler disables processor interrupts, -places the error code in @b{XXX}, and executes a @code{XXX} -instruction to simulate a halt processor instruction. - diff --git a/doc/supplements/mips/intr_NOTIMES.t b/doc/supplements/mips/intr_NOTIMES.t deleted file mode 100644 index 5b1025e873..0000000000 --- a/doc/supplements/mips/intr_NOTIMES.t +++ /dev/null @@ -1,196 +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 XXX'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 XXX family has two -different interrupt handling models. - -@subsection Models Without Separate Interrupt Stacks - -Upon receipt of an interrupt the XXX 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 XXX 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 -XXX 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 Interrupt Levels - -Eight levels (0-7) of interrupt priorities are -supported by XXX 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 -XXX family only supports eight. RTEMS interrupt levels 0 -through 7 directly correspond to XXX 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 processor 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 mips port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - diff --git a/doc/supplements/mips/memmodel.t b/doc/supplements/mips/memmodel.t deleted file mode 100644 index ef35072230..0000000000 --- a/doc/supplements/mips/memmodel.t +++ /dev/null @@ -1,39 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The XXX 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 this family. - -Some of the XXX family members such as the -XXX, XXX, and XXX support virtual memory and -segmentation. The XXX requires external hardware support -such as the XXX 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 XXX family members. - diff --git a/doc/supplements/mips/mips.texi b/doc/supplements/mips/mips.texi deleted file mode 100644 index e33d69332c..0000000000 --- a/doc/supplements/mips/mips.texi +++ /dev/null @@ -1,114 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename mips.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the Template Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS MIPS Applications Supplement: (mips). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS MIPS Applications Supplement - -@setchapternewpage odd -@settitle RTEMS MIPS Applications Supplement -@titlepage -@finalout - -@title RTEMS MIPS Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeBSP.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top mips - -This is the online version of the RTEMS MIPS Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* BSP_FOR_TIMES Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/mips/preface.texi b/doc/supplements/mips/preface.texi deleted file mode 100644 index c4f4f3ee0b..0000000000 --- a/doc/supplements/mips/preface.texi +++ /dev/null @@ -1,57 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the VENDOR XXX -architecture dependencies in this port of RTEMS. The XXX -family has a wide variety of CPU models within it. The part -numbers ... - -XXX fill in some things here - -It is highly recommended that the XXX -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the family as a whole. - -@subheading Architecture Documents - -IDT docs are online at http://www.idt.com/products/risc/Welcome.html - -For information on the XXX architecture, -refer to the following documents available from VENDOR -(@file{http//www.XXX.com/}): - -@itemize @bullet -@item @cite{XXX Family Reference, VENDOR, PART NUMBER}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@end itemize - diff --git a/doc/supplements/mips/timeBSP.t b/doc/supplements/mips/timeBSP.t deleted file mode 100644 index a00259ec94..0000000000 --- a/doc/supplements/mips/timeBSP.t +++ /dev/null @@ -1,112 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter BSP_FOR_TIMES Timing Data - -@section Introduction - -The timing data for the MIPS version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the MIPS version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with one wait -state dynamic memory and a XXX numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the XXX allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the XXX microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. It -should be noted that the worst case instruction times for the -XXX assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the XXX to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. The interrupt vector and entry -overhead time was generated on an BSP_FOR_TIMES benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the BSP_FOR_TIMES benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent which FPU is being -used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the BSP_FOR_TIMES benchmark platform: - diff --git a/doc/supplements/powerpc/.cvsignore b/doc/supplements/powerpc/.cvsignore deleted file mode 100644 index f4a6482d2a..0000000000 --- a/doc/supplements/powerpc/.cvsignore +++ /dev/null @@ -1,32 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -powerpc -powerpc-? -powerpc-?? -powerpc.aux -powerpc.cp -powerpc.dvi -powerpc.fn -powerpc*.html -powerpc.ky -powerpc.log -powerpc.pdf -powerpc.pg -powerpc.ps -powerpc.toc -powerpc.tp -powerpc.vr -rtems_footer.html -rtems_header.html -stamp-vti -timeDMV177_.t -timePSIM_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/powerpc/ChangeLog b/doc/supplements/powerpc/ChangeLog deleted file mode 100644 index 9e7df2eec7..0000000000 --- a/doc/supplements/powerpc/ChangeLog +++ /dev/null @@ -1,72 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * powerpc.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * powerpc.texi: Set @setfilename powerpc.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/powerpc/DMV177_TIMES b/doc/supplements/powerpc/DMV177_TIMES deleted file mode 100644 index 8f6ff2e3c0..0000000000 --- a/doc/supplements/powerpc/DMV177_TIMES +++ /dev/null @@ -1,248 +0,0 @@ -# -# PowerPC/603e/PSIM Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP DMV177 -RTEMS_CPU_MODEL PPC603e -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100.0 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0-lmco -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 585 -RTEMS_RESTORE_1ST_FP_TASK 730 -RTEMS_SAVE_INIT_RESTORE_INIT 478 -RTEMS_SAVE_IDLE_RESTORE_INIT 825 -RTEMS_SAVE_IDLE_RESTORE_IDLE 478 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 2301 -RTEMS_TASK_IDENT_ONLY 2900 -RTEMS_TASK_START_ONLY 794 -RTEMS_TASK_RESTART_CALLING_TASK 1137 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 906 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 1102 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 928 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 1483 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 1640 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 1601 -RTEMS_TASK_DELETE_CALLING_TASK 2117 -RTEMS_TASK_DELETE_SUSPENDED_TASK 1555 -RTEMS_TASK_DELETE_BLOCKED_TASK 1609 -RTEMS_TASK_DELETE_READY_TASK 1620 -RTEMS_TASK_SUSPEND_CALLING_TASK 960 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 433 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 960 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 803 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 368 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 633 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 1211 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 184 -RTEMS_TASK_MODE_NO_RESCHEDULE 213 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 247 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 919 -RTEMS_TASK_GET_NOTE_ONLY 382 -RTEMS_TASK_SET_NOTE_ONLY 383 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 245 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 851 -RTEMS_TASK_WAKE_WHEN_ONLY 1275 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 201 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 206 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 202 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED 201 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 213 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 857 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 792 -RTEMS_CLOCK_GET_ONLY 78 -RTEMS_CLOCK_TICK_ONLY 214 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 357 -RTEMS_TIMER_IDENT_ONLY 2828 -RTEMS_TIMER_DELETE_INACTIVE 432 -RTEMS_TIMER_DELETE_ACTIVE 471 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 607 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 646 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 766 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 764 -RTEMS_TIMER_RESET_INACTIVE 552 -RTEMS_TIMER_RESET_ACTIVE 766 -RTEMS_TIMER_CANCEL_INACTIVE 339 -RTEMS_TIMER_CANCEL_ACTIVE 378 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 571 -RTEMS_SEMAPHORE_IDENT_ONLY 3243 -RTEMS_SEMAPHORE_DELETE_ONLY 575 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 414 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 414 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 1254 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 501 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 636 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 982 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 2270 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 2828 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 708 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 923 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 955 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 1322 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 919 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 955 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 1322 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 589 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 1079 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 1435 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 755 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 467 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 1283 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 369 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 431 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 354 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 571 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 946 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 43 -RTEMS_EVENT_RECEIVE_AVAILABLE 357 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 331 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 1043 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 267 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 408 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 607 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 464 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 752 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 762 -RTEMS_PARTITION_IDENT_ONLY 2828 -RTEMS_PARTITION_DELETE_ONLY 426 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 394 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 376 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 420 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 614 -RTEMS_REGION_IDENT_ONLY 2878 -RTEMS_REGION_DELETE_ONLY 425 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 515 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 472 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 1345 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 544 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 935 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 1296 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 428 -RTEMS_PORT_IDENT_ONLY 2828 -RTEMS_PORT_DELETE_ONLY 421 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 339 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 339 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 52 -RTEMS_IO_OPEN_ONLY 42 -RTEMS_IO_CLOSE_ONLY 44 -RTEMS_IO_READ_ONLY 42 -RTEMS_IO_WRITE_ONLY 44 -RTEMS_IO_CONTROL_ONLY 42 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 388 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 2826 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 427 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 519 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 465 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 556 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 842 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 377 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 428 -RTEMS_MINIMUM_CONFIGURATION 30,980 -RTEMS_MAXIMUM_CONFIGURATION 55540 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 21,516 -RTEMS_INITIALIZATION_CODE_SIZE 1,412 -RTEMS_TASK_CODE_SIZE 4,804 -RTEMS_INTERRUPT_CODE_SIZE 96 -RTEMS_CLOCK_CODE_SIZE 536 -RTEMS_TIMER_CODE_SIZE 1,380 -RTEMS_SEMAPHORE_CODE_SIZE 1,928 -RTEMS_MESSAGE_CODE_SIZE 532 -RTEMS_EVENT_CODE_SIZE 100 -RTEMS_SIGNAL_CODE_SIZE 100 -RTEMS_PARTITION_CODE_SIZE 1,384 -RTEMS_REGION_CODE_SIZE 1,780 -RTEMS_DPMEM_CODE_SIZE 928 -RTEMS_IO_CODE_SIZE 1,244 -RTEMS_FATAL_ERROR_CODE_SIZE 44 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,756 -RTEMS_MULTIPROCESSING_CODE_SIZE 11,448 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 340 -RTEMS_SEMAPHORE_CODE_OPTSIZE 308 -RTEMS_MESSAGE_CODE_OPTSIZE 532 -RTEMS_EVENT_CODE_OPTSIZE 100 -RTEMS_SIGNAL_CODE_OPTSIZE 100 -RTEMS_PARTITION_CODE_OPTSIZE 244 -RTEMS_REGION_CODE_OPTSIZE 292 -RTEMS_DPMEM_CODE_OPTSIZE 244 -RTEMS_IO_CODE_OPTSIZE NA -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 336 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 612 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 456 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 120 -RTEMS_BYTES_PER_MESSAGE_QUEUE 144 -RTEMS_BYTES_PER_REGION 140 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 264 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10008 - diff --git a/doc/supplements/powerpc/Makefile.am b/doc/supplements/powerpc/Makefile.am deleted file mode 100644 index 3dcdf95c6f..0000000000 --- a/doc/supplements/powerpc/Makefile.am +++ /dev/null @@ -1,125 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = powerpc -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timePSIM.texi timeDMV177.texi -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = powerpc.texi -powerpc_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Low Power Model" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t PSIM_TIMES - ${REPLACE2} -p $(srcdir)/PSIM_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t PSIM_TIMES - ${REPLACE2} -p $(srcdir)/PSIM_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "PSIM Timing Data" < $< > $@ - -# Timing Data for PSIM BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timePSIM.texi: $(top_srcdir)/common/timetbl.t timePSIM.t - cat $(srcdir)/timePSIM.t $(top_srcdir)/common/timetbl.t >timePSIM_.t - @echo >>timePSIM_.t - @echo "@tex" >>timePSIM_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timePSIM_.t - @echo "@end tex" >>timePSIM_.t - ${REPLACE2} -p $(srcdir)/PSIM_TIMES timePSIM_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "DMV177 Timing Data" > $@ -CLEANFILES += timePSIM_.t timeDMV177_.t - -# Timing Data for DMV177 BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeDMV177.texi: $(top_srcdir)/common/timetbl.t timeDMV177.t - cat $(srcdir)/timeDMV177.t $(top_srcdir)/common/timetbl.t >timeDMV177_.t - @echo >>timeDMV177_.t - @echo "@tex" >>timeDMV177_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeDMV177_.t - @echo "@end tex" >>timeDMV177_.t - ${REPLACE2} -p $(srcdir)/DMV177_TIMES timeDMV177_.t | \ - $(BMENU2) -p "PSIM Timing Data Rate Monotonic Manager" \ - -u "Top" \ - -n "Command and Variable Index" > $@ - -EXTRA_DIST = DMV177_TIMES PSIM_TIMES bsp.t callconv.t cpumodel.t cputable.t \ - fatalerr.t intr_NOTIMES.t memmodel.t timeDMV177.t timePSIM.t - -CLEANFILES += powerpc.info powerpc.info-? diff --git a/doc/supplements/powerpc/PSIM_TIMES b/doc/supplements/powerpc/PSIM_TIMES deleted file mode 100644 index b357a1fc3c..0000000000 --- a/doc/supplements/powerpc/PSIM_TIMES +++ /dev/null @@ -1,248 +0,0 @@ -# -# PowerPC/603e/PSIM Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP PSIM -RTEMS_CPU_MODEL PPC603e -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ na -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0-lmco -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 214 -RTEMS_RESTORE_1ST_FP_TASK 255 -RTEMS_SAVE_INIT_RESTORE_INIT 140 -RTEMS_SAVE_IDLE_RESTORE_INIT 140 -RTEMS_SAVE_IDLE_RESTORE_IDLE 290 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 1075 -RTEMS_TASK_IDENT_ONLY 1637 -RTEMS_TASK_START_ONLY 345 -RTEMS_TASK_RESTART_CALLING_TASK 483 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 396 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 491 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 404 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 644 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 709 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 686 -RTEMS_TASK_DELETE_CALLING_TASK 941 -RTEMS_TASK_DELETE_SUSPENDED_TASK 703 -RTEMS_TASK_DELETE_BLOCKED_TASK 723 -RTEMS_TASK_DELETE_READY_TASK 729 -RTEMS_TASK_SUSPEND_CALLING_TASK 403 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 181 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 191 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 803 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 147 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 264 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 517 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 88 -RTEMS_TASK_MODE_NO_RESCHEDULE 110 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 112 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 386 -RTEMS_TASK_GET_NOTE_ONLY 156 -RTEMS_TASK_SET_NOTE_ONLY 155 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 92 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 348 -RTEMS_TASK_WAKE_WHEN_ONLY 546 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 60 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 62 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 61 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED 55 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 67 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 344 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 340 -RTEMS_CLOCK_GET_ONLY 29 -RTEMS_CLOCK_TICK_ONLY 81 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 144 -RTEMS_TIMER_IDENT_ONLY 1595 -RTEMS_TIMER_DELETE_INACTIVE 197 -RTEMS_TIMER_DELETE_ACTIVE 181 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 252 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 269 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 333 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 334 -RTEMS_TIMER_RESET_INACTIVE 233 -RTEMS_TIMER_RESET_ACTIVE 250 -RTEMS_TIMER_CANCEL_INACTIVE 156 -RTEMS_TIMER_CANCEL_ACTIVE 140 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 223 -RTEMS_SEMAPHORE_IDENT_ONLY 1836 -RTEMS_SEMAPHORE_DELETE_ONLY 1836 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 175 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 175 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 530 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 206 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 272 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 415 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 1022 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 1596 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 308 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 421 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 434 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 581 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 422 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 435 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 582 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 244 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 482 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 630 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 345 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 197 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 542 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 142 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 170 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 145 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 250 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 407 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 17 -RTEMS_EVENT_RECEIVE_AVAILABLE 133 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 130 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 442 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 95 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 165 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 275 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 216 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 329 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 320 -RTEMS_PARTITION_IDENT_ONLY 1596 -RTEMS_PARTITION_DELETE_ONLY 168 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 157 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 149 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 172 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 239 -RTEMS_REGION_IDENT_ONLY 1625 -RTEMS_REGION_DELETE_ONLY 167 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 206 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 190 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 556 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 230 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 412 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 562 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 167 -RTEMS_PORT_IDENT_ONLY 1594 -RTEMS_PORT_DELETE_ONLY 165 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 133 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 134 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 23 -RTEMS_IO_OPEN_ONLY 18 -RTEMS_IO_CLOSE_ONLY 18 -RTEMS_IO_READ_ONLY 18 -RTEMS_IO_WRITE_ONLY 18 -RTEMS_IO_CONTROL_ONLY 18 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 149 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 1595 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 169 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 212 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 186 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 226 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 362 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 142 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 428 -RTEMS_MINIMUM_CONFIGURATION 30,912 -RTEMS_MAXIMUM_CONFIGURATION 55,572 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 21,452 -RTEMS_INITIALIZATION_CODE_SIZE 1,408 -RTEMS_TASK_CODE_SIZE 4,804 -RTEMS_INTERRUPT_CODE_SIZE 96 -RTEMS_CLOCK_CODE_SIZE 536 -RTEMS_TIMER_CODE_SIZE 1,380 -RTEMS_SEMAPHORE_CODE_SIZE 1,928 -RTEMS_MESSAGE_CODE_SIZE 2,400 -RTEMS_EVENT_CODE_SIZE 1,460 -RTEMS_SIGNAL_CODE_SIZE 576 -RTEMS_PARTITION_CODE_SIZE 1,384 -RTEMS_REGION_CODE_SIZE 1,780 -RTEMS_DPMEM_CODE_SIZE 928 -RTEMS_IO_CODE_SIZE 1,244 -RTEMS_FATAL_ERROR_CODE_SIZE 44 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,756 -RTEMS_MULTIPROCESSING_CODE_SIZE 11,448 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 340 -RTEMS_SEMAPHORE_CODE_OPTSIZE 308 -RTEMS_MESSAGE_CODE_OPTSIZE 532 -RTEMS_EVENT_CODE_OPTSIZE 100 -RTEMS_SIGNAL_CODE_OPTSIZE 100 -RTEMS_PARTITION_CODE_OPTSIZE 244 -RTEMS_REGION_CODE_OPTSIZE 292 -RTEMS_DPMEM_CODE_OPTSIZE 244 -RTEMS_IO_CODE_OPTSIZE NA -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 336 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 612 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 456 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 120 -RTEMS_BYTES_PER_MESSAGE_QUEUE 144 -RTEMS_BYTES_PER_REGION 140 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 264 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,008 - diff --git a/doc/supplements/powerpc/bsp.t b/doc/supplements/powerpc/bsp.t deleted file mode 100644 index cf71029fa6..0000000000 --- a/doc/supplements/powerpc/bsp.t +++ /dev/null @@ -1,76 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of PowerPC specific BSP issues. -For more information on developing a BSP, refer to the chapter -titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the PowerPC processor is reset. The PowerPC -architecture defines a Reset Exception, but leaves the -details of the CPU state as implementation specific. Please -refer to the User's Manual for the CPU model in question. - -In general, at power-up the PowerPC begin execution at address -0xFFF00100 in supervisor mode with all exceptions disabled. For -soft resets, the CPU will vector to either 0xFFF00100 or 0x00000100 -depending upon the setting of the Exception Prefix bit in the MSR. -If during a soft reset, a Machine Check Exception occurs, then the -CPU may execute a hard reset. - -@section Processor Initialization - -It is the responsibility of the application's -initialization code to initialize the CPU and board -to a quiescent state before invoking the @code{rtems_initialize_executive} -directive. It is recommended that the BSP utilize the @code{predriver_hook} -to install default handlers for all exceptions. These default handlers -may be overwritten as various device drivers and subsystems install -their own exception handlers. Upon completion of RTEMS executive -initialization, all interrupts are enabled. - -If this PowerPC implementation supports on-chip caching -and this is to be utilized, then it should be enabled during the -reset application initialization code. On-chip caching has been -observed to prevent some emulators from working properly, so it -may be necessary to run with caching disabled to use these emulators. - -In addition to the requirements described in the -@b{Board Support Packages} chapter of the @b{@value{LANGUAGE} -Applications User's Manual} for the reset code -which is executed before the call to @code{rtems_initialize_executive}, -the PowrePC version has the following specific requirements: - -@itemize @bullet -@item Must leave the PR bit of the Machine State Register (MSR) set -to 0 so the PowerPC remains in the supervisor state. - -@item Must set stack pointer (sp or r1) such that a minimum stack -size of MINIMUM_STACK_SIZE bytes is provided for the -@code{rtems_initialize_executive} directive. - -@item Must disable all external interrupts (i.e. clear the EI (EE) -bit of the machine state register). - -@item Must enable traps so window overflow and underflow -conditions can be properly handled. - -@item Must initialize the PowerPC's initial Exception Table with default -handlers. - -@end itemize - diff --git a/doc/supplements/powerpc/callconv.t b/doc/supplements/powerpc/callconv.t deleted file mode 100644 index 7722589058..0000000000 --- a/doc/supplements/powerpc/callconv.t +++ /dev/null @@ -1,229 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage - -@item parameter passing - -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -RTEMS supports the Embedded Application Binary Interface (EABI) -calling convention. Documentation for EABI is available by sending -a message with a subject line of "EABI" to eabi@@goth.sis.mot.com. - -@section Programming Model - -This section discusses the programming model for the -PowerPC architecture. - -@subsection Non-Floating Point Registers - -The PowerPC architecture defines thirty-two non-floating point registers -directly visible to the programmer. In thirty-two bit implementations, each -register is thirty-two bits wide. In sixty-four bit implementations, each -register is sixty-four bits wide. - -These registers are referred to as @code{gpr0} to @code{gpr31}. - -Some of the registers serve defined roles in the EABI programming model. -The following table describes the role of each of these registers: - -@ifset use-ascii -@example -@group - +---------------+----------------+------------------------------+ - | Register Name | Alternate Name | Description | - +---------------+----------------+------------------------------+ - | r1 | sp | stack pointer | - +---------------+----------------+------------------------------+ - | | | global pointer to the Small | - | r2 | na | Constant Area (SDA2) | - +---------------+----------------+------------------------------+ - | r3 - r12 | na | parameter and result passing | - +---------------+----------------+------------------------------+ - | | | global pointer to the Small | - | r13 | na | Data Area (SDA) | - +---------------+----------------+------------------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 2.50in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} -&r1&&sp&&stack pointer&\cr\noalign{\hrule} -&r2&&NA&&global pointer to the Small&\cr -&&&&&Constant Area (SDA2)&\cr\noalign{\hrule} -&r3 - r12&&NA&¶meter and result passing&\cr\noalign{\hrule} -&r13&&NA&&global pointer to the Small&\cr -&&&&&Data Area (SDA2)&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - - - - - - - - -
Register NameAlternate NameDescription
r1spstack pointer
r2naglobal pointer to the Small Constant Area (SDA2)
r3 - r12NAparameter and result passing
r13NAglobal pointer to the Small Data Area (SDA)
-
-@end html -@end ifset - - -@subsection Floating Point Registers - -The PowerPC architecture includes thirty-two, sixty-four bit -floating point registers. All PowerPC floating point instructions -interpret these registers as 32 double precision floating point registers, -regardless of whether the processor has 64-bit or 32-bit implementation. - -The floating point status and control register (fpscr) records exceptions -and the type of result generated by floating-point operations. -Additionally, it controls the rounding mode of operations and allows the -reporting of floating exceptions to be enabled or disabled. - -@subsection Special Registers - -The PowerPC architecture includes a number of special registers -which are critical to the programming model: - -@table @b - -@item Machine State Register - -The MSR contains the processor mode, power management mode, endian mode, -exception information, privilege level, floating point available and -floating point excepiton mode, address translation information and -the exception prefix. - -@item Link Register - -The LR contains the return address after a function call. This register -must be saved before a subsequent subroutine call can be made. The -use of this register is discussed further in the @b{Call and Return -Mechanism} section below. - -@item Count Register - -The CTR contains the iteration variable for some loops. It may also be used -for indirect function calls and jumps. - -@end table - -@section Call and Return Mechanism - -The PowerPC architecture supports a simple yet effective call -and return mechanism. A subroutine is invoked -via the "branch and link" (@code{bl}) and -"brank and link absolute" (@code{bla}) -instructions. This instructions place the return address -in the Link Register (LR). The callee returns to the caller by -executing a "branch unconditional to the link register" (@code{blr}) -instruction. Thus the callee returns to the caller via a jump -to the return address which is stored in the LR. - -The previous contents of the LR are not automatically saved -by either the @code{bl} or @code{bla}. It is the responsibility -of the callee to save the contents of the LR before invoking -another subroutine. If the callee invokes another subroutine, -it must restore the LR before executing the @code{blr} instruction -to return to the caller. - -It is important to note that the PowerPC subroutine -call and return mechanism does not automatically save and -restore any registers. - -The LR may be accessed as special purpose register 8 (@code{SPR8}) using the -"move from special register" (@code{mfspr}) and -"move to special register" (@code{mtspr}) instructions. - -@section Calling Mechanism - -All RTEMS directives are invoked using the regular -PowerPC EABI calling convention via the @code{bl} or -@code{bla} instructions. - -@section Register Usage - -As discussed above, the call instruction does not -automatically save any registers. It is the responsibility -of the callee to save and restore any registers which must be preserved -across subroutine calls. The callee is responsible for saving -callee-preserved registers to the program stack and restoring them -before returning to the caller. - -@section Parameter Passing - -RTEMS assumes that arguments are placed in the -general purpose registers with the first argument in -register 3 (@code{r3}), the second argument in general purpose -register 4 (@code{r4}), and so forth until the seventh -argument is in general purpose register 10 (@code{r10}). -If there are more than seven arguments, then subsequent arguments -are placed on the program stack. The following pseudo-code -illustrates the typical sequence used to call a RTEMS directive -with three (3) arguments: - -@example -load third argument into r5 -load second argument into r4 -load first argument into r3 -invoke directive -@end example - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these same calling conventions. - - diff --git a/doc/supplements/powerpc/cpumodel.t b/doc/supplements/powerpc/cpumodel.t deleted file mode 100644 index 3173dc15f0..0000000000 --- a/doc/supplements/powerpc/cpumodel.t +++ /dev/null @@ -1,156 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC, and PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. - -@section CPU Model Feature Flags - -Each processor family supported by RTEMS has a -list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This section presents the set of features which vary -across PowerPC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/ppc/ppc.h based upon the particular CPU -model defined on the compilation command line. - -@subsection CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the PowerPC 603e -model, this macro is set to the string "PowerPC 603e". - -@subsection Floating Point Unit - -The macro PPC_HAS_FPU is set to 1 to indicate that this CPU model -has a hardware floating point unit and 0 otherwise. - -@subsection Alignment - -The macro PPC_ALIGNMENT is set to the PowerPC model's worst case alignment -requirement for data types on a byte boundary. This value is used -to derive the alignment restrictions for memory allocated from -regions and partitions. - -@subsection Cache Alignment - -The macro PPC_CACHE_ALIGNMENT is set to the line size of the cache. It is -used to align the entry point of critical routines so that as much code -as possible can be retrieved with the initial read into cache. This -is done for the interrupt handler as well as the context switch routines. - -In addition, the "shortcut" data structure used by the PowerPC implementation -to ease access to data elements frequently accessed by RTEMS routines -implemented in assembly language is aligned using this value. - -@subsection Maximum Interrupts - -The macro PPC_INTERRUPT_MAX is set to the number of exception sources -supported by this PowerPC model. - -@subsection Has Double Precision Floating Point - -The macro PPC_HAS_DOUBLE is set to 1 to indicate that the PowerPC model -has support for double precision floating point numbers. This is -important because the floating point registers need only be four bytes -wide (not eight) if double precision is not supported. - -@subsection Critical Interrupts - -The macro PPC_HAS_RFCI is set to 1 to indicate that the PowerPC model -has the Critical Interrupt capability as defined by the IBM 403 models. - -@subsection Use Multiword Load/Store Instructions - -The macro PPC_USE_MULTIPLE is set to 1 to indicate that multiword load and -store instructions should be used to perform context switch operations. -The relative efficiency of multiword load and store instructions versus -an equivalent set of single word load and store instructions varies based -upon the PowerPC model. - -@subsection Instruction Cache Size - -The macro PPC_I_CACHE is set to the size in bytes of the instruction cache. - -@subsection Data Cache Size - -The macro PPC_D_CACHE is set to the size in bytes of the data cache. - -@subsection Debug Model - -The macro PPC_DEBUG_MODEL is set to indicate the debug support features -present in this CPU model. The following debug support feature sets -are currently supported: - -@table @b - -@item @code{PPC_DEBUG_MODEL_STANDARD} -indicates that the single-step trace enable (SE) and branch trace -enable (BE) bits in the MSR are supported by this CPU model. - -@item @code{PPC_DEBUG_MODEL_SINGLE_STEP_ONLY} -indicates that only the single-step trace enable (SE) bit in the MSR -is supported by this CPU model. - -@item @code{PPC_DEBUG_MODEL_IBM4xx} -indicates that the debug exception enable (DE) bit in the MSR is supported -by this CPU model. At this time, this particular debug feature set -has only been seen in the IBM 4xx series. - -@end table - -@subsection Low Power Model - -The macro PPC_LOW_POWER_MODE is set to indicate the low power model -supported by this CPU model. The following low power modes are currently -supported. - -@table @b - -@item @code{PPC_LOW_POWER_MODE_NONE} -indicates that this CPU model has no low power mode support. - -@item @code{PPC_LOW_POWER_MODE_STANDARD} -indicates that this CPU model follows the low power model defined for -the PPC603e. - -@end table diff --git a/doc/supplements/powerpc/cputable.t b/doc/supplements/powerpc/cputable.t deleted file mode 100644 index 42f67b1a70..0000000000 --- a/doc/supplements/powerpc/cputable.t +++ /dev/null @@ -1,155 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The PowerPC version of the RTEMS CPU Dependent -Information Table is given by the C structure definition is -shown below: - -@example -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - unsigned32 clicks_per_usec; /* Timer clicks per microsecond */ - void (*spurious_handler)( - unsigned32 vector, CPU_Interrupt_frame *); - boolean exceptions_in_RAM; /* TRUE if in RAM */ - -#if defined(ppc403) - unsigned32 serial_per_sec; /* Serial clocks per second */ - boolean serial_external_clock; - boolean serial_xon_xoff; - boolean serial_cts_rts; - unsigned32 serial_rate; - unsigned32 timer_average_overhead; /* in ticks */ - unsigned32 timer_least_valid; /* Least valid number from timer */ -#endif -@}; -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS allocated interrupt stack in bytes. -This value must be at least as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item clicks_per_usec -is the number of decrementer interupts that occur each microsecond. - -@item spurious_handler -is the address of the -routine which is invoked when a spurious interrupt occurs. - -@item exceptions_in_RAM -indicates whether the exception vectors are located in RAM or ROM. If -they are located in RAM dynamic vector installation occurs, otherwise -it does not. - -@item serial_per_sec -is a PPC403 specific field which specifies the number of clock -ticks per second for the PPC403 serial timer. - -@item serial_rate -is a PPC403 specific field which specifies the baud rate for the -PPC403 serial port. - -@item serial_external_clock -is a PPC403 specific field which indicates whether or not to mask in a 0x2 into -the Input/Output Configuration Register (IOCR) during initialization of the -PPC403 console. (NOTE: This bit is defined as "reserved" 6-12?) - -@item serial_xon_xoff -is a PPC403 specific field which indicates whether or not -XON/XOFF flow control is supported for the PPC403 serial port. - -@item serial_cts_rts -is a PPC403 specific field which indicates whether or not to set the -least significant bit of the Input/Output Configuration Register -(IOCR) during initialization of the PPC403 console. (NOTE: This -bit is defined as "reserved" 6-12?) - -@item timer_average_overhead -is a PPC403 specific field which specifies the average number of overhead ticks that occur on the PPC403 timer. - -@item timer_least_valid -is a PPC403 specific field which specifies the maximum valid PPC403 timer value. - -@end table - diff --git a/doc/supplements/powerpc/fatalerr.t b/doc/supplements/powerpc/fatalerr.t deleted file mode 100644 index 8a03d57674..0000000000 --- a/doc/supplements/powerpc/fatalerr.t +++ /dev/null @@ -1,47 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler performs the following actions: - -@itemize @bullet - -@item places the error code in r3, and - -@item executes a trap instruction which results in a Program Exception. - -@end itemize - -If the Program Exception returns, then the following actions are performed: - -@itemize @bullet - -@item disables all processor exceptions by loading a 0 into the MSR, and - -@item goes into an infinite loop to simulate a halt processor instruction. - -@end itemize - diff --git a/doc/supplements/powerpc/intr_NOTIMES.t b/doc/supplements/powerpc/intr_NOTIMES.t deleted file mode 100644 index 514e27c9a5..0000000000 --- a/doc/supplements/powerpc/intr_NOTIMES.t +++ /dev/null @@ -1,184 +0,0 @@ -@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 PowerPC's -interrupt response and control mechanisms as they pertain to -RTEMS. - -RTEMS and associated documentation uses the terms -interrupt and vector. In the PowerPC architecture, these terms -correspond to exception and exception handler, respectively. The terms will -be used interchangeably in this manual. - -@section Synchronous Versus Asynchronous Exceptions - -In the PowerPC architecture exceptions can be either precise or -imprecise and either synchronous or asynchronous. Asynchronous -exceptions occur when an external event interrupts the processor. -Synchronous exceptions are caused by the actions of an -instruction. During an exception SRR0 is used to calculate where -instruction processing should resume. All instructions prior to -the resume instruction will have completed execution. SRR1 is used to -store the machine status. - -There are two asynchronous nonmaskable, highest-priority exceptions -system reset and machine check. There are two asynchrononous maskable -low-priority exceptions external interrupt and decrementer. Nonmaskable -execptions are never delayed, therefore if two nonmaskable, asynchronous -exceptions occur in immediate succession, the state information saved by -the first exception may be overwritten when the subsequent exception occurs. - -The PowerPC arcitecure defines one imprecise exception, the imprecise -floating point enabled exception. All other synchronous exceptions are -precise. The synchronization occuring during asynchronous precise -exceptions conforms to the requirements for context synchronization. - -@section Vectoring of Interrupt Handler - -Upon determining that an exception can be taken the PowerPC automatically -performs the following actions: - -@itemize @bullet -@item an instruction address is loaded into SRR0 - -@item bits 33-36 and 42-47 of SRR1 are loaded with information -specific to the exception. - -@item bits 0-32, 37-41, and 48-63 of SRR1 are loaded with corresponding -bits from the MSR. - -@item the MSR is set based upon the exception type. - -@item instruction fetch and execution resumes, using the new MSR value, at a location specific to the execption type. - -@end itemize - -If the interrupt handler was installed as an RTEMS -interrupt handler, then upon receipt of the interrupt, the -processor passes control to the RTEMS interrupt handler which -performs the following actions: - -@itemize @bullet -@item saves the state of the interrupted task on it's stack, - -@item saves all registers which are not normally preserved -by the calling sequence so the user's interrupt service -routine can be written in a high-level language. - -@item if this is the outermost (i.e. non-nested) interrupt, -then the RTEMS interrupt handler switches from the current stack -to the interrupt stack, - -@item enables exceptions, - -@item invokes the vectors to a user interrupt service routine (ISR). -@end itemize - -Asynchronous interrupts are ignored while exceptions are -disabled. Synchronous interrupts which occur while are -disabled result in the CPU being forced into an error mode. - -A nested interrupt is processed similarly with the -exception that the current stack need not be switched to the -interrupt stack. - -@section Interrupt Levels - -The PowerPC architecture supports only a single external -asynchronous interrupt source. This interrupt source -may be enabled and disabled via the External Interrupt Enable (EE) -bit in the Machine State Register (MSR). Thus only two level (enabled -and disabled) of external device interrupt priorities are -directly supported by the PowerPC architecture. - -Some PowerPC implementations include a Critical Interrupt capability -which is often used to receive interrupts from high priority external -devices. - -The RTEMS interrupt level mapping scheme for the PowerPC is not -a numeric level as on most RTEMS ports. It is a bit mapping in -which the least three significiant bits of the interrupt level -are mapped directly to the enabling of specific interrupt -sources as follows: - -@table @b - -@item Critical Interrupt -Setting bit 0 (the least significant bit) of the interrupt level -enables the Critical Interrupt source, if it is available on this -CPU model. - -@item Machine Check -Setting bit 1 of the interrupt level enables Machine Check execptions. - -@item External Interrupt -Setting bit 2 of the interrupt level enables External Interrupt execptions. - -@end table - -All other bits in the RTEMS task interrupt level are ignored. - -@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 Critical Interrupts, External Interrupts -and Machine Checks 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 PowerPC 603e 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.] - -If a PowerPC implementation provides non-maskable interrupts (NMI) -which cannot be disabled, ISRs which process these interrupts -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 - -The PowerPC architecture does not provide for a -dedicated interrupt stack. Thus by default, exception handlers would -execute on the stack of the RTEMS task which they interrupted. -This artificially inflates the stack requirements for each task -since EVERY task stack would have to include enough space to -account for the worst case interrupt stack requirements in -addition to it's own worst case usage. RTEMS addresses this -problem on the PowerPC by providing a dedicated interrupt stack -managed by software. - -During system initialization, 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. As -part of processing a non-nested interrupt, RTEMS will switch to -the interrupt stack before invoking the installed handler. - - - diff --git a/doc/supplements/powerpc/memmodel.t b/doc/supplements/powerpc/memmodel.t deleted file mode 100644 index 13341696cf..0000000000 --- a/doc/supplements/powerpc/memmodel.t +++ /dev/null @@ -1,110 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The PowerPC architecture supports a variety of memory models. -RTEMS supports the PowerPC using a flat memory model with -paging disabled. In this mode, the PowerPC automatically -converts every address from a logical to a physical address -each time it is used. The PowerPC uses information provided -in the Block Address Translation (BAT) to convert these addresses. - -Implementations of the PowerPC architecture may be thirty-two or sixty-four bit. -The PowerPC architecture supports a flat thirty-two or sixty-four bit address -space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 -gigabytes) in thirty-two bit implementations or to 0xFFFFFFFFFFFFFFFF -in sixty-four bit implementations. Each address is represented -by either a thirty-two bit or sixty-four bit value and is byte addressable. -The address may be used to reference a single byte, half-word -(2-bytes), word (4 bytes), or in sixty-four bit implementations a -doubleword (8 bytes). Memory accesses within the address space are -performed in big or little endian fashion by the PowerPC based -upon the current setting of the Little-endian mode enable bit (LE) -in the Machine State Register (MSR). While the processor is in -big endian mode, memory accesses which are not properly aligned -generate an "alignment exception" (vector offset 0x00600). In -little endian mode, the PowerPC architecture does not require -the processor to generate alignment exceptions. - -The following table lists the alignment requirements for a variety -of data accesses: - -@ifset use-ascii -@example -@group - +--------------+-----------------------+ - | Data Type | Alignment Requirement | - +--------------+-----------------------+ - | byte | 1 | - | half-word | 2 | - | word | 4 | - | doubleword | 8 | - +--------------+-----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} -&byte&&1&\cr\noalign{\hrule} -&half-word&&2&\cr\noalign{\hrule} -&word&&4&\cr\noalign{\hrule} -&doubleword&&8&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - - - -
Data TypeAlignment Requirement
byte1
half-word2
word4
doubleword8
-
-@end html -@end ifset - -Doubleword load and store operations are only available in -PowerPC CPU models which are sixty-four bit implementations. - -RTEMS does not directly support any PowerPC Memory Management -Units, therefore, virtual memory or segmentation systems -involving the PowerPC are not supported. - diff --git a/doc/supplements/powerpc/powerpc.texi b/doc/supplements/powerpc/powerpc.texi deleted file mode 100644 index 4e27aa0ee0..0000000000 --- a/doc/supplements/powerpc/powerpc.texi +++ /dev/null @@ -1,115 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename powerpc.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the PowerPC Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS PowerPC Applications Supplement: (powerpc). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS PowerPC Applications Supplement - -@setchapternewpage odd -@settitle RTEMS PowerPC Applications Supplement -@titlepage -@finalout - -@title RTEMS PowerPC Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timePSIM.texi -@include timeDMV177.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top powerpc - -This is the online version of the RTEMS PowerPC Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* PSIM Timing Data:: -* DMV177 Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, DMV177 Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/powerpc/preface.texi b/doc/supplements/powerpc/preface.texi deleted file mode 100644 index 607953e00c..0000000000 --- a/doc/supplements/powerpc/preface.texi +++ /dev/null @@ -1,94 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems -(RTEMS) is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the PowerPC architecture -dependencies in this port of RTEMS. - -It is highly recommended that the PowerPC RTEMS -application developer obtain and become familiar with the -documentation for the processor being used as well as the -specification for the revision of the PowerPC architecture which -corresponds to that processor. - -@subheading PowerPC Architecture Documents - -For information on the PowerPC architecture, refer to -the following documents available from Motorola and IBM: - -@itemize @bullet - -@item @cite{PowerPC Microprocessor Family: The Programming Environment} -(Motorola Document MPRPPCFPE-01). - -@item @cite{IBM PPC403GB Embedded Controller User's Manual}. - -@item @cite{PoweRisControl MPC500 Family RCPU RISC Central Processing -Unit Reference Manual} (Motorola Document RCPUURM/AD). - -@item @cite{PowerPC 601 RISC Microprocessor User's Manual} -(Motorola Document MPR601UM/AD). - -@item @cite{PowerPC 603 RISC Microprocessor User's Manual} -(Motorola Document MPR603UM/AD). - -@item @cite{PowerPC 603e RISC Microprocessor User's Manual} -(Motorola Document MPR603EUM/AD). - -@item @cite{PowerPC 604 RISC Microprocessor User's Manual} -(Motorola Document MPR604UM/AD). - -@item @cite{PowerPC MPC821 Portable Systems Microprocessor User's Manual} -(Motorola Document MPC821UM/AD). - -@item @cite{PowerQUICC MPC860 User's Manual} (Motorola Document MPC860UM/AD). - - -@end itemize - -Motorola maintains an on-line electronic library for the PowerPC -at the following URL: - -@itemize @code{ } -@item @cite{http://www.mot.com/powerpc/library/library.html} -@end itemize - -This site has a a wealth of information and examples. Many of the -manuals are available from that site in electronic format. - -@subheading PowerPC Processor Simulator Information - -PSIM is a program which emulates the Instruction Set Architecture -of the PowerPC microprocessor family. It is reely available in source -code form under the terms of the GNU General Public License (version -2 or later). PSIM can be integrated with the GNU Debugger (gdb) to -execute and debug PowerPC executables on non-PowerPC hosts. PSIM -supports the addition of user provided device models which can be -used to allow one to develop and debug embedded applications using -the simulator. - -The latest version of PSIM is made available to the public via -anonymous ftp at ftp://ftp.ci.com.au/pub/psim or -ftp://cambridge.cygnus.com/pub/psim. There is also a mailing list -at powerpc-psim@@ci.com.au. - - diff --git a/doc/supplements/powerpc/timeDMV177.t b/doc/supplements/powerpc/timeDMV177.t deleted file mode 100644 index 301bfee4c1..0000000000 --- a/doc/supplements/powerpc/timeDMV177.t +++ /dev/null @@ -1,113 +0,0 @@ -@c -@c Timing information for the DMV177 -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter RTEMS_BSP Timing Data - -@section Introduction - -The timing data for RTEMS on the DY-4 RTEMS_BSP board -is provided along with the target -dependent aspects concerning the gathering of the timing data. -The hardware platform used to gather the times is described to -give the reader a better understanding of each directive time -provided. Also, provided is a description of the interrupt -latency and the context switch times as they pertain to the -PowerPC version of RTEMS. - -@section Hardware Platform - -All times reported in this chapter were measured using a RTEMS_BSP board. -All data and code caching was disabled. This results in very deterministic -times which represent the worst possible performance. Many embedded -applications disable caching to insure that execution times are -repeatable. Moreover, the JTAG port on certain revisions of the PowerPC -603e does not operate properly if caching is enabled. Thus during -development and debug, caching must be off. - -The PowerPC decrementer register was was used to gather -all timing information. In the PowerPC architecture, -this register typically counts -something like CPU cycles or is a function of the clock -speed. On the PPC603e decrements once for every four (4) bus cycles. -On the RTEMS_BSP, the bus operates at a clock speed of -33 Mhz. This result in a very accurate number since it is a function of the -microprocessor itself. Thus all measurements in this -chapter are reported as the actual number of decrementer -clicks reported. - -To convert the numbers reported to microseconds, one should -divide the number reported by 8.650752. This number was derived as -shown below: - -@example -((33 * 1048576) / 1000000) / 4 = 8.650752 -@end example - -All sources of hardware interrupts were disabled, -although traps were enabled and the interrupt level of the -PowerPC allows all interrupts. - -@section Interrupt Latency - -The maximum period with traps disabled or the -processor interrupt level set to it's highest value inside RTEMS -is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions which -disable and re-enable interrupts. The time required for the -PowerPC to vector an interrupt and for the RTEMS entry overhead -before invoking the user's trap handler are a total of -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case interrupt -latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. -[NOTE: The maximum period with interrupts disabled was last -determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -The maximum period with interrupts disabled within -RTEMS is hand-timed with some assistance from the PowerPC simulator. -The maximum period with interrupts disabled with RTEMS has not -been calculated on this target. - -The interrupt vector and entry overhead time was -generated on the PSIM benchmark platform using the PowerPC's -decrementer register. This register was programmed to generate -an interrupt after one countdown. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -bus cycle on the RTEMS_BSP benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The following table summarizes the context switch -times for the RTEMS_BSP benchmark platform: - diff --git a/doc/supplements/powerpc/timePSIM.t b/doc/supplements/powerpc/timePSIM.t deleted file mode 100644 index b0516c828b..0000000000 --- a/doc/supplements/powerpc/timePSIM.t +++ /dev/null @@ -1,97 +0,0 @@ -@c -@c Timing information for PSIM -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter RTEMS_BSP Timing Data - -@section Introduction - -The timing data for RTEMS on the RTEMS_BSP target -is provided along with the target -dependent aspects concerning the gathering of the timing data. -The hardware platform used to gather the times is described to -give the reader a better understanding of each directive time -provided. Also, provided is a description of the interrupt -latency and the context switch times as they pertain to the -PowerPC version of RTEMS. - -@section Hardware Platform - -All times reported in this chapter were measured using the PowerPC -Instruction Simulator (PSIM). PSIM simulates a variety of PowerPC -6xx models with the PPC603e being used as the basis for the measurements -reported in this chapter. - -The PowerPC decrementer register was was used to gather -all timing information. In real hardware implementations -of the PowerPC architecture, this register would typically -count something like CPU cycles or be a function of the clock -speed. However, with PSIM each count of the decrementer register -represents an instruction. Thus all measurements in this -chapter are reported as the actual number of instructions -executed. All sources of hardware interrupts were disabled, -although traps were enabled and the interrupt level of the -PowerPC allows all interrupts. - -@section Interrupt Latency - -The maximum period with traps disabled or the -processor interrupt level set to it's highest value inside RTEMS -is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions which -disable and re-enable interrupts. The time required for the -PowerPC to vector an interrupt and for the RTEMS entry overhead -before invoking the user's trap handler are a total of -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case interrupt -latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. -[NOTE: The maximum period with interrupts disabled was last -determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -The maximum period with interrupts disabled within -RTEMS is hand-timed with some assistance from RTEMS_BSP. The maximum -period with interrupts disabled with RTEMS occurs was not measured -on this target. - -The interrupt vector and entry overhead time was -generated on the RTEMS_BSP benchmark platform using the PowerPC's -decrementer register. This register was programmed to generate -an interrupt after one countdown. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -instructions on the RTEMS_BSP benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The following table summarizes the context switch -times for the RTEMS_BSP benchmark platform: diff --git a/doc/supplements/sh/.cvsignore b/doc/supplements/sh/.cvsignore deleted file mode 100644 index d18f3b9ad3..0000000000 --- a/doc/supplements/sh/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -sh -sh-? -sh-?? -sh.aux -sh.cp -sh.dvi -sh.fn -sh*.html -sh.ky -sh.log -sh.pdf -sh.pg -sh.ps -sh.toc -sh.tp -sh.vr -stamp-vti -timeBSP_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/sh/BSP_TIMES b/doc/supplements/sh/BSP_TIMES deleted file mode 100644 index 82b8160aa5..0000000000 --- a/doc/supplements/sh/BSP_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# CPU MODEL/BSP Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP BSPFORTIMES -RTEMS_CPU_MODEL BSP_CPU_MODEL -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 35 -RTEMS_RESTORE_1ST_FP_TASK 39 -RTEMS_SAVE_INIT_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_IDLE 68 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 148 -RTEMS_TASK_IDENT_ONLY 350 -RTEMS_TASK_START_ONLY 76 -RTEMS_TASK_RESTART_CALLING_TASK 95 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 -RTEMS_TASK_DELETE_CALLING_TASK 170 -RTEMS_TASK_DELETE_SUSPENDED_TASK 138 -RTEMS_TASK_DELETE_BLOCKED_TASK 143 -RTEMS_TASK_DELETE_READY_TASK 144 -RTEMS_TASK_SUSPEND_CALLING_TASK 71 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 -RTEMS_TASK_MODE_NO_RESCHEDULE 16 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 -RTEMS_TASK_GET_NOTE_ONLY 33 -RTEMS_TASK_SET_NOTE_ONLY 33 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 -RTEMS_TASK_WAKE_WHEN_ONLY 117 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 86 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 17 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 28 -RTEMS_TIMER_IDENT_ONLY 343 -RTEMS_TIMER_DELETE_INACTIVE 43 -RTEMS_TIMER_DELETE_ACTIVE 47 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 -RTEMS_TIMER_RESET_INACTIVE 54 -RTEMS_TIMER_RESET_ACTIVE 58 -RTEMS_TIMER_CANCEL_INACTIVE 31 -RTEMS_TIMER_CANCEL_ACTIVE 34 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 60 -RTEMS_SEMAPHORE_IDENT_ONLY 367 -RTEMS_SEMAPHORE_DELETE_ONLY 58 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 24 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 28 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 15 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 70 -RTEMS_PARTITION_IDENT_ONLY 341 -RTEMS_PARTITION_DELETE_ONLY 42 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 63 -RTEMS_REGION_IDENT_ONLY 348 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 35 -RTEMS_PORT_IDENT_ONLY 340 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 2 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 2 -RTEMS_IO_WRITE_ONLY 3 -RTEMS_IO_CONTROL_ONLY 2 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 723 -RTEMS_MINIMUM_CONFIGURATION 18,980 -RTEMS_MAXIMUM_CONFIGURATION 36,438 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 12,674 -RTEMS_INITIALIZATION_CODE_SIZE 970 -RTEMS_TASK_CODE_SIZE 3,562 -RTEMS_INTERRUPT_CODE_SIZE 54 -RTEMS_CLOCK_CODE_SIZE 334 -RTEMS_TIMER_CODE_SIZE 1,110 -RTEMS_SEMAPHORE_CODE_SIZE 1,632 -RTEMS_MESSAGE_CODE_SIZE 1,754 -RTEMS_EVENT_CODE_SIZE 1,000 -RTEMS_SIGNAL_CODE_SIZE 418 -RTEMS_PARTITION_CODE_SIZE 1,164 -RTEMS_REGION_CODE_SIZE 1,494 -RTEMS_DPMEM_CODE_SIZE 724 -RTEMS_IO_CODE_SIZE 686 -RTEMS_FATAL_ERROR_CODE_SIZE 24 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 -RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 184 -RTEMS_SEMAPHORE_CODE_OPTSIZE 172 -RTEMS_MESSAGE_CODE_OPTSIZE 288 -RTEMS_EVENT_CODE_OPTSIZE 56 -RTEMS_SIGNAL_CODE_OPTSIZE 56 -RTEMS_PARTITION_CODE_OPTSIZE 132 -RTEMS_REGION_CODE_OPTSIZE 160 -RTEMS_DPMEM_CODE_OPTSIZE 132 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 400 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 332 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/sh/ChangeLog b/doc/supplements/sh/ChangeLog deleted file mode 100644 index 5bbba06126..0000000000 --- a/doc/supplements/sh/ChangeLog +++ /dev/null @@ -1,76 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * sh.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * sh.texi: Set @setfilename sh.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-07-30 Joel Sherrill - - * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/sh/Makefile.am b/doc/supplements/sh/Makefile.am deleted file mode 100644 index 388173e524..0000000000 --- a/doc/supplements/sh/Makefile.am +++ /dev/null @@ -1,111 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = sh -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ - timeBSP.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = sh.texi -sh_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure - -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "BSP_FOR_TIMES Timing Data" < $< > $@ - -# Timing Data for BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t - cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t - @echo >>timeBSP_.t - @echo "@tex" >>timeBSP_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t - @echo "@end tex" >>timeBSP_.t - ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeBSP_.t - -EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeBSP.t - -CLEANFILES += sh.info sh.info-? diff --git a/doc/supplements/sh/bsp.t b/doc/supplements/sh/bsp.t deleted file mode 100644 index 657c359a96..0000000000 --- a/doc/supplements/sh/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of XXX specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the XXX processor is reset. When the -XXX is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 XXX's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 XXX version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the XXX remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -XXX from the interrupt state. - -@item 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. - -@item Must initialize the XXX's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/sh/callconv.t b/doc/supplements/sh/callconv.t deleted file mode 100644 index 89ac51db68..0000000000 --- a/doc/supplements/sh/callconv.t +++ /dev/null @@ -1,102 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -The Hitachi SH architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch to subroutine (XXX) or the jump to subroutine -(XXX) 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. - -@section Calling Mechanism - -All RTEMS directives are invoked using either a bsr -or jsr instruction and return to the user application via the -rts instruction. - -@section Register Usage - -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 -directive. - - -> > The SH1 has 16 general registers (r0..r15) -> > r0..r3 used as general volatile registers -> > r4..r7 used to pass up to 4 arguments to functions, arguments above 4 are -> > passed via the stack) -> > r8..13 caller saved registers (i.e. push them to the stack if you need them -> > inside of a function) -> > r14 frame pointer -> > r15 stack pointer -> - - -@section Parameter Passing - -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: - -@example -@group -push third argument -push second argument -push first argument -invoke directive -remove arguments from the stack -@end group -@end example - -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. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/sh/cpumodel.t b/doc/supplements/sh/cpumodel.t deleted file mode 100644 index c366970ae1..0000000000 --- a/doc/supplements/sh/cpumodel.t +++ /dev/null @@ -1,68 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/XXX/XXX.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the MODEL -processor, this macro is set to the string "XXX". - -@section Floating Point Unit - -The macro XXX_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. - -@section Another Optional Feature - -The macro XXX diff --git a/doc/supplements/sh/cputable.t b/doc/supplements/sh/cputable.t deleted file mode 100644 index 75d0fc15f6..0000000000 --- a/doc/supplements/sh/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The XXX version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the XXX. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - /* XXX CPU family dependent stuff */ -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item XXX -is where the CPU family dependent stuff goes. - -@end table diff --git a/doc/supplements/sh/fatalerr.t b/doc/supplements/sh/fatalerr.t deleted file mode 100644 index 53efad0435..0000000000 --- a/doc/supplements/sh/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is -no user handler configured or the user handler returns control to -RTEMS. The default fatal error handler disables processor interrupts, -places the error code in @b{XXX}, and executes a @code{XXX} -instruction to simulate a halt processor instruction. - diff --git a/doc/supplements/sh/intr_NOTIMES.t b/doc/supplements/sh/intr_NOTIMES.t deleted file mode 100644 index d642ce1ddf..0000000000 --- a/doc/supplements/sh/intr_NOTIMES.t +++ /dev/null @@ -1,196 +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 SH'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 SH family has two -different interrupt handling models. - -@subsection Models Without Separate Interrupt Stacks - -Upon receipt of an interrupt the SH 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 SH 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 -XXX 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 Interrupt Levels - -Eight levels (0-7) of interrupt priorities are -supported by XXX 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 -XXX family only supports eight. RTEMS interrupt levels 0 -through 7 directly correspond to XXX 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 XXX 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 XXX port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - diff --git a/doc/supplements/sh/memmodel.t b/doc/supplements/sh/memmodel.t deleted file mode 100644 index ef35072230..0000000000 --- a/doc/supplements/sh/memmodel.t +++ /dev/null @@ -1,39 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The XXX 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 this family. - -Some of the XXX family members such as the -XXX, XXX, and XXX support virtual memory and -segmentation. The XXX requires external hardware support -such as the XXX 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 XXX family members. - diff --git a/doc/supplements/sh/preface.texi b/doc/supplements/sh/preface.texi deleted file mode 100644 index 686a17b48d..0000000000 --- a/doc/supplements/sh/preface.texi +++ /dev/null @@ -1,55 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the VENDOR XXX -architecture dependencies in this port of RTEMS. The XXX -family has a wide variety of CPU models within it. The part -numbers ... - -XXX fill in some things here - -It is highly recommended that the XXX -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the family as a whole. - -@subheading Architecture Documents - -For information on the XXX architecture, -refer to the following documents available from VENDOR -(@file{http//www.XXX.com/}): - -@itemize @bullet -@item @cite{XXX Family Reference, VENDOR, PART NUMBER}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@end itemize - diff --git a/doc/supplements/sh/sh.texi b/doc/supplements/sh/sh.texi deleted file mode 100644 index 50dff26ec6..0000000000 --- a/doc/supplements/sh/sh.texi +++ /dev/null @@ -1,114 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename sh.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the Template Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS Hitachi SH Applications Supplement: (sh). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS Hitachi SH Applications Supplement - -@setchapternewpage odd -@settitle RTEMS Hitachi SH Applications Supplement -@titlepage -@finalout - -@title RTEMS Hitachi SH Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeBSP.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top sh - -This is the online version of the RTEMS Hitachi SH Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* BSP_FOR_TIMES Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, BSP_FOR_TIMES Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/sh/timeBSP.t b/doc/supplements/sh/timeBSP.t deleted file mode 100644 index 1439bb56bf..0000000000 --- a/doc/supplements/sh/timeBSP.t +++ /dev/null @@ -1,112 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter BSP_FOR_TIMES Timing Data - -@section Introduction - -The timing data for the SH version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the SH version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -BSP_FOR_TIMES CPU board. The BSP_FOR_TIMES is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with one wait -state dynamic memory and a XXX numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the XXX allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the XXX microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. It -should be noted that the worst case instruction times for the -processor assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the processor to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. The interrupt vector and entry -overhead time was generated on an BSP_FOR_TIMES benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the BSP_FOR_TIMES benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on whether an XXX or -XXX is being used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the BSP_FOR_TIMES benchmark platform: - diff --git a/doc/supplements/sparc/.cvsignore b/doc/supplements/sparc/.cvsignore deleted file mode 100644 index 9bbd58773d..0000000000 --- a/doc/supplements/sparc/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -sparc -sparc-? -sparc-?? -sparc.aux -sparc.cp -sparc.dvi -sparc.fn -sparc*.html -sparc.ky -sparc.log -sparc.pdf -sparc.pg -sparc.ps -sparc.toc -sparc.tp -sparc.vr -stamp-vti -timeERC32_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/sparc/ChangeLog b/doc/supplements/sparc/ChangeLog deleted file mode 100644 index ee5e300ac1..0000000000 --- a/doc/supplements/sparc/ChangeLog +++ /dev/null @@ -1,72 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * sparc.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * sparc.texi: Set @setfilename sparc.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/sparc/ERC32_TIMES b/doc/supplements/sparc/ERC32_TIMES deleted file mode 100644 index 4f9ce4c98b..0000000000 --- a/doc/supplements/sparc/ERC32_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# SPARC/ERC32/SIS Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP ERC32 -RTEMS_CPU_MODEL ERC32 -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 15.0 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.2.0-prerelease -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 21 -RTEMS_RESTORE_1ST_FP_TASK 26 -RTEMS_SAVE_INIT_RESTORE_INIT 24 -RTEMS_SAVE_IDLE_RESTORE_INIT 23 -RTEMS_SAVE_IDLE_RESTORE_IDLE 33 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 59 -RTEMS_TASK_IDENT_ONLY 163 -RTEMS_TASK_START_ONLY 30 -RTEMS_TASK_RESTART_CALLING_TASK 64 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 36 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 47 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 37 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 77 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 84 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 75 -RTEMS_TASK_DELETE_CALLING_TASK 91 -RTEMS_TASK_DELETE_SUSPENDED_TASK 47 -RTEMS_TASK_DELETE_BLOCKED_TASK 50 -RTEMS_TASK_DELETE_READY_TASK 51 -RTEMS_TASK_SUSPEND_CALLING_TASK 56 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 16 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 17 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 52 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 10 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 25 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 67 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 5 -RTEMS_TASK_MODE_NO_RESCHEDULE 6 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 9 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 42 -RTEMS_TASK_GET_NOTE_ONLY 10 -RTEMS_TASK_SET_NOTE_ONLY 10 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 6 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 49 -RTEMS_TASK_WAKE_WHEN_ONLY 75 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 7 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED 5 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 7 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 14 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 33 -RTEMS_CLOCK_GET_ONLY 4 -RTEMS_CLOCK_TICK_ONLY 6 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 11 -RTEMS_TIMER_IDENT_ONLY 159 -RTEMS_TIMER_DELETE_INACTIVE 15 -RTEMS_TIMER_DELETE_ACTIVE 17 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 21 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 23 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 34 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 34 -RTEMS_TIMER_RESET_INACTIVE 20 -RTEMS_TIMER_RESET_ACTIVE 22 -RTEMS_TIMER_CANCEL_INACTIVE 10 -RTEMS_TIMER_CANCEL_ACTIVE 13 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 19 -RTEMS_SEMAPHORE_IDENT_ONLY 171 -RTEMS_SEMAPHORE_DELETE_ONLY 19 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 12 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 12 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 14 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 23 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 57 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 114 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 159 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 25 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 36 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 38 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 76 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 36 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 38 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 76 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 15 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 42 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 83 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 30 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 13 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 9 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 13 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 9 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 22 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 58 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 10 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 9 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 60 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 6 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 14 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 22 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 27 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 56 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 34 -RTEMS_PARTITION_IDENT_ONLY 159 -RTEMS_PARTITION_DELETE_ONLY 14 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 12 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 16 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 22 -RTEMS_REGION_IDENT_ONLY 162 -RTEMS_REGION_DELETE_ONLY 14 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 19 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 19 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 67 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 17 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 44 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 77 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 14 -RTEMS_PORT_IDENT_ONLY 159 -RTEMS_PORT_DELETE_ONLY 13 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 9 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 9 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 2 -RTEMS_IO_OPEN_ONLY 1 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 1 -RTEMS_IO_WRITE_ONLY 1 -RTEMS_IO_CONTROL_ONLY 1 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 12 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 159 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 14 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 19 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 16 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 20 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 55 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 9 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 9059 -RTEMS_MINIMUM_CONFIGURATION 28,288 -RTEMS_MAXIMUM_CONFIGURATION 50,432 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 20,336 -RTEMS_INITIALIZATION_CODE_SIZE 1,408 -RTEMS_TASK_CODE_SIZE 4,496 -RTEMS_INTERRUPT_CODE_SIZE 72 -RTEMS_CLOCK_CODE_SIZE 576 -RTEMS_TIMER_CODE_SIZE 1,336 -RTEMS_SEMAPHORE_CODE_SIZE 1,888 -RTEMS_MESSAGE_CODE_SIZE 2,032 -RTEMS_EVENT_CODE_SIZE 1,696 -RTEMS_SIGNAL_CODE_SIZE 664 -RTEMS_PARTITION_CODE_SIZE 1,368 -RTEMS_REGION_CODE_SIZE 1,736 -RTEMS_DPMEM_CODE_SIZE 872 -RTEMS_IO_CODE_SIZE 1,144 -RTEMS_FATAL_ERROR_CODE_SIZE 32 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,656 -RTEMS_MULTIPROCESSING_CODE_SIZE 8,328 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 208 -RTEMS_SEMAPHORE_CODE_OPTSIZE 192 -RTEMS_MESSAGE_CODE_OPTSIZE 320 -RTEMS_EVENT_CODE_OPTSIZE 64 -RTEMS_SIGNAL_CODE_OPTSIZE 64 -RTEMS_PARTITION_CODE_OPTSIZE 152 -RTEMS_REGION_CODE_OPTSIZE 176 -RTEMS_DPMEM_CODE_OPTSIZE 152 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 208 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 408 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 488 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 136 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 10,072 diff --git a/doc/supplements/sparc/Makefile.am b/doc/supplements/sparc/Makefile.am deleted file mode 100644 index 14ec898a66..0000000000 --- a/doc/supplements/sparc/Makefile.am +++ /dev/null @@ -1,108 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = sparc -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi timing.texi wksheets.texi \ - timeERC32.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi - -FILES = preface.texi - -info_TEXINFOS = sparc.texi -sparc_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features CPU Model Implementation Notes" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t ERC32_TIMES - ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t ERC32_TIMES - ${REPLACE2} -p $(srcdir)/ERC32_TIMES $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "ERC32 Timing Data" < $< > $@ - -# Timing Data for ERC32 BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeERC32.texi: $(top_srcdir)/common/timetbl.t timeERC32.t - cat $(srcdir)/timeERC32.t $(top_srcdir)/common/timetbl.t >timeERC32_.t - @echo >>timeERC32_.t - @echo "@tex" >>timeERC32_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeERC32_.t - @echo "@end tex" >>timeERC32_.t - ${REPLACE2} -p $(srcdir)/ERC32_TIMES timeERC32_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeERC32_.t - -EXTRA_DIST = ERC32_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeERC32.t - -CLEANFILES += sparc.info sparc.info-? diff --git a/doc/supplements/sparc/bsp.t b/doc/supplements/sparc/bsp.t deleted file mode 100644 index 8810614825..0000000000 --- a/doc/supplements/sparc/bsp.t +++ /dev/null @@ -1,87 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of SPARC specific BSP issues. -For more information on developing a BSP, refer to the chapter -titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the SPARC processor is reset. When the SPARC -is reset, the processor performs the following actions: - -@itemize @bullet -@item the enable trap (ET) of the psr is set to 0 to disable -traps, - -@item the supervisor bit (S) of the psr is set to 1 to enter -supervisor mode, and - -@item the PC is set 0 and the nPC is set to 4. -@end itemize - -The processor then begins to execute the code at -location 0. It is important to note that all fields in the psr -are not explicitly set by the above steps and all other -registers retain their value from the previous execution mode. -This is true even of the Trap Base Register (TBR) whose contents -reflect the last trap which occurred before the reset. - -@section Processor Initialization - -It is the responsibility of the application's -initialization code to initialize the TBR and install trap -handlers for at least the register window overflow and register -window underflow conditions. Traps should be enabled before -invoking any subroutines to allow for register window -management. However, interrupts should be disabled by setting -the Processor Interrupt Level (pil) field of the psr to 15. -RTEMS installs it's own Trap Table as part of initialization -which is initialized with the contents of the Trap Table in -place when the @code{rtems_initialize_executive} directive was invoked. -Upon completion of executive initialization, interrupts are -enabled. - -If this SPARC implementation supports on-chip caching -and this 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 @value{LANGUAGE} -Applications User's Manual for the reset code -which is executed before the call to -@code{rtems_initialize_executive}, the SPARC version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the SPARC remains in the supervisor state. - -@item Must set stack pointer (sp) such that a minimum stack -size of MINIMUM_STACK_SIZE bytes is provided for the -@code{rtems_initialize_executive} directive. - -@item Must disable all external interrupts (i.e. set the pil -to 15). - -@item Must enable traps so window overflow and underflow -conditions can be properly handled. - -@item Must initialize the SPARC's initial trap table with at -least trap handlers for register window overflow and register -window underflow. -@end itemize - diff --git a/doc/supplements/sparc/callconv.t b/doc/supplements/sparc/callconv.t deleted file mode 100644 index 2b968ebb0b..0000000000 --- a/doc/supplements/sparc/callconv.t +++ /dev/null @@ -1,392 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage - -@item parameter passing - -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Programming Model - -This section discusses the programming model for the -SPARC architecture. - -@subsection Non-Floating Point Registers - -The SPARC architecture defines thirty-two -non-floating point registers directly visible to the programmer. -These are divided into four sets: - -@itemize @bullet -@item input registers - -@item local registers - -@item output registers - -@item global registers -@end itemize - -Each register is referred to by either two or three -names in the SPARC reference manuals. First, the registers are -referred to as r0 through r31 or with the alternate notation -r[0] through r[31]. Second, each register is a member of one of -the four sets listed above. Finally, some registers have an -architecturally defined role in the programming model which -provides an alternate name. The following table describes the -mapping between the 32 registers and the register sets: - -@ifset use-ascii -@example -@group - +-----------------+----------------+------------------+ - | Register Number | Register Names | Description | - +-----------------+----------------+------------------+ - | 0 - 7 | g0 - g7 | Global Registers | - +-----------------+----------------+------------------+ - | 8 - 15 | o0 - o7 | Output Registers | - +-----------------+----------------+------------------+ - | 16 - 23 | l0 - l7 | Local Registers | - +-----------------+----------------+------------------+ - | 24 - 31 | i0 - i7 | Input Registers | - +-----------------+----------------+------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} -&0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} -&8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} -&16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} -&24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - - - - - - - - -
Register NumberRegister NamesDescription
0 - 7g0 - g7Global Registers
8 - 15o0 - o7Output Registers
16 - 23l0 - l7Local Registers
24 - 31i0 - i7Input Registers
-
-@end html -@end ifset - -As mentioned above, some of the registers serve -defined roles in the programming model. The following table -describes the role of each of these registers: - -@ifset use-ascii -@example -@group - +---------------+----------------+----------------------+ - | Register Name | Alternate Name | Description | - +---------------+----------------+----------------------+ - | g0 | na | reads return 0 | - | | | writes are ignored | - +---------------+----------------+----------------------+ - | o6 | sp | stack pointer | - +---------------+----------------+----------------------+ - | i6 | fp | frame pointer | - +---------------+----------------+----------------------+ - | i7 | na | return address | - +---------------+----------------+----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} -&g0&&NA&&reads return 0; &\cr -&&&&&writes are ignored&\cr\noalign{\hrule} -&o6&&sp&&stack pointer&\cr\noalign{\hrule} -&i6&&fp&&frame pointer&\cr\noalign{\hrule} -&i7&&NA&&return address&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - - - - - - - - -
Register NameAlternate NameDescription
g0NAreads return 0 ; writes are ignored
o6spstack pointer
i6fpframe pointer
i7NAreturn address
-
-@end html -@end ifset - - -@subsection Floating Point Registers - -The SPARC V7 architecture includes thirty-two, -thirty-two bit registers. These registers may be viewed as -follows: - -@itemize @bullet -@item 32 single precision floating point or integer registers -(f0, f1, ... f31) - -@item 16 double precision floating point registers (f0, f2, -f4, ... f30) - -@item 8 extended precision floating point registers (f0, f4, -f8, ... f28) -@end itemize - -The floating point status register (fpsr) specifies -the behavior of the floating point unit for rounding, contains -its condition codes, version specification, and trap information. - -A queue of the floating point instructions which have -started execution but not yet completed is maintained. This -queue is needed to support the multiple cycle nature of floating -point operations and to aid floating point exception trap -handlers. Once a floating point exception has been encountered, -the queue is frozen until it is emptied by the trap handler. -The floating point queue is loaded by launching instructions. -It is emptied normally when the floating point completes all -outstanding instructions and by floating point exception -handlers with the store double floating point queue (stdfq) -instruction. - -@subsection Special Registers - -The SPARC architecture includes two special registers -which are critical to the programming model: the Processor State -Register (psr) and the Window Invalid Mask (wim). The psr -contains the condition codes, processor interrupt level, trap -enable bit, supervisor mode and previous supervisor mode bits, -version information, floating point unit and coprocessor enable -bits, and the current window pointer (cwp). The cwp field of -the psr and wim register are used to manage the register windows -in the SPARC architecture. The register windows are discussed -in more detail below. - -@section Register Windows - -The SPARC architecture includes the concept of -register windows. An overly simplistic way to think of these -windows is to imagine them as being an infinite supply of -"fresh" register sets available for each subroutine to use. In -reality, they are much more complicated. - -The save instruction is used to obtain a new register -window. This instruction decrements the current window pointer, -thus providing a new set of registers for use. This register -set includes eight fresh local registers for use exclusively by -this subroutine. When done with a register set, the restore -instruction increments the current window pointer and the -previous register set is once again available. - -The two primary issues complicating the use of -register windows are that (1) the set of register windows is -finite, and (2) some registers are shared between adjacent -registers windows. - -Because the set of register windows is finite, it is -possible to execute enough save instructions without -corresponding restore's to consume all of the register windows. -This is easily accomplished in a high level language because -each subroutine typically performs a save instruction upon -entry. Thus having a subroutine call depth greater than the -number of register windows will result in a window overflow -condition. The window overflow condition generates a trap which -must be handled in software. The window overflow trap handler -is responsible for saving the contents of the oldest register -window on the program stack. - -Similarly, the subroutines will eventually complete -and begin to perform restore's. If the restore results in the -need for a register window which has previously been written to -memory as part of an overflow, then a window underflow condition -results. Just like the window overflow, the window underflow -condition must be handled in software by a trap handler. The -window underflow trap handler is responsible for reloading the -contents of the register window requested by the restore -instruction from the program stack. - -The Window Invalid Mask (wim) and the Current Window -Pointer (cwp) field in the psr are used in conjunction to manage -the finite set of register windows and detect the window -overflow and underflow conditions. The cwp contains the index -of the register window currently in use. The save instruction -decrements the cwp modulo the number of register windows. -Similarly, the restore instruction increments the cwp modulo the -number of register windows. Each bit in the wim represents -represents whether a register window contains valid information. -The value of 0 indicates the register window is valid and 1 -indicates it is invalid. When a save instruction causes the cwp -to point to a register window which is marked as invalid, a -window overflow condition results. Conversely, the restore -instruction may result in a window underflow condition. - -Other than the assumption that a register window is -always available for trap (i.e. interrupt) handlers, the SPARC -architecture places no limits on the number of register windows -simultaneously marked as invalid (i.e. number of bits set in the -wim). However, RTEMS assumes that only one register window is -marked invalid at a time (i.e. only one bit set in the wim). -This makes the maximum possible number of register windows -available to the user while still meeting the requirement that -window overflow and underflow conditions can be detected. - -The window overflow and window underflow trap -handlers are a critical part of the run-time environment for a -SPARC application. The SPARC architectural specification allows -for the number of register windows to be any power of two less -than or equal to 32. The most common choice for SPARC -implementations appears to be 8 register windows. This results -in the cwp ranging in value from 0 to 7 on most implementations. - - -The second complicating factor is the sharing of -registers between adjacent register windows. While each -register window has its own set of local registers, the input -and output registers are shared between adjacent windows. The -output registers for register window N are the same as the input -registers for register window ((N - 1) modulo RW) where RW is -the number of register windows. An alternative way to think of -this is to remember how parameters are passed to a subroutine on -the SPARC. The caller loads values into what are its output -registers. Then after the callee executes a save instruction, -those parameters are available in its input registers. This is -a very efficient way to pass parameters as no data is actually -moved by the save or restore instructions. - -@section Call and Return Mechanism - -The SPARC architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the call (call) instruction. This instruction places the -return address in the caller's output register 7 (o7). After -the callee executes a save instruction, this value is available -in input register 7 (i7) until the corresponding restore -instruction is executed. - -The callee returns to the caller via a jmp to the -return address. There is a delay slot following this -instruction which is commonly used to execute a restore -instruction -- if a register window was allocated by this -subroutine. - -It is important to note that the SPARC subroutine -call and return mechanism does not automatically save and -restore any registers. This is accomplished via the save and -restore instructions which manage the set of registers windows. - -@section Calling Mechanism - -All RTEMS directives are invoked using the regular -SPARC calling convention via the call instruction. - -@section Register Usage - -As discussed above, the call instruction does not -automatically save any registers. The save and restore -instructions are used to allocate and deallocate register -windows. When a register window is allocated, the new set of -local registers are available for the exclusive use of the -subroutine which allocated this register set. - -@section Parameter Passing - -RTEMS assumes that arguments are placed in the -caller's output registers with the first argument in output -register 0 (o0), the second argument in output register 1 (o1), -and so forth. Until the callee executes a save instruction, the -parameters are still visible in the output registers. After the -callee executes a save instruction, the parameters are visible -in the corresponding input registers. The following pseudo-code -illustrates the typical sequence used to call a RTEMS directive -with three (3) arguments: - -@example -load third argument into o2 -load second argument into o1 -load first argument into o0 -invoke directive -@end example - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/sparc/cpumodel.t b/doc/supplements/sparc/cpumodel.t deleted file mode 100644 index d676fcc480..0000000000 --- a/doc/supplements/sparc/cpumodel.t +++ /dev/null @@ -1,128 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. - -@section CPU Model Feature Flags - -Each processor family supported by RTEMS has a -list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This section presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/sparc/sparc.h based upon the particular CPU -model defined on the compilation command line. - -@subsection CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the European Space -Agency's ERC32 SPARC model, this macro is set to the string -"erc32". - -@subsection Floating Point Unit - -The macro SPARC_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. - -@subsection Bitscan Instruction - -The macro SPARC_HAS_BITSCAN is set to 1 to indicate -that this CPU model has the bitscan instruction. For example, -this instruction is supported by the Fujitsu SPARClite family. - -@subsection Number of Register Windows - -The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to -indicate the number of register window sets implemented by this -CPU model. The SPARC architecture allows a for a maximum of -thirty-two register window sets although most implementations -only include eight. - -@subsection Low Power Mode - -The macro SPARC_HAS_LOW_POWER_MODE is set to one to -indicate that this CPU model has a low power mode. If low power -is enabled, then there must be CPU model specific implementation -of the IDLE task in cpukit/score/cpu/sparc/cpu.c. The low -power mode IDLE task should be of the form: - -@example -while ( TRUE ) @{ - enter low power mode -@} -@end example - -The code required to enter low power mode is CPU model specific. - -@section CPU Model Implementation Notes - -The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602 -chipset. This CPU has a number of on-board peripherals and was developed by -the European Space Agency to target space applications. RTEMS currently -provides support for the following peripherals: - -@itemize @bullet -@item UART Channels A and B -@item General Purpose Timer -@item Real Time Clock -@item Watchdog Timer (so it can be disabled) -@item Control Register (so powerdown mode can be enabled) -@item Memory Control Register -@item Interrupt Control -@end itemize - -The General Purpose Timer and Real Time Clock Timer provided with the ERC32 -share the Timer Control Register. Because the Timer Control Register is write -only, we must mirror it in software and insure that writes to one timer do not -alter the current settings and status of the other timer. Routines are -provided in erc32.h which promote the view that the two timers are completely -independent. By exclusively using these routines to access the Timer Control -Register, the application can view the system as having a General Purpose -Timer Control Register and a Real Time Clock Timer Control Register -rather than the single shared value. - -The RTEMS Idle thread take advantage of the low power mode provided by the -ERC32. Low power mode is entered during idle loops and is enabled at -initialization time. diff --git a/doc/supplements/sparc/cputable.t b/doc/supplements/sparc/cputable.t deleted file mode 100644 index 22873590c1..0000000000 --- a/doc/supplements/sparc/cputable.t +++ /dev/null @@ -1,102 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The SPARC version of the RTEMS CPU Dependent -Information Table is given by the C structure definition is -shown below: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS allocated interrupt stack in bytes. -This value must be at least as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@end table - diff --git a/doc/supplements/sparc/fatalerr.t b/doc/supplements/sparc/fatalerr.t deleted file mode 100644 index 6de94ba8f4..0000000000 --- a/doc/supplements/sparc/fatalerr.t +++ /dev/null @@ -1,32 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts to -level 15, places the error code in g1, and goes into an infinite -loop to simulate a halt processor instruction. - - diff --git a/doc/supplements/sparc/intr_NOTIMES.t b/doc/supplements/sparc/intr_NOTIMES.t deleted file mode 100644 index a66ccc981d..0000000000 --- a/doc/supplements/sparc/intr_NOTIMES.t +++ /dev/null @@ -1,199 +0,0 @@ -@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 SPARC's -interrupt response and control mechanisms as they pertain to -RTEMS. - -RTEMS and associated documentation uses the terms -interrupt and vector. In the SPARC architecture, these terms -correspond to traps and trap type, respectively. The terms will -be used interchangeably in this manual. - -@section Synchronous Versus Asynchronous Traps - -The SPARC architecture includes two classes of traps: -synchronous and asynchronous. Asynchronous traps occur when an -external event interrupts the processor. These traps are not -associated with any instruction executed by the processor and -logically occur between instructions. The instruction currently -in the execute stage of the processor is allowed to complete -although subsequent instructions are annulled. The return -address reported by the processor for asynchronous traps is the -pair of instructions following the current instruction. - -Synchronous traps are caused by the actions of an -instruction. The trap stimulus in this case either occurs -internally to the processor or is from an external signal that -was provoked by the instruction. These traps are taken -immediately and the instruction that caused the trap is aborted -before any state changes occur in the processor itself. The -return address reported by the processor for synchronous traps -is the instruction which caused the trap and the following -instruction. - -@section Vectoring of Interrupt Handler - -Upon receipt of an interrupt the SPARC automatically -performs the following actions: - -@itemize @bullet -@item disables traps (sets the ET bit of the psr to 0), - -@item the S bit of the psr is copied into the Previous -Supervisor Mode (PS) bit of the psr, - -@item the cwp is decremented by one (modulo the number of -register windows) to activate a trap window, - -@item the PC and nPC are loaded into local register 1 and 2 -(l0 and l1), - -@item the trap type (tt) field of the Trap Base Register (TBR) -is set to the appropriate value, and - -@item if the trap is not a reset, then the PC is written with -the contents of the TBR and the nPC is written with TBR + 4. If -the trap is a reset, then the PC is set to zero and the nPC is -set to 4. -@end itemize - -Trap processing on the SPARC has two features which -are noticeably different than interrupt processing on other -architectures. First, the value of psr register in effect -immediately before the trap occurred is not explicitly saved. -Instead only reversible alterations are made to it. Second, the -Processor Interrupt Level (pil) is not set to correspond to that -of the interrupt being processed. When a trap occurs, ALL -subsequent traps are disabled. In order to safely invoke a -subroutine during trap handling, traps must be enabled to allow -for the possibility of register window overflow and underflow -traps. - -If the interrupt handler was installed as an RTEMS -interrupt handler, then upon receipt of the interrupt, the -processor passes control to the RTEMS interrupt handler which -performs the following actions: - -@itemize @bullet -@item saves the state of the interrupted task on it's stack, - -@item insures that a register window is available for -subsequent traps, - -@item if this is the outermost (i.e. non-nested) interrupt, -then the RTEMS interrupt handler switches from the current stack -to the interrupt stack, - -@item enables traps, - -@item invokes the vectors to a user interrupt service routine (ISR). -@end itemize - -Asynchronous interrupts are ignored while traps are -disabled. Synchronous traps which occur while traps are -disabled result in the CPU being forced into an error mode. - -A nested interrupt is processed similarly with the -exception that the current stack need not be switched to the -interrupt stack. - -@section Traps and Register Windows - -One of the register windows must be reserved at all -times for trap processing. This is critical to the proper -operation of the trap mechanism in the SPARC architecture. It -is the responsibility of the trap handler to insure that there -is a register window available for a subsequent trap before -re-enabling traps. It is likely that any high level language -routines invoked by the trap handler (such as a user-provided -RTEMS interrupt handler) will allocate a new register window. -The save operation could result in a window overflow trap. This -trap cannot be correctly processed unless (1) traps are enabled -and (2) a register window is reserved for traps. Thus, the -RTEMS interrupt handler insures that a register window is -available for subsequent traps before enabling traps and -invoking the user's interrupt handler. - -@section Interrupt Levels - -Sixteen levels (0-15) of interrupt priorities are -supported by the SPARC architecture with level fifteen (15) -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 -SPARC only supports sixteen. RTEMS interrupt levels 0 through -15 directly correspond to SPARC processor 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 (15) -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 ERC32 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.] - -[NOTE: It is thought that the length of time at which -the processor interrupt level is elevated to fifteen by RTEMS is -not anywhere near as long as the length of time ALL traps are -disabled as part of the "flush all register windows" operation.] - -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 - -The SPARC architecture does not provide for a -dedicated interrupt stack. Thus by default, trap handlers would -execute on the stack of the RTEMS task which they interrupted. -This artificially inflates the stack requirements for each task -since EVERY task stack would have to include enough space to -account for the worst case interrupt stack requirements in -addition to it's own worst case usage. RTEMS addresses this -problem on the SPARC by providing a dedicated interrupt stack -managed by software. - -During system initialization, 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. As -part of processing a non-nested interrupt, RTEMS will switch to -the interrupt stack before invoking the installed handler. - diff --git a/doc/supplements/sparc/memmodel.t b/doc/supplements/sparc/memmodel.t deleted file mode 100644 index 7bf814ffa8..0000000000 --- a/doc/supplements/sparc/memmodel.t +++ /dev/null @@ -1,104 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The SPARC architecture 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, half-word (2-bytes), word (4 bytes), or doubleword -(8 bytes). Memory accesses within this address space are -performed in big endian fashion by the SPARC. Memory accesses -which are not properly aligned generate a "memory address not -aligned" trap (type number 7). The following table lists the -alignment requirements for a variety of data accesses: - -@ifset use-ascii -@example -@group - +--------------+-----------------------+ - | Data Type | Alignment Requirement | - +--------------+-----------------------+ - | byte | 1 | - | half-word | 2 | - | word | 4 | - | doubleword | 8 | - +--------------+-----------------------+ -@end group -@end example -@end ifset - -@ifset use-tex -@sp 1 -@tex -\centerline{\vbox{\offinterlineskip\halign{ -\vrule\strut#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#& -\hbox to 1.75in{\enskip\hfil#\hfil}& -\vrule#\cr -\noalign{\hrule} -&\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} -&byte&&1&\cr\noalign{\hrule} -&half-word&&2&\cr\noalign{\hrule} -&word&&4&\cr\noalign{\hrule} -&doubleword&&8&\cr\noalign{\hrule} -}}\hfil} -@end tex -@end ifset - -@ifset use-html -@html -
- - - - - - - - - - - -
Data TypeAlignment Requirement
byte1
half-word2
word4
doubleword8
-
-@end html -@end ifset - -Doubleword load and store operations must use a pair -of registers as their source or destination. This pair of -registers must be an adjacent pair of registers with the first -of the pair being even numbered. For example, a valid -destination for a doubleword load might be input registers 0 and -1 (i0 and i1). The pair i1 and i2 would be invalid. [NOTE: -Some assemblers for the SPARC do not generate an error if an odd -numbered register is specified as the beginning register of the -pair. In this case, the assembler assumes that what the -programmer meant was to use the even-odd pair which ends at the -specified register. This may or may not have been a correct -assumption.] - -RTEMS does not support any SPARC Memory Management -Units, therefore, virtual memory or segmentation systems -involving the SPARC are not supported. - diff --git a/doc/supplements/sparc/preface.texi b/doc/supplements/sparc/preface.texi deleted file mode 100644 index c3415236cf..0000000000 --- a/doc/supplements/sparc/preface.texi +++ /dev/null @@ -1,91 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems -(RTEMS) is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the SPARC architecture -dependencies in this port of RTEMS. Currently, only -implementations of SPARC Version 7 are supported by RTEMS. - -It is highly recommended that the SPARC RTEMS -application developer obtain and become familiar with the -documentation for the processor being used as well as the -specification for the revision of the SPARC architecture which -corresponds to that processor. - -@subheading SPARC Architecture Documents - -For information on the SPARC architecture, refer to -the following documents available from SPARC International, Inc. -(http://www.sparc.com): - -@itemize @bullet -@item SPARC Standard Version 7. - -@item SPARC Standard Version 8. - -@item SPARC Standard Version 9. -@end itemize - -@subheading ERC32 Specific Information - -The European Space Agency's ERC32 is a three chip -computing core implementing a SPARC V7 processor and associated -support circuitry for embedded space applications. The integer -and floating-point units (90C601E & 90C602E) are based on the -Cypress 7C601 and 7C602, with additional error-detection and -recovery functions. The memory controller (MEC) implements -system support functions such as address decoding, memory -interface, DMA interface, UARTs, timers, interrupt control, -write-protection, memory reconfiguration and error-detection. -The core is designed to work at 25MHz, but using space qualified -memories limits the system frequency to around 15 MHz, resulting -in a performance of 10 MIPS and 2 MFLOPS. - -Information on the ERC32 and a number of development -support tools, such as the SPARC Instruction Simulator (SIS), -are freely available on the Internet. The following documents -and SIS are available via anonymous ftp or pointing your web -browser at ftp://ftp.estec.esa.nl/pub/ws/wsd/erc32. - -@itemize @bullet -@item ERC32 System Design Document - -@item MEC Device Specification -@end itemize - -Additionally, the SPARC RISC User's Guide from Matra -MHS documents the functionality of the integer and floating -point units including the instruction set information. To -obtain this document as well as ERC32 components and VHDL models -contact: - -@example -Matra MHS SA -3 Avenue du Centre, BP 309, -78054 St-Quentin-en-Yvelines, -Cedex, France -VOICE: +31-1-30607087 -FAX: +31-1-30640693 -@end example - -Amar Guennon (amar.guennon@@matramhs.fr) is familiar with the ERC32. - diff --git a/doc/supplements/sparc/sparc.texi b/doc/supplements/sparc/sparc.texi deleted file mode 100644 index 2ed4c3ab1c..0000000000 --- a/doc/supplements/sparc/sparc.texi +++ /dev/null @@ -1,113 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename sparc.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the SPARC Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS SPARC Applications Supplement: (sparc). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS SPARC Applications Supplement - -@setchapternewpage odd -@settitle RTEMS SPARC Applications Supplement -@titlepage -@finalout - -@title RTEMS SPARC Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeERC32.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top sparc - -This is the online version of the RTEMS SPARC Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* ERC32 Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, ERC32 Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/sparc/timeERC32.t b/doc/supplements/sparc/timeERC32.t deleted file mode 100644 index acece2b675..0000000000 --- a/doc/supplements/sparc/timeERC32.t +++ /dev/null @@ -1,120 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter ERC32 Timing Data - -@section Introduction - -The timing data for RTEMS on the ERC32 implementation -of the SPARC architecture is provided along with the target -dependent aspects concerning the gathering of the timing data. -The hardware platform used to gather the times is described to -give the reader a better understanding of each directive time -provided. Also, provided is a description of the interrupt -latency and the context switch times as they pertain to the -SPARC version of RTEMS. - -@section Hardware Platform - -All times reported in this chapter were measured -using the SPARC Instruction Simulator (SIS) developed by the -European Space Agency. SIS simulates the ERC32 -- a custom low -power implementation combining the Cypress 90C601 integer unit, -the Cypress 90C602 floating point unit, and a number of -peripherals such as counter timers, interrupt controller and a -memory controller. - -For the RTEMS tests, SIS is configured with the -following characteristics: - -@itemize @bullet -@item 15 Mhz clock speed - -@item 0 wait states for PROM accesses - -@item 0 wait states for RAM accesses -@end itemize - -The ERC32's General Purpose Timer was used to gather -all timing information. This timer was programmed to operate -with one microsecond accuracy. All sources of hardware -interrupts were disabled, although traps were enabled and the -interrupt level of the SPARC allows all interrupts. - -@section Interrupt Latency - -The maximum period with traps disabled or the -processor interrupt level set to it's highest value inside RTEMS -is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions which -disable and re-enable interrupts. The time required for the -ERC32 to vector an interrupt and for the RTEMS entry overhead -before invoking the user's trap handler are a total of -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case interrupt -latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD + -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz. -[NOTE: The maximum period with interrupts disabled was last -determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -The maximum period with interrupts disabled within -RTEMS is hand-timed with some assistance from SIS. The maximum -period with interrupts disabled with RTEMS occurs during a -context switch when traps are disabled to flush all the register -windows to memory. The length of time spent flushing the -register windows varies based on the number of windows which -must be flushed. Based on the information reported by SIS, it -takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to -flush the register windows. It takes approximately 41 CPU -cycles (2.73 microseconds) to flush each register window set to -memory. The register window flush operation is heavily memory -bound. - -[NOTE: All traps are disabled during the register -window flush thus disabling both software generate traps and -external interrupts. During a normal RTEMS critical section, -the processor interrupt level (pil) is raised to level 15 and -traps are left enabled. The longest path for a normal critical -section within RTEMS is less than 50 instructions.] - -The interrupt vector and entry overhead time was -generated on the SIS benchmark platform using the ERC32's -ability to forcibly generate an arbitrary interrupt as the -source of the "benchmark" interrupt. - -@section Context Switch - -The RTEMS processor context switch time is 10 -microseconds on the SIS benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The following table summarizes the context switch -times for the ERC32 benchmark platform: - diff --git a/doc/supplements/supplement.am b/doc/supplements/supplement.am deleted file mode 100644 index 62542391d1..0000000000 --- a/doc/supplements/supplement.am +++ /dev/null @@ -1,16 +0,0 @@ -## $Id$ - -## -## Makefile fragment common to all supplements//Makefile.ams -## - -REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2 - -html_projectdir = $(htmldir)/supplements/$(PROJECT) - -TEXI2WWW_ARGS=\ --I $(srcdir) -I $(top_srcdir) -I $(top_builddir) \ --dirfile ../../index.html \ --header rtems_header.html \ --footer rtems_footer.html \ --icons ../../images diff --git a/doc/supplements/template/.cvsignore b/doc/supplements/template/.cvsignore deleted file mode 100644 index 8407ae75d6..0000000000 --- a/doc/supplements/template/.cvsignore +++ /dev/null @@ -1,31 +0,0 @@ -index.html -intr.t -intr.texi -Makefile -Makefile.in -mdate-sh -rtems_footer.html -rtems_header.html -stamp-vti -template -template-? -template-?? -template.aux -template.cp -template.dvi -template.fn -template*.html -template.ky -template.log -template.pdf -template.pg -template.ps -template.toc -template.tp -template.vr -timeBSP_.t -timing.t -timing.texi -version.texi -wksheets.t -wksheets.texi diff --git a/doc/supplements/template/BSP_TIMES b/doc/supplements/template/BSP_TIMES deleted file mode 100644 index 10a86f288f..0000000000 --- a/doc/supplements/template/BSP_TIMES +++ /dev/null @@ -1,247 +0,0 @@ -# -# CPU MODEL/BSP Timing and Size Information -# -# $Id$ -# - -# -# CPU Model Information -# -RTEMS_BSP MYBSP -RTEMS_CPU_MODEL MYCPU -# -# Interrupt Latency -# -# NOTE: In general, the text says it is hand-calculated to be -# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -# Mhz and this was last calculated for Release -# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. -# -RTEMS_MAXIMUM_DISABLE_PERIOD TBD -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 20 -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD 4.0.0 -# -# Context Switch Times -# -RTEMS_NO_FP_CONTEXTS 35 -RTEMS_RESTORE_1ST_FP_TASK 39 -RTEMS_SAVE_INIT_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_INIT 66 -RTEMS_SAVE_IDLE_RESTORE_IDLE 68 -# -# Task Manager Times -# -RTEMS_TASK_CREATE_ONLY 148 -RTEMS_TASK_IDENT_ONLY 350 -RTEMS_TASK_START_ONLY 76 -RTEMS_TASK_RESTART_CALLING_TASK 95 -RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 89 -RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 124 -RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 92 -RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 125 -RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 149 -RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 142 -RTEMS_TASK_DELETE_CALLING_TASK 170 -RTEMS_TASK_DELETE_SUSPENDED_TASK 138 -RTEMS_TASK_DELETE_BLOCKED_TASK 143 -RTEMS_TASK_DELETE_READY_TASK 144 -RTEMS_TASK_SUSPEND_CALLING_TASK 71 -RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 43 -RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 45 -RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 67 -RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 31 -RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 64 -RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 106 -RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 14 -RTEMS_TASK_MODE_NO_RESCHEDULE 16 -RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 23 -RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 60 -RTEMS_TASK_GET_NOTE_ONLY 33 -RTEMS_TASK_SET_NOTE_ONLY 33 -RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 16 -RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 56 -RTEMS_TASK_WAKE_WHEN_ONLY 117 -# -# Interrupt Manager -# -RTEMS_INTR_ENTRY_RETURNS_TO_NESTED 12 -RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK 9 -RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK 9 -RTEMS_INTR_EXIT_RETURNS_TO_NESTED <1 -RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK 8 -RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK 54 -# -# Clock Manager -# -RTEMS_CLOCK_SET_ONLY 86 -RTEMS_CLOCK_GET_ONLY 1 -RTEMS_CLOCK_TICK_ONLY 17 -# -# Timer Manager -# -RTEMS_TIMER_CREATE_ONLY 28 -RTEMS_TIMER_IDENT_ONLY 343 -RTEMS_TIMER_DELETE_INACTIVE 43 -RTEMS_TIMER_DELETE_ACTIVE 47 -RTEMS_TIMER_FIRE_AFTER_INACTIVE 58 -RTEMS_TIMER_FIRE_AFTER_ACTIVE 61 -RTEMS_TIMER_FIRE_WHEN_INACTIVE 88 -RTEMS_TIMER_FIRE_WHEN_ACTIVE 88 -RTEMS_TIMER_RESET_INACTIVE 54 -RTEMS_TIMER_RESET_ACTIVE 58 -RTEMS_TIMER_CANCEL_INACTIVE 31 -RTEMS_TIMER_CANCEL_ACTIVE 34 -# -# Semaphore Manager -# -RTEMS_SEMAPHORE_CREATE_ONLY 60 -RTEMS_SEMAPHORE_IDENT_ONLY 367 -RTEMS_SEMAPHORE_DELETE_ONLY 58 -RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 38 -RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 109 -RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 44 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 66 -RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 87 -# -# Message Manager -# -RTEMS_MESSAGE_QUEUE_CREATE_ONLY 200 -RTEMS_MESSAGE_QUEUE_IDENT_ONLY 341 -RTEMS_MESSAGE_QUEUE_DELETE_ONLY 80 -RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 97 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 96 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 101 -RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 123 -RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 53 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 111 -RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 133 -RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 79 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 43 -RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 114 -RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 29 -RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 39 -# -# Event Manager -# -RTEMS_EVENT_SEND_NO_TASK_READIED 24 -RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 60 -RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 84 -RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 -RTEMS_EVENT_RECEIVE_AVAILABLE 28 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 23 -RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 84 -# -# Signal Manager -# -RTEMS_SIGNAL_CATCH_ONLY 15 -RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 37 -RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 55 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 37 -RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 54 -# -# Partition Manager -# -RTEMS_PARTITION_CREATE_ONLY 70 -RTEMS_PARTITION_IDENT_ONLY 341 -RTEMS_PARTITION_DELETE_ONLY 42 -RTEMS_PARTITION_GET_BUFFER_AVAILABLE 35 -RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 33 -RTEMS_PARTITION_RETURN_BUFFER_ONLY 43 -# -# Region Manager -# -RTEMS_REGION_CREATE_ONLY 63 -RTEMS_REGION_IDENT_ONLY 348 -RTEMS_REGION_DELETE_ONLY 39 -RTEMS_REGION_GET_SEGMENT_AVAILABLE 52 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 49 -RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 123 -RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 54 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 114 -RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 136 -# -# Dual-Ported Memory Manager -# -RTEMS_PORT_CREATE_ONLY 35 -RTEMS_PORT_IDENT_ONLY 340 -RTEMS_PORT_DELETE_ONLY 39 -RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 26 -RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 27 -# -# IO Manager -# -RTEMS_IO_INITIALIZE_ONLY 4 -RTEMS_IO_OPEN_ONLY 2 -RTEMS_IO_CLOSE_ONLY 1 -RTEMS_IO_READ_ONLY 2 -RTEMS_IO_WRITE_ONLY 3 -RTEMS_IO_CONTROL_ONLY 2 -# -# Rate Monotonic Manager -# -RTEMS_RATE_MONOTONIC_CREATE_ONLY 32 -RTEMS_RATE_MONOTONIC_IDENT_ONLY 341 -RTEMS_RATE_MONOTONIC_CANCEL_ONLY 39 -RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 51 -RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 48 -RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 54 -RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 74 -RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 31 -# -# Size Information -# -# -# xxx alloted for numbers -# -RTEMS_DATA_SPACE 723 -RTEMS_MINIMUM_CONFIGURATION 18,980 -RTEMS_MAXIMUM_CONFIGURATION 36,438 -# x,xxx alloted for numbers -RTEMS_CORE_CODE_SIZE 12,674 -RTEMS_INITIALIZATION_CODE_SIZE 970 -RTEMS_TASK_CODE_SIZE 3,562 -RTEMS_INTERRUPT_CODE_SIZE 54 -RTEMS_CLOCK_CODE_SIZE 334 -RTEMS_TIMER_CODE_SIZE 1,110 -RTEMS_SEMAPHORE_CODE_SIZE 1,632 -RTEMS_MESSAGE_CODE_SIZE 1,754 -RTEMS_EVENT_CODE_SIZE 1,000 -RTEMS_SIGNAL_CODE_SIZE 418 -RTEMS_PARTITION_CODE_SIZE 1,164 -RTEMS_REGION_CODE_SIZE 1,494 -RTEMS_DPMEM_CODE_SIZE 724 -RTEMS_IO_CODE_SIZE 686 -RTEMS_FATAL_ERROR_CODE_SIZE 24 -RTEMS_RATE_MONOTONIC_CODE_SIZE 1,212 -RTEMS_MULTIPROCESSING_CODE_SIZE 6.952 -# xxx alloted for numbers -RTEMS_TIMER_CODE_OPTSIZE 184 -RTEMS_SEMAPHORE_CODE_OPTSIZE 172 -RTEMS_MESSAGE_CODE_OPTSIZE 288 -RTEMS_EVENT_CODE_OPTSIZE 56 -RTEMS_SIGNAL_CODE_OPTSIZE 56 -RTEMS_PARTITION_CODE_OPTSIZE 132 -RTEMS_REGION_CODE_OPTSIZE 160 -RTEMS_DPMEM_CODE_OPTSIZE 132 -RTEMS_IO_CODE_OPTSIZE 00 -RTEMS_RATE_MONOTONIC_CODE_OPTSIZE 184 -RTEMS_MULTIPROCESSING_CODE_OPTSIZE 332 -# xxx alloted for numbers -RTEMS_BYTES_PER_TASK 400 -RTEMS_BYTES_PER_TIMER 68 -RTEMS_BYTES_PER_SEMAPHORE 124 -RTEMS_BYTES_PER_MESSAGE_QUEUE 148 -RTEMS_BYTES_PER_REGION 144 -RTEMS_BYTES_PER_PARTITION 56 -RTEMS_BYTES_PER_PORT 36 -RTEMS_BYTES_PER_PERIOD 36 -RTEMS_BYTES_PER_EXTENSION 64 -RTEMS_BYTES_PER_FP_TASK 332 -RTEMS_BYTES_PER_NODE 48 -RTEMS_BYTES_PER_GLOBAL_OBJECT 20 -RTEMS_BYTES_PER_PROXY 124 -# x,xxx alloted for numbers -RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS 8,872 diff --git a/doc/supplements/template/ChangeLog b/doc/supplements/template/ChangeLog deleted file mode 100644 index 7df694a6cc..0000000000 --- a/doc/supplements/template/ChangeLog +++ /dev/null @@ -1,76 +0,0 @@ -2003-12-12 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-12-11 Ralf Corsepius - - * Makefile.am: Cosmetics. - -2003-11-26 Ralf Corsepius - - * Makefile.am: Add *.info to CLEANFILES to accomodate - automake-1.7f/1.8 breaking building infos. - -2003-09-26 Joel Sherrill - - * cpumodel.t: Obsoleting HP PA-RISC port and removing all references. - -2003-09-22 Ralf Corsepius - - * Makefile.am: Merger from rtems-4-6-branch. - -2003-09-19 Joel Sherrill - - * template.texi: Merge from branch. - -2003-05-22 Ralf Corsepius - - * cpumodel.t: Reflect c/src/exec having moved to cpukit. - -2003-01-25 Ralf Corsepius - - * template.texi: Set @setfilename template.info. - -2003-01-24 Ralf Corsepius - - * Makefile.am: Put GENERATED_FILES into $builddir. - -2003-01-22 Ralf Corsepius - - * version.texi: Remove from CVS. - * stamp-vti: Remove from CVS. - * .cvsignore: Add version.texi. - Add stamp-vti. - Re-sort. - -2003-01-21 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-11-13 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-10-24 Joel Sherrill - - * stamp-vti, version.texi: Regenerated. - -2002-07-30 Joel Sherrill - - * intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info. - -2002-03-27 Ralf Corsepius - - * Makefile.am: Remove AUTOMAKE_OPTIONS. - -2002-01-18 Ralf Corsepius - - * Makefile.am: Require automake-1.5. - -2001-01-17 Joel Sherrill - - * .cvsignore: Added rtems_header.html and rtems_footer.html. - -2000-08-10 Joel Sherrill - - * ChangeLog: New file. diff --git a/doc/supplements/template/Makefile.am b/doc/supplements/template/Makefile.am deleted file mode 100644 index 27ecc24457..0000000000 --- a/doc/supplements/template/Makefile.am +++ /dev/null @@ -1,110 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. -# -# $Id$ -# - -PROJECT = template -EDITION = 1 - -include $(top_srcdir)/project.am -include $(top_srcdir)/supplements/supplement.am - -GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ - fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ - timeBSP.texi -COMMON_FILES += $(top_srcdir)/common/cpright.texi \ - $(top_srcdir)/common/timemac.texi - -FILES = preface.texi - -info_TEXINFOS = template.texi -template_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -# -# Chapters which get automatic processing -# - -cpumodel.texi: cpumodel.t - $(BMENU2) -p "Preface" \ - -u "Top" \ - -n "Calling Conventions" < $< > $@ - -callconv.texi: callconv.t - $(BMENU2) -p "CPU Model Dependent Features Another Optional Feature" \ - -u "Top" \ - -n "Memory Model" < $< > $@ - -memmodel.texi: memmodel.t - $(BMENU2) -p "Calling Conventions User-Provided Routines" \ - -u "Top" \ - -n "Interrupt Processing" < $< > $@ - -# Interrupt Chapter: -# 1. Replace Times and Sizes -# 2. Build Node Structure -intr.texi: intr_NOTIMES.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ - $(BMENU2) -p "Memory Model Flat Memory Model" \ - -u "Top" \ - -n "Default Fatal Error Processing" > $@ - -fatalerr.texi: fatalerr.t - $(BMENU2) -p "Interrupt Processing Interrupt Stack" \ - -u "Top" \ - -n "Board Support Packages" < $< > $@ - -bsp.texi: bsp.t - $(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ - -u "Top" \ - -n "Processor Dependent Information Table" < $< > $@ - -cputable.texi: cputable.t - $(BMENU2) -p "Board Support Packages Processor Initialization" \ - -u "Top" \ - -n "Memory Requirements" < $< > $@ - -# Worksheets Chapter: -# 1. Obtain the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES - ${REPLACE2} -p $(srcdir)/BSP_TIMES \ - $(top_srcdir)/common/wksheets.t | \ - $(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ - -u "Top" \ - -n "Timing Specification" > $@ - -# Timing Specification Chapter: -# 1. Copy the Shared File -# 3. Build Node Structure - -timing.texi: $(top_srcdir)/common/timing.t - $(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ - -u "Top" \ - -n "MYBSP Timing Data" < $< > $@ - -# Timing Data for BSP BSP Chapter: -# 1. Copy the Shared File -# 2. Replace Times and Sizes -# 3. Build Node Structure - -timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t - cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t - @echo >>timeBSP_.t - @echo "@tex" >>timeBSP_.t - @echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t - @echo "@end tex" >>timeBSP_.t - ${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ - $(BMENU2) -p "Timing Specification Terminology" \ - -u "Top" \ - -n "Command and Variable Index" > $@ -CLEANFILES += timeBSP_.t - -EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ - intr_NOTIMES.t memmodel.t timeBSP.t - -CLEANFILES += template.info template.info-? diff --git a/doc/supplements/template/bsp.t b/doc/supplements/template/bsp.t deleted file mode 100644 index 657c359a96..0000000000 --- a/doc/supplements/template/bsp.t +++ /dev/null @@ -1,93 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Board Support Packages - -@section Introduction - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of XXX specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - -@section System Reset - -An RTEMS based application is initiated or -re-initiated when the XXX processor is reset. When the -XXX is reset, the processor performs the following actions: - -@itemize @bullet -@item The tracing bits of the status register are cleared to -disable tracing. - -@item The supervisor interrupt state is entered by setting the -supervisor (S) bit and clearing the master/interrupt (M) bit of -the status register. - -@item The interrupt mask of the status register is set to -level 7 to effectively disable all maskable interrupts. - -@item The vector base register (VBR) is set to zero. - -@item The cache control register (CACR) is set to zero to -disable and freeze the processor cache. - -@item The interrupt stack pointer (ISP) is set to the value -stored at vector 0 (bytes 0-3) of the exception vector table -(EVT). - -@item The program counter (PC) is set to the value stored at -vector 1 (bytes 4-7) of the EVT. - -@item The processor begins execution at the address stored in -the PC. -@end itemize - -@section Processor Initialization - -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 XXX's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set before this directive -is invoked to insure 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 XXX version has the following -specific requirements: - -@itemize @bullet -@item Must leave the S bit of the status register set so that -the XXX remains in the supervisor state. - -@item Must set the M bit of the status register to remove the -XXX from the interrupt state. - -@item 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. - -@item Must initialize the XXX's vector table. -@end itemize - -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. - diff --git a/doc/supplements/template/callconv.t b/doc/supplements/template/callconv.t deleted file mode 100644 index 5387032c60..0000000000 --- a/doc/supplements/template/callconv.t +++ /dev/null @@ -1,92 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Calling Conventions - -@section Introduction - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@section Processor Background - -The MC68xxx architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch to subroutine (@code{XXX}) or the jump to subroutine -(@code{XXX}) instructions. These instructions push the return address -on the current stack. The return from subroutine (@code{XXX}) -instruction pops the return address off the current stack and -transfers control to that instruction. It is is important to -note that the XXX 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. - -@section Calling Mechanism - -All RTEMS directives are invoked using either a @code{XXX} -or @code{XXX} instruction and return to the user application via the -@code{XXX} instruction. - -@section Register Usage - -As discussed above, the @code{XXX} and @code{XXX} instructions do -not automatically save any registers. RTEMS uses the registers -@b{D0}, @b{D1}, @b{A0}, and @b{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 -directive. - -@section Parameter Passing - -RTEMS assumes that arguments are placed on the -current stack before the directive is invoked via the @code{XXX} or @code{XXX} -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: - -@example -@group -push third argument -push second argument -push first argument -invoke directive -remove arguments from the stack -@end group -@end example - -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. - -@section User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. - diff --git a/doc/supplements/template/cpumodel.t b/doc/supplements/template/cpumodel.t deleted file mode 100644 index c366970ae1..0000000000 --- a/doc/supplements/template/cpumodel.t +++ /dev/null @@ -1,68 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter CPU Model Dependent Features - -@section Introduction - -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. -The set of CPU model feature macros are defined in the file -cpukit/score/cpu/XXX/XXX.h based upon the particular CPU -model defined on the compilation command line. - -@section CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the MODEL -processor, this macro is set to the string "XXX". - -@section Floating Point Unit - -The macro XXX_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. - -@section Another Optional Feature - -The macro XXX diff --git a/doc/supplements/template/cputable.t b/doc/supplements/template/cputable.t deleted file mode 100644 index 75d0fc15f6..0000000000 --- a/doc/supplements/template/cputable.t +++ /dev/null @@ -1,109 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Processor Dependent Information Table - -@section Introduction - -Any highly processor dependent information required -to describe a processor to RTEMS is provided in the CPU -Dependent Information Table. This table is not required for all -processors supported by RTEMS. This chapter describes the -contents, if any, for a particular processor type. - -@section CPU Dependent Information Table - -The XXX version of the RTEMS CPU Dependent -Information Table contains the information required to interface -a Board Support Package and RTEMS on the XXX. This -information is provided to allow RTEMS to interoperate -effectively with the BSP. The C structure definition is given -here: - -@example -@group -typedef struct @{ - void (*pretasking_hook)( void ); - void (*predriver_hook)( void ); - void (*postdriver_hook)( void ); - void (*idle_task)( void ); - boolean do_zero_of_workspace; - unsigned32 idle_task_stack_size; - unsigned32 interrupt_stack_size; - unsigned32 extra_mpci_receive_server_stack; - void * (*stack_allocate_hook)( unsigned32 ); - void (*stack_free_hook)( void* ); - /* end of fields required on all CPUs */ - - /* XXX CPU family dependent stuff */ -@} rtems_cpu_table; -@end group -@end example - -@table @code -@item pretasking_hook -is the address of the user provided routine which is invoked -once RTEMS APIs are initialized. This routine will be invoked -before any system tasks are created. Interrupts are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item predriver_hook -is the address of the user provided -routine that is invoked immediately before the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item postdriver_hook -is the address of the user provided -routine that is invoked immediately after the -the device drivers and MPCI are initialized. RTEMS -initialization is complete but interrupts and tasking are disabled. -This field may be NULL to indicate that the hook is not utilized. - -@item idle_task -is the address of the optional user -provided routine which is used as the system's IDLE task. If -this field is not NULL, then the RTEMS default IDLE task is not -used. This field may be NULL to indicate that the default IDLE -is to be used. - -@item do_zero_of_workspace -indicates whether RTEMS should -zero the Workspace as part of its initialization. If set to -TRUE, the Workspace is zeroed. Otherwise, it is not. - -@item idle_task_stack_size -is the size of the RTEMS idle task stack in bytes. -If this number is less than MINIMUM_STACK_SIZE, then the -idle task's stack will be MINIMUM_STACK_SIZE in byte. - -@item interrupt_stack_size -is the size of the RTEMS -allocated interrupt stack in bytes. This value must be at least -as large as MINIMUM_STACK_SIZE. - -@item extra_mpci_receive_server_stack -is the extra stack space allocated for the RTEMS MPCI receive server task -in bytes. The MPCI receive server may invoke nearly all directives and -may require extra stack space on some targets. - -@item stack_allocate_hook -is the address of the optional user provided routine which allocates -memory for task stacks. If this hook is not NULL, then a stack_free_hook -must be provided as well. - -@item stack_free_hook -is the address of the optional user provided routine which frees -memory for task stacks. If this hook is not NULL, then a stack_allocate_hook -must be provided as well. - -@item XXX -is where the CPU family dependent stuff goes. - -@end table diff --git a/doc/supplements/template/fatalerr.t b/doc/supplements/template/fatalerr.t deleted file mode 100644 index 53efad0435..0000000000 --- a/doc/supplements/template/fatalerr.t +++ /dev/null @@ -1,31 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Default Fatal Error Processing - -@section Introduction - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@section Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the @code{rtems_fatal_error_occurred} directive when there is -no user handler configured or the user handler returns control to -RTEMS. The default fatal error handler disables processor interrupts, -places the error code in @b{XXX}, and executes a @code{XXX} -instruction to simulate a halt processor instruction. - diff --git a/doc/supplements/template/intr_NOTIMES.t b/doc/supplements/template/intr_NOTIMES.t deleted file mode 100644 index 13e4921ea9..0000000000 --- a/doc/supplements/template/intr_NOTIMES.t +++ /dev/null @@ -1,196 +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 processor'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 XXX family has two -different interrupt handling models. - -@subsection Models Without Separate Interrupt Stacks - -Upon receipt of an interrupt the XXX 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 XXX 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 -XXX 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 Interrupt Levels - -Eight levels (0-7) of interrupt priorities are -supported by XXX 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 -XXX family only supports eight. RTEMS interrupt levels 0 -through 7 directly correspond to XXX 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 XXX 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 XXX port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - diff --git a/doc/supplements/template/memmodel.t b/doc/supplements/template/memmodel.t deleted file mode 100644 index ef35072230..0000000000 --- a/doc/supplements/template/memmodel.t +++ /dev/null @@ -1,39 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@chapter Memory Model - -@section Introduction - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@section Flat Memory Model - -The XXX 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 this family. - -Some of the XXX family members such as the -XXX, XXX, and XXX support virtual memory and -segmentation. The XXX requires external hardware support -such as the XXX 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 XXX family members. - diff --git a/doc/supplements/template/preface.texi b/doc/supplements/template/preface.texi deleted file mode 100644 index 686a17b48d..0000000000 --- a/doc/supplements/template/preface.texi +++ /dev/null @@ -1,55 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@ifinfo -@node Preface, CPU Model Dependent Features, Top, Top -@end ifinfo -@unnumbered Preface - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the VENDOR XXX -architecture dependencies in this port of RTEMS. The XXX -family has a wide variety of CPU models within it. The part -numbers ... - -XXX fill in some things here - -It is highly recommended that the XXX -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the family as a whole. - -@subheading Architecture Documents - -For information on the XXX architecture, -refer to the following documents available from VENDOR -(@file{http//www.XXX.com/}): - -@itemize @bullet -@item @cite{XXX Family Reference, VENDOR, PART NUMBER}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@item @cite{XXX MODEL Manual, VENDOR, PART NUMBER}. -@end itemize - diff --git a/doc/supplements/template/template.texi b/doc/supplements/template/template.texi deleted file mode 100644 index a2b655fd63..0000000000 --- a/doc/supplements/template/template.texi +++ /dev/null @@ -1,115 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename template.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@c -@c Master file for the Template Applications Supplement -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS Target Supplements -@direntry -* RTEMS Template Applications Supplement: (template). -@end direntry -@end ifset - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS Template Applications Supplement - -@setchapternewpage odd -@settitle RTEMS Template Applications Supplement -@titlepage -@finalout - -@title RTEMS Template Applications Supplement -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page - -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@include preface.texi -@include cpumodel.texi -@include callconv.texi -@include memmodel.texi -@include intr.texi -@include fatalerr.texi -@include bsp.texi -@include cputable.texi -@include wksheets.texi -@include timing.texi -@include timeBSP.texi -@ifinfo -@node Top, Preface, (dir), (dir) -@top template - -This is the online version of the RTEMS Template -Applications Supplement. - -@menu -* Preface:: -* CPU Model Dependent Features:: -* Calling Conventions:: -* Memory Model:: -* Interrupt Processing:: -* Default Fatal Error Processing:: -* Board Support Packages:: -* Processor Dependent Information Table:: -* Memory Requirements:: -* Timing Specification:: -* MYBSP Timing Data:: -* Command and Variable Index:: -* Concept Index:: -@end menu - -@end ifinfo -@c -@c -@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here -@c - -@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@contents -@bye - diff --git a/doc/supplements/template/timeBSP.t b/doc/supplements/template/timeBSP.t deleted file mode 100644 index 85e5ea44aa..0000000000 --- a/doc/supplements/template/timeBSP.t +++ /dev/null @@ -1,112 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. -@c -@c $Id$ -@c - -@include common/timemac.texi -@tex -\global\advance \smallskipamount by -4pt -@end tex - -@chapter MYBSP Timing Data - -@section Introduction - -The timing data for the XXX version of RTEMS is -provided along with the target dependent aspects concerning the -gathering of the timing data. The hardware platform used to -gather the times is described to give the reader a better -understanding of each directive time provided. Also, provided -is a description of the interrupt latency and the context switch -times as they pertain to the XXX version of RTEMS. - -@section Hardware Platform - -All times reported except for the maximum period -interrupts are disabled by RTEMS were measured using a Motorola -MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz board with one wait -state dynamic memory and a XXX numeric coprocessor. The -Zilog 8036 countdown timer on this board was used to measure -elapsed time with a one-half microsecond resolution. All -sources of hardware interrupts were disabled, although the -interrupt level of the processor allows all interrupts. - -The maximum period interrupts are disabled was -measured by summing the number of CPU cycles required by each -assembly language instruction executed while interrupts were -disabled. The worst case times of the XXX microprocessor -were used for each instruction. Zero wait state memory was -assumed. The total CPU cycles executed with interrupts -disabled, including the instructions to disable and enable -interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. It -should be noted that the worst case instruction times for the -processor assume that the internal cache is disabled and that no -instructions overlap. - -@section Interrupt Latency - -The maximum period with interrupts disabled within -RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD -microseconds including the instructions -which disable and re-enable interrupts. The time required for -the processor to vector an interrupt and for the RTEMS entry -overhead before invoking the user's interrupt handler are a -total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds. These combine to yield a worst case -interrupt latency of less than -RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK -microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz. [NOTE: The maximum period with interrupts -disabled was last determined for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -It should be noted again that the maximum period with -interrupts disabled within RTEMS is hand-timed and based upon -worst case (i.e. CPU cache disabled and no instruction overlap) -times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ -Mhz processor. The interrupt vector and entry -overhead time was generated on an MYBSP benchmark platform -using the Multiprocessing Communications registers to generate -as the interrupt source. - -@section Context Switch - -The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS -microseconds on the MYBSP benchmark platform when no floating -point context is saved or restored. Additional execution time -is required when a TASK_SWITCH user extension is configured. -The use of the TASK_SWITCH extension is application dependent. -Thus, its execution time is not considered part of the raw -context switch time. - -Since RTEMS was designed specifically for embedded -missile applications which are floating point intensive, the -executive is optimized to avoid unnecessarily saving and -restoring the state of the numeric coprocessor. The state of -the numeric coprocessor is only saved when an FLOATING_POINT -task is dispatched and that task was not the last task to -utilize the coprocessor. In a system with only one -FLOATING_POINT task, the state of the numeric coprocessor will -never be saved or restored. When the first FLOATING_POINT task -is dispatched, RTEMS does not need to save the current state of -the numeric coprocessor. - -The exact amount of time required to save and restore -floating point context is dependent on whether an XXX or -XXX is being used as well as the state of the numeric -coprocessor. These numeric coprocessors define three operating -states: initialized, idle, and busy. RTEMS places the -coprocessor in the initialized state when a task is started or -restarted. Once the task has utilized the coprocessor, it is in -the idle state when floating point instructions are not -executing and the busy state when floating point instructions -are executing. The state of the coprocessor is task specific. - -The following table summarizes the context switch -times for the MYBSP benchmark platform: - -- cgit v1.2.3