linux/arch/m68k/ifpsp060/TEST.DOC
<<
>>
Prefs
   1~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   2MOTOROLA MICROPROCESSOR & MEMORY TECHNOLOGY GROUP
   3M68000 Hi-Performance Microprocessor Division
   4M68060 Software Package
   5Production Release P1.00 -- October 10, 1994
   6
   7M68060 Software Package Copyright © 1993, 1994 Motorola Inc.  All rights reserved.
   8
   9THE SOFTWARE is provided on an "AS IS" basis and without warranty.
  10To the maximum extent permitted by applicable law,
  11MOTOROLA DISCLAIMS ALL WARRANTIES WHETHER EXPRESS OR IMPLIED,
  12INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
  13and any warranty against infringement with regard to the SOFTWARE
  14(INCLUDING ANY MODIFIED VERSIONS THEREOF) and any accompanying written materials.
  15
  16To the maximum extent permitted by applicable law,
  17IN NO EVENT SHALL MOTOROLA BE LIABLE FOR ANY DAMAGES WHATSOEVER
  18(INCLUDING WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,
  19BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS)
  20ARISING OF THE USE OR INABILITY TO USE THE SOFTWARE.
  21Motorola assumes no responsibility for the maintenance and support of the SOFTWARE.
  22
  23You are hereby granted a copyright license to use, modify, and distribute the SOFTWARE
  24so long as this entire notice is retained without alteration in any modified and/or
  25redistributed versions, and that such modified versions are clearly identified as such.
  26No licenses are granted by implication, estoppel or otherwise under any patents
  27or trademarks of Motorola, Inc.
  28~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  2968060 SOFTWARE PACKAGE (Kernel version) SIMPLE TESTS
  30-----------------------------------------------------
  31
  32The files itest.sa and ftest.sa contain simple tests to check
  33the state of the 68060ISP and 68060FPSP once they have been installed.
  34
  35Release file format:
  36--------------------
  37The release files itest.sa and ftest.sa are essentially
  38hexadecimal images of the actual tests. This format is the
  39ONLY format that will be supported. The hex images were created
  40by assembling the source code and then converting the resulting
  41binary output images into ASCII text files. The hexadecimal
  42numbers are listed using the Motorola Assembly syntax assembler
  43directive "dc.l" (define constant longword). The files can be
  44converted to other assembly syntaxes by using any word processor
  45with a global search and replace function.
  46
  47To assist in assembling and linking these modules with other modules,
  48the installer should add symbolic labels to the top of the files.
  49This will allow the calling routines to access the entry points
  50of these packages.
  51
  52The source code itest.s and ftest.s have been included but only
  53for documentation purposes.
  54
  55Release file structure:
  56-----------------------
  57
  58(top of module)
  59        -----------------
  60        |               | - 128 byte-sized section
  61   (1)  |   Call-Out    | - 4 bytes per entry (user fills these in)
  62        |               |
  63        -----------------
  64        |               | - 8 bytes per entry
  65   (2)  | Entry Point   | - user does "bsr" or "jsr" to this address
  66        |               |
  67        -----------------
  68        |               | - code section
  69   (3)  ~               ~
  70        |               |
  71        -----------------
  72(bottom of module)
  73
  74The first section of this module is the "Call-out" section. This section
  75is NOT INCLUDED in {i,f}test.sa (an example "Call-out" section is provided at
  76the end of this file). The purpose of this section is to allow the test
  77routines to reference external printing functions that must be provided
  78by the host operating system. This section MUST be exactly 128 bytes in
  79size. There are 32 fields, each 4 bytes in size. Each field corresponds
  80to a function required by the test packages (these functions and their
  81location are listed in "68060{ISP,FPSP}-TEST call-outs" below). Each field
  82entry should contain the address of the corresponding function RELATIVE to
  83the starting address of the "call-out" section. The "Call-out" section must
  84sit adjacent to the {i,f}test.sa image in memory. Since itest.sa and ftest.sa
  85are individual tests, they each require their own "Call-out" sections.
  86
  87The second section, the "Entry-point" section, is used by external routines
  88to access the test routines. Since the {i,f}test.sa hex files contain
  89no symbol names, this section contains function entry points that are fixed
  90with respect to the top of the package. The currently defined entry-points
  91are listed in section "68060{ISP,FPSP}-TEST entry points" below. A calling
  92routine would simply execute a "bsr" or "jsr" that jumped to the selected
  93function entry-point.
  94
  95For example, to run the 060ISP test, write a program that includes the
  96itest.sa data and execute something similar to:
  97
  98        bsr     _060ISP_TEST+128+0
  99
 100(_060ISP_TEST is the starting address of the "Call-out" section; the "Call-out"
 101section is 128 bytes long; and the 68060ISP test entry point is located
 1020 bytes from the top of the "Entry-point" section.)
 103
 104The third section is the code section. After entering through an "Entry-point",
 105the entry code jumps to the appropriate test code within the code section.
 106
 10768060ISP-TEST Call-outs:
 108------------------------
 1090x0: _print_string()
 1100x4: _print_number()
 111
 11268060FPSP-TEST Call-outs:
 113-------------------------
 1140x0: _print_string()
 1150x4: _print_number()
 116
 117The test packages call _print_string() and _print_number()
 118as subroutines and expect the main program to print a string
 119or a number to a file or to the screen.
 120In "C"-like fashion, the test program calls:
 121
 122        print_string("Test passed");
 123
 124                or
 125
 126        print_number(20);
 127
 128For _print_string(), the test programs pass a longword address
 129of the string on the stack. For _print_number(), the test programs pass
 130a longword number to be printed.
 131
 132For debugging purposes, after the main program performs a "print"
 133for a test package, it should flush the output so that it's not
 134buffered. In this way, if the test program crashes, at least the previous
 135statements printed will be seen.
 136
 13768060ISP-TEST Entry-points:
 138---------------------------
 1390x0: integer test
 140
 14168060FPSP-TEST Entry-points:
 142----------------------------
 1430x00: main fp test
 1440x08: FP unimplemented test
 1450x10: FP enabled snan/operr/ovfl/unfl/dz/inex
 146
 147The floating-point unit test has 3 entry points which will require
 1483 different calls to the package if each of the three following tests
 149is desired:
 150
 151main fp test: tests (1) unimp effective address exception
 152                    (2) unsupported data type exceptions
 153                    (3) non-maskable overflow/underflow exceptions
 154
 155FP unimplemented: tests FP unimplemented exception. this one is
 156                  separate from the previous tests for systems that don't
 157                  want FP unimplemented instructions.
 158
 159FP enabled: tests enabled snan/operr/ovfl/unfl/dz/inex.
 160            basically, it enables each of these exceptions and forces
 161            each using an implemented FP instruction. this process
 162            exercises _fpsp_{snan,operr,ovfl,unfl,dz,inex}() and
 163            _real_{snan,operr,ovfl,unfl,dz,inex}(). the test expects
 164            _real_XXXX() to do nothing except clear the exception
 165            and "rte". if a system's _real_XXXX() handler creates an
 166            alternate result, the test will print "failed" but this
 167            is acceptable.
 168
 169Miscellaneous:
 170--------------
 171Again, itest.sa and ftest.sa are simple tests and do not thoroughly
 172test all 68060SP connections. For example, they do not test connections
 173to _real_access(), _real_trace(), _real_trap(), etc. because these
 174will be system-implemented several different ways and the test packages
 175must remain system independent.
 176
 177Example test package set-up:
 178----------------------------
 179_print_str:
 180        .                       # provided by system
 181        rts
 182
 183_print_num:
 184        .                       # provided by system
 185        rts
 186
 187        .
 188        .
 189        bsr     _060FPSP_TEST+128+0
 190        .
 191        .
 192        rts
 193
 194# beginning of "Call-out" section; provided by integrator.
 195# MUST be 128 bytes long.
 196_060FPSP_TEST:
 197        long    _print_str - _060FPSP_TEST
 198        long    _print_num - _060FPSP_TEST
 199        space   120
 200
 201# ftest.sa starts here; start of "Entry-point" section.
 202        long    0x60ff0000, 0x00002346
 203        long    0x60ff0000, 0x00018766
 204        long    0x60ff0000, 0x00023338
 205        long    0x24377299, 0xab2643ea
 206                .
 207                .
 208                .
 209