Software Design Notes Bootstrap Loading SECTION 2 Bootstrap Loading 2.1 INTRODUCTION Bootstrap loading the Explorer system involves several stages and several types of loads. While the remainder of this document is involved with system operation, bootstrap loading occurs before the system is operational and is, therefore, quite different from what follows in later sections. 2.2 TYPES OF LOADS There are four types of loads: * Power on / System reset. These are exactly the same except for the way they are initiated. A power on boot is performed when power is cycled on the main chassis. A system reset is performed by issuing the boot key chord META-CTRL-META-CTRL-ABORT. Much goes on during this type of load, but when the LISP system is being loaded, the primary software entity that gets loaded is the "primitive" microcode (from now on this will be referred to as the "primitive"). Microcode is loaded from a microload band (also known as a microcode partition) on secondary storage into the writable control store (WCS) of the processor. The system microcode in turn loads the system (the LISP system software) from a load band on secondary storage. * Cold boot. This is performed by issuing the boot key chord META-CTRL-META-CTRL-RUBOUT. This causes the Explorer to reload the current system microcode and the current system load band from secondary storage. The previous environment is lost. * Warm boot. This is performed by issuing the boot key chord META-CTRL-META-CTRL-RETURN. This causes the Explorer to restart the system code in such a way as to preserve the previous environment. Neither the system microcode nor the system load are re-read from secondary storage. 2-1 Bootstrap Loading Software Design Notes * Menu boot. This is performed by issuing the boot key chord META-CTRL-META-CTRL-M. This causes the Menuboot microload (see description of Menuboot in the Power on / Cold boot description below) to be loaded from the same unit that the current system load was loaded from. Menuboot is then executed as described below. Note that each of the four boot key chords described above will cause the Explorer processor to take a true hardware trap (not just a polled event) to the appropriate point in microcode. So even if the processor is stuck in a loop, it should respond to any of the four chords. An additional key chord, META-CTRL-META- CTRL-C, can be used if the system appears to be in an infinite loop. This causes the system to crash and to record the currently running Lisp function. If the system microcode in Writable Control Store (WCS) has been violated, then the Cold boot, Warm boot, and Menu boot may not function correctly. In this case you have no choice but to cycle power or do a System reset. 2.3 POWER ON / SYSTEM RESET Both of these actions cause a NuBus reset which forces all boards that have a self-test to perform it. A NuBus reset causes the Explorer processor to enter its boot ROM based Microcode at a fixed location. The first action it takes is to perform the processor self-tests. Then all internal memories and registers are cleared. If the Explorer I processor fails self-test, it will crash with a light code #x89. The Explorer II processor reports individual selftest numbers as they are run, with the failing test number left on the lights in case of failure. (See the light codes table.) System Test - if the processor passes its self-test, it proceeds to the next phase, System Test and Boot. 1. First the processor determines whether it is to be the System Test & Boot Master (STBM) or if some other processor will be. In a single processor system, the Explorer will of course be the STBM. In a multi- processor environment, the processor in the lowest numbered slot that is an STBM candidate and has passed 2-2 Software Design Notes Bootstrap Loading self-test (within 10 seconds) is the STBM. If the Explorer processor is not the STBM, it enters Secondary mode and waits for the STBM to post an event to awaken it. It then performs secondary booting operations. 2. Assuming the Explorer is the STBM, it performs the following actions: NOTE All searches for resources are performed by starting with slot 0 and looking at boards in successively higher numbered slots until slot 15 has been checked. For each slot, the STBM first checks for a value of #xC3 in the ID character of the boards Configuration ROM (see paragraph on the Configuration ROM). This indicates the board has a valid Configuration ROM. Next, check that the CRC in the configuration ROM is correct. Then the Resource Type field in the Configuration ROM of each board is examined to see if the board contains the desired resource. a. Search for NVRAM. If the NVRAM bit of the Resource Type field is set, then the board contains NVRAM. The Explorer checks the CRC on the contents of the NVRAM (Explorer I does not) and the format generation number to verify it contains a value of #x01. Upon finding a valid NVRAM, the STBM extracts pointers to a Monitor, Keyboard, and Load Source for later use. See the paragraph on NVRAM for format details. b. Find a monitor. If a valid NVRAM was found, then the monitor slot and unit numbers from NVRAM are used and the monitor is validated by first checking that the monitor bit in the Resource Type field is set, and then by issuing the Initialize- Monitor device driver call. If this completes successfully the monitor has been found. If there was no valid NVRAM, or if the Initialize-monitor call failed, then the processor searches for a board with the monitor bit on in the Resource Type field of the configuration ROM. If it finds one it calls the Initialize-monitor function of the device driver 2-3 Bootstrap Loading Software Design Notes on that board. If the call completes successfully, the monitor has been found. If no monitor can be found, the processor attempts to perform a default boot. c. Display the message "Slot S TESTING SYSTEM", where S is the slot number of the processor board, on the monitor. d. Find a memory board. The processor searches for a board with the memory bit set in the Resource Type field. When it finds one, it validates it by running the Interface Diagnostic, located in the ROM on that board. The diagnostic is run with messages disabled. If it passes, that memory board is used. Otherwise, the processor searches for another memory board. It is assumed that every memory board will have at least two megabyte of memory. If no valid memory board can be found, the message "ERROR: NO GOOD MEMORY FOUND" (Explorer I = "ERROR: 00000004") is displayed on the monitor, and the processor crashes with a light code (Explorer I = #xBA; Explorer II = #x74) e. If a memory board was found, the processor then performs Chassis Testing where it performs the following actions on each successive board in the system, starting with slot 0 and ending with slot 15. If any test fails, the rest of the tests for that board are skipped. - Tests whether a board is present in the slot (if no NuBus timeout is received when reading the configuration ROM, then a board is present). If the slot is empty, go to next slot. - Displays "Slot S" on the monitor, where S is the slot number of the board under test. - Tests whether the Configuration ROM contents are valid: ID character = #xC3 and CRC verifies. If not, display "ROM" ("TESTS FAILED" displayed later). - If the ROM flags in the Configuration ROM indicate that the board performs a self-test, then wait up to 20 seconds for the self-test to complete. The board will reset a bit in the onboard Flag Register (see paragraph on Configuration ROM) when its self-test is complete. Check the Flag Register for a self- 2-4 Software Design Notes Bootstrap Loading test failure, and if one occurred, display "SELF" ("TESTS FAILED" displayed later). - If the ROM flags in the Configuration ROM indicate that the board participates in NuBus tests, command it to do so and check the results. If a failure is detected, display "NUBUS" ("TESTS FAILED" displayed later). - If the Configuration ROM Diagnostic Offset field is not = #xFFFFFF, execute the boards Interface Diagnostic. - If all tests for a slot have passed, then turn off the slot Test LED in the Configuration Register (see paragraph on the Configuration ROM), and display "passed", otherwise display "TESTS FAILED". f. Find a keyboard. If a valid NVRAM was found, then the keyboard slot and unit number from NVRAM is used and the keyboard is validated by first checking that the keyboard bit in the Resource Type field is set, and then by issuing the Initialize- keyboard device driver call. If this completes successfully the keyboard has been found. If there was no valid NVRAM, or if the Initialize-keyboard call failed, then the processor first attempts to initialize a keyboard at the same slot and unit as the system monitor currently in use (not supported by Explorer I). If that also fails then it searches for a board with the keyboard bit on in the Resource Type field of the configuration ROM. If it finds one it calls the Initialize-keyboard function of the device driver on that board. If the call completes successfully, the keyboard has been found. If no keyboard can be found, the processor performs a default load using the boot device slot and unit from NVRAM. If there was no valid NVRAM, the processor searches for a boot device by first searching for a slot that has the boot source bit (Explorer I: and not the LAN bit) in the Resource Type field set, and then using the lowest numbered unit at that slot. The microcode specified as default in the partition table are loaded. 2-5 Bootstrap Loading Software Design Notes Initial Menu - if a keyboard was found, the processor sounds a tone and displays the Initial Menu: "D=Default load, M=Menu load, R=Retest, E=Extended tests :" If no key is pressed within approximately 15 seconds and no boards have failed Chassis Test, the processor attempts a default load of the MCR partition marked as default on whichever load source is determined to be the default load source. Pressing "D" or "RETURN" also results in a default load. 1. Pressing "R" causes the Chassis Testing phase, described above, to be repeated. 2. Pressing "E" causes the Chassis Testing phase to be repeated, but each Interface Diagnostic is run in "extended mode". In extended mode, an interface diagnostic will display the board identifier, the part number, the name of each test it runs on the screen, and an indication of whether each test passed or failed. Additional testing may also be performed. For example, the memory board diagnostic tests all of memory in extended mode, but not in normal mode. 3. Pressing "M" causes the processor to go into the menu boot sequence, described below. 4. At this point there are a number of "hidden options" in addition to those already mentioned. They are intended for use by expert users such as system managers and maintenance personnel. a. Pressing "S" tells the processor that you want to do a default boot, but you want to use a boot unit other than the default unit. The processor will then present the device selection menu (described below), but will perform the boot as soon as you have selected the device. b. Pressing "G" tells the processor that you want to load GDOS, the diagnostic operating system. The processor will then present the device selection menu (described below) but will boot GDOS as soon as you have selected the device. c. Pressing "N" means that you want to type in the names of microcode and load bands to be booted. The processor will then prompt you for each of these names. You must type these names exactly as they are displayed by print-disk-label; the processor will not convert lower case to upper case automatically. The shift key or caps lock key will give you upper case. The rubout key will let you correct mistakes. Once you have typed in a name, the return key indicates you are 2-6 Software Design Notes Bootstrap Loading ready to proceed. When you have entered both names, the processor presents the device selection menu (described below). As soon as you select a device, the processor will boot the microcode and load band you typed in. d. Pressing "F" (not supported on Explorer I) tells the processor that you want to load FDOS, the Factory version of the diagnostic operating system. The processor will then present the device selection menu (described below) but will boot FDOS as soon as you have selected the device. e. Pressing "!" (not supported on Explorer I) causes the processor to enter a Debug utility menu. Default Boot. After D is selected for Default Boot, the processor attempts to load from either the default load source specified in NVRAM or the first unit found by searching all slots. A "waiting" message is displayed until the default load source is ready, then the STBM interprets the Device Driver in the load source interface board configuration ROM to load the first MCR partition with the default bit set. Under the Release 3.0 the MCR named PRIM is used for an Explorer I, BOOT for an Explorer II. Both BOOT and PRIM are primitives and the term "primitive" refers to both. The "primitive" has three primary functions which are: 1. The "primitive" co-ordinates the booting of a machine with multiple processors. Since the Explorer does not currently have multiple processors, this is not done in the "primitive" even though it has a skeleton design for such a function. 2. The "primitive" performs slave device downloading. Downloading can be thought of as patching the ROM on a controller board such as a disk controller board. If there is a software bug in the controller board ROM, it can be fixed by loading new software into a RAM area on the controller board and executing out of the RAM area rather than the ROM area. 3. The "primitive" loads the Lisp MCR code into the processor. 2-7 Bootstrap Loading Software Design Notes To do all of the above, the "primitive" uses a special type of partition called a Configuration partition. There may be several configuration partitions on the default disk. The default configuration partition is ued by the "primitive". A configuration partition has several entires in it, which are the name of the Lisp MCR, the name of the Lisp Load band, the name of the download software partition, and other information reflecting the machines configuration. If the default configuration reflects an erroneous machine configuration an error will occur. Later in this section there will be a description of the configuration partition and the algorithm used by the "primitive". It should be noted that on an Exploror I PRIM and BOOT are identical but separate software partitions. On the Explorer II the single partition BOOT takes on both roles as "primitive" and menuboot. Both Menuboot and the "primitive" assume 2MB or greater memory boards. Menu Boot - If you entered an "M" at the Initial Menu the processor then presents the device selection menu (the header is "AVAILABLE LOAD DEVICES"). This menu lists the available load devices and asks you to select one. After you select a device, the processor then loads a microcode band called "BOOT" from the device you selected. This is Menuboot, which then takes over the remainder of the boot process. It should be noted that this is the point where the processor leaves ROM and enters code (Menuboot) that has been downloaded into WCS. This is important because if for some reason Menuboot does not exist on the device you selected (or if it has been wiped out), this step will not work. If Menuboot is non-existent, the message "MICROLOAD NOT FOUND" will be displayed. If Menuboot has been wiped out, the message "BAD MICROLOAD FORMAT" will be displayed. These messages can also occur on any other microload attempt. The first thing Menuboot does is to present the menu "L=LISP load, M=Multi-unit load, D=Diagnostic load, P=Print device label,C=Configuration Boot" 1. To do a Configuration Boot you enter an C or simply press RETURN since Configuration Boot is the default. After a C is pressed a menu of load devices appear. The operator is to select the desired device. After the device is selected, a list of configuration partitions appear on the screen. The operator then selects which configuration partition is to be used in the booting process. 2. To do a Lisp load enter "L" . The processor presents a 2-8 Software Design Notes Bootstrap Loading menu of available load bands on the device previously selected. Asterisks may appear by some of the load bands. The asterisks should be ignored and the user should select the desired load band. Once you have selected a load band, you will be presented with a menu of available microcode bands. Again, asterisks may appear by some microcode bands. The asterisk may be ignored as above. The microcode that is preferred by the load band you previously selected will be named in a header message above the microcode menu. The preferred microcode is simply the one that the load band was saved with. You can generally use microcodes other than the preferred one, but the system will have to load the error table over the network. Once you have selected a microcode partition, the processor will load that microcode and pass it the name of the load band to be used. 3. If you select "M" the processor will present you with the the device selection menu before each partition menu. This allows you to select the system microcode and and system load band from different devices. 4. If you select "D" the processor will present you with the device selection menu (described above). Once you select a device the processor will display a menu of available diagnostic microloads for that device. Selecting one will cause that microcode to be loaded and executed. 5. If you select "P" the processor will present you with the device selection menu again (see above). When you select a device the processor displays the list of partitions on that device, similar to what is displayed by a (print-disk-label) form in LISP. 2.4 CONFIGURATION ROM A machine based on the NuBus architecture has up to 16 NuBus slots. The Explorer has seven. Each slot may contain one board. Each board contains a configuration ROM. The configuration ROM is located at the highest NuBus physical addresses allocated for each slot (i.e. the ROM ends at address FsFFFFFC, where s is the slot number of the board) with data stored one byte per NuBus word. The Configuration ROM fields that are of concern to the booting 2-9 Bootstrap Loading Software Design Notes process are as follows: Resource Type field - This is a one byte field, located at address FSFFFF00. Each bit that is set to one indicates a resource that the board contains. Bit 0 Memory - board contains memory that may be used during booting. This memory will start at FS000000 and be at least one contiguous megabyte long. Bit 1 Boot source - board is a controller (e.g. disk, tape, LAN) that has a unit(s) that may be used as a load device. This board contains a load device driver. Bit 2 LAN - board contains a Local Area Network (LAN) controller that may provide a load device via the network This board may contain a load device driver. Bit 3 Monitor - board has a unit that can be used as the system monitor during the boot process. This board contains a monitor device driver. Bit 4 Bootable processor - board is capable of performing the standardized functions of a "secondary" processor to an STBM during system booting operations. Bit 5 Keyboard - board has a unit that can be used as the system keyboard during the boot process. This board contains a keyboard device driver. Bit 6 NVRAM - board contains non-volatile RAM that may contain system test and boot default parameters. If this bit is set the three byte board relative offset to the NVRAM is stored in locations FSFFFEF4 - FSFFFEFC (one byte per word) and the log 2 of the NVRAM size is stored in location FSFFFEF0. Identification character - This is a one byte field, located at address FSFFFF04. If it contains the value #xC3, then the configuration ROM contains valid data, otherwise it does not. This provides a way for "foreign" boards to exist in the system without confusing the STBM. ROM Flags - a one byte field at location FSFFFF10 which contains the following flags (and several others which do not concern us here): Bit 0 A one indicates the board does self-test. Bit 1 A one indicates the board will participage in NuBus tests. Bit 2 A one indicates the board is capable of being an STBM. 2-10 Software Design Notes Bootstrap Loading Flag Register Offset - a three byte field at locations FSFFFF14 - FSFFFF1C (one byte per word) containing the board relative offset to the Flag Register. The Flag Register is a one byte field containing the following flags: Bit 0 A one indicates self-test is still in progress. Bit 1 A one indicates the board failed self-test. Bit 2 A one indicates that a peripheral or subsystem controlled by this board failed test. Diagnostic Offset - a three byte field at locations FSFFFF20 - FSFFFF28 containing the board relative offset to the Diagnostic Engine code that makes up the interface diagnostic. A value of >FFFFFF indicates that there is no interface diagnostic. Device Driver Offset - a three byte field at locations FSFFFF2C - FSFFFF34 containing the board relative offset to the Diagnostic Engine code making up the boards device driver(s). There must be one device driver for each of the following bits that are set in the Resource Type field: boot source, monitor, keyboard. Configuration Register Offset - a three byte field at locations FSFFFF38 - FSFFFF40 containing the board relative offset to the Configuration Register, which is a 8 bit field which contains (among other information) the following: Bit 0 Reset - writing a one resets the board Bit 1 NuBus Master Enable - a one enables the board to read and write via the NuBus (0 disables the boards NuBus interface) Bit 2 Test LED - A one turns on the red LED on the board. A zero turns it off. Bit 3 Test - when set to one during system testing requests the board to perform its NuBus test. CRC Signature - A 2 byte field at locations FSFFFFB8 - FSFFFFBC that contains the CRC value computed over the boards ROM. The ROM size is stored in location FSFFFFB4. 2.5 THE STBM AND DEVICE INDEPENDENCE One of the goals of the STBM is to allow the ROM code on each board to be independant of the other boards in the system. For example, it must be possible to replace teh disk controller board with one that provides a different interface to the processor, but not to have to change the processors boot ROMs. This is accomplished by having a boot source device driver (DDR) in the ROM on the disk controller. The DDR provides the processor with a generic interface to the device. The DDR is written in a 2-11 Bootstrap Loading Software Design Notes processor independant, interpreted language, called Diagnostic Engine code, and is executed by the processor. Since it is interpreted, the processor must have a Diagnostic Engine Interpreter in its ROM. Being processor independent means the disk controllers ROM does not have to change if the processor is replaced with one of a different type. It is called Diagnostic Engine code because the scheme was originally developed to allow processor independent diagnostics to be written. Most boards in the system have an Interface Diagnostic written in Diagnostic Engine code in their Configuration ROM. There are three type of DDRs: load source, monitor, and keyboard. They provide the processor with a generic interface to the three peripheral resources it requires to perform system testing and load. The monitor and keyboard allow the processor to communicate with the operator, and the load source provides a source from which to load code. Load source interfaces currently exist for disk, tape, and LAN, and the processor-to-boot-source interface is generic enough to support virtually any kind of device that is capable of loading code. DDRs are intended to be used for bootstrap loading, not for normal system use. 2.6 NVRAM FORMAT The information in NVRAM is accessed as though it were stored one byte per word. The first part of NVRAM contains system default configuration information, whcih is accessed during the boot process: base addr + #x00 = STBM Monitor unit number LSB byte Binary base addr + #x04 = STBM Monitor unit number MID byte Binary base addr + #x08 = STBM Monitor unit number MSB byte Binary base addr + #x0C = STBM Monitor slot number (FF = none) Binary base addr + #x10 = STBM Keyboard unit number LSB byte Binary base addr + #x14 = STBM Keyboard unit number MID byte Binary base addr + #x18 = STBM Keyboard unit number MSB byte Binary base addr + #x1C = STBM Keyboard slot number (FF = none) Binary base addr + #x20 = Boot Source unit number LSB byte Binary base addr + #x24 = Boot Source unit number MID byte Binary base addr + #x28 = Boot Source unit number MSB byte Binary base addr + #x2C = Boot Source slot number (FF = none) Binary base addr + #x30 = NVRAM format generation number. Equal 01 for all NuGeneration devices Binary base addr + #x34 = NVRAM format superset revision number. Binary base addr + #x38 = NVRAM CRC LSB byte Binary 2-12 Software Design Notes Bootstrap Loading base addr + #x3C = NVRAM CRC.MSB byte Binary The NVRAM contains additional information in a specific generic format so that it can be accessed by any type of processor. The format is described in detail in the NuBus System Architecture Specification. 2.7 ERROR CODES AND MESSAGES For the most common error conditions, textual error messages are displayed. However, in some cases, the STBM ROM code and Menuboot will display hexadecimal error codes. 2.7.1 STBM ROMS - Error Codes. ERROR: 00000002 - Load device offline or not responding. The device is powered down or is not connected. ERROR: 00000003 - Load device error. The load device experienced an unrecoverable error. ERROR: 00000004 - Processor could not find a memory board that passed tests. The processor checks the following when looking for a memory board: Look for the value #xC3 in Configuration ROM ID character. Look for memory bit set in Configuration ROM Resource Type field. Make sure CRC in configuration ROM is correct. Run the Interface Diagnostic in the board's ROM and check that it had ROM and check that it had no failures. DEVICE ERROR: 00000005 - Unexpected NUBUS error. The processor was executing diagnostic engine code in a device driver in the NuBus Peripheral Interface (NUPI) or SIB ROM when an unexpected NUBUS error occurred. DEVICE ERROR: 0000006 - Command timeout. The NUPI device driver issued a NUPI command block and the NUPI did not set the complete bit in the status field. The minimum timeout value is 10 seconds. If the disk label is messed up, it could possibly cause this problem. The NUPI could also be faulty. If the NUPI considers a command block to be invalid, it will exhibit this failure mode. The last NUPI 2-13 Bootstrap Loading Software Design Notes command block that the NUPI device driver issued is located at location FS00C000, where S is the slot number of the memory board in the lowest numbered slot. DEVICE ERROR: 00000009 - Network down. The Ethernet is disconnected, shorted, or open. DEVICE ERROR: 0000000A - Invalid unit number for the load device. DEVICE ERROR: 0000000B - Ethernet board failed to initialize. DEVICE ERROR: 00000010 - Bad DEI instruction header. A board was found with a valid configuration ROM, but the Diagnostic Engine code that the Diagnostic offset or Device Driver offset in the configuration ROM points to has an invalid header. This possibly means that the ROM is bad. DEVICE ERROR: 00000011 - Invalid DEI request. The ROM on the board is good, but a request was made that could not be handled by that board (e.g. a boot request was given to the monitor). This probably means that the contents of NVRAM are invalid. Try doing a menu boot, specifying the boot unit. Once the system is booted type in (si:setup-nvram) to the LISP Listener. DEVICE ERROR: 00000012 - Diagnostic Engine code instruction space (ispace) problems. The processor found an invalid instruction when trying to execute Diagnostic Engine code out of the ROM on one of the boards. This could happen when executing a diagnostic or a device driver. This possibly means the ROM is bad. DEVICE ERROR: 00000013 - Diagnostic Engine code data space (dspace) problems. The processor found one of the following problems when trying to execute Diagnostic Engine code out of the ROM on one of the boards: stack overflow, stack underflow, or dspace variable out of range. This could happen when executing a diagnostic or a device driver. This could be due to a bug in the code being executed, or the ROM could be bad. DEVICE ERROR: 60000000 and above - NUPI command status. These are errors that the NUPI device driver 2-14 Software Design Notes Bootstrap Loading passes back from the status field of the NUPI command block. See the NUPI Hardware Specification. 2.7.2 Menu Boot and Primitive - Error Codes and Error Messages. ERROR: 00000014 - Device access error. The NUPI returned bad status. ERROR: 00000015 - Invalid label. The first word of block 0 did not contain "LABL". ERROR: 00000016 - Invalid partition table. The first word of the partition table did not contain "PRTN". ERROR: 00000017 - No available microloads. There were no Explorer microcode partitions in the partition table. 2-15 Bootstrap Loading Software Design Notes 2.7.2.1 Menuboot and Primitive Error Messages. Message Meaning ------- ------- Warning: No Microcode Device selected in a Lisp load Partitions on Device or device specified in a configuration partition had no microcode. Warning: No Configuration Device selected in a Partition on Device Configuration Boot had no configuration partition on it. No Default Configuration On default boot, the "primitive" Partition could not locate a default configuration partition. Unable to Read Device An error occurred when trying to read the load device. Invalid Slot or Unit The portion of the configuration Number in the Configuration partition containing the disk Partition. slot and unit number for the Lisp MCR is invalid. Bad Load Partition or Load The entry portion of the Device configuration partition containing the information about the load band has invalid information in it Currently Executing CPU A configuration partition was is not in Configuration used which did not have a valid entry for the Explorer processor board. Cannot Download Device When trying to download a device, one of four problems occured. First, the part number in the entry field may not match; second, there is a problem with the disk slot or unit number specified; third, there is a problem in matching the CPU type to the board types in the configuration partition; and last, there is no match on the download partition name. Unable to Read the This means the data in the 2-16 Software Design Notes Bootstrap Loading Partition table partition table is not set up correctly. To be set up correctly the following must be true: There must be a default entry named LABEL with partition type of Volume Label and CPU type of generic. There also must be a default entry named FTBL with partition type of Partition Table and CPU type of generic. 2.8 LIGHT CODE TABLE In some cases the processor cannot proceed and cannot display a message. In these cases teh processor will crash and display a code in the amber colored light-emitting diodes (LEDs) located on the processor board. These can be viewed by opening the front door on the systme unit and looking through the slot on the interlock door. The lights are read as an eight bit binary number (seven bits for Explorer II) with the lowest amber LED as the least significant bit. The codes shown below are hexadecimal. 2.8.1 Explorer I STBM LED Codes. Physical locations of LEDs: (H)(6)(5)(4)|(3)(2)(1)(0)| (Fault) H = Halt amber 6:0 = status indicators amber Fault = Fault indicator red 81 = Power failure. The processor took the power failure hardware trap. 82 = The processor took the control store parity error trap. This probably means that the processor's WCS is faulty. 83-87 = Should never occur. If they do the processor is probably faulty. 88 = The processor received an unexpected NuBus error. 89 = Processor failed self test. 8A = No memory. If the processor can find a monitor it will also display ERROR: 00000004 as described above. 8B = No boot device. This crash will only occur if the 2-17 Bootstrap Loading Software Design Notes processor cannot find a boot device and can not find a monitor on which to display a message. 8C = Microload problems. This will only occur if the processor cannot find a monitor on which to display the message "BAD MICROLOAD FORMAT" 8D = DEI PROBLEMS. This will only occur if the processor cannot find a monitor on which to display the device errors 10 - 13 described above. 8E = Monitor device driver problems. The processor got a non-zero completion code on a call to the monitor device driver. 2.8.2 Explorer II STBM LED Codes. Physical locations of LEDs: (H)(B)(L)(R)|(F)(6)(5)(4)|(3)(2)(1)(0)| (Fault) H = Halt amber B = Busy amber L = cache hit left amber R = cache hit right amber F = cache filling amber 6:0 = status indicators amber Fault = Fault indicator red with Fault LED on: ------------------ selftests: 7F = Processor unable to load code from EPROM 01-05 = Part 1 self-tests (kernel tests) 06 = Passed kernel selftests, attempting to load remainder of tests and STBM (Part 2) 07-39 = Part 2 Lisp Chip and processor board selftests 3A-3C = Floating Point Board tests 2-18 Software Design Notes Bootstrap Loading crash codes: 71 = No online devices from which to download 72 = Bad microcode format found during attempted download 73 = Device error during attempted download 74 = No good system memory found 75 = NuBus error during download from NuBus memory to internal memories 76 = MCR partition requires floating point board which is not present Fault LED off: -------------- 0n = STBM arbitration phase, looking at slot n 1n = NVRAM search phase, looking at slot n 2n = Monitor search phase, looking at slot n 3n = Memory search phase, looking at slot n 4n = STBM testing chassis slot 41 = ROM test (C3, format version, CRC) 42 = Selftest 44 = NuBus test 48 = Interface diagnostic 5n = Keyboard search phase, looking at slot n 60 = At top level STBM menu 61 = Attempting to default boot 62 = Building device menu 63 = Waiting for load device to come ready 64 = Reading partition from load source 65 = Processing MCR sections (except last) 66 = Loading WCS, PDL to A/M, and enter new code 70 = Waiting for first Secondary event 71 = Processing first Secondary event 2-19 Bootstrap Loading Software Design Notes 72 = Waiting for second Secondary event 73 = Booting quietly 78 = Waiting RAM download (P3 mode 5) 2.9 MICROLOADS The writable control store and other internal memories of the Explorer processor are loaded from a microload. A microload is read by the boot PROM from a mass storage device, interpreted, and the internal memories are loaded. The Explorer microassembler produces an output file in the "MCR" format. The file name will be "xxx.mcr" where "xxx.lisp" is name of the source file. The "load-mcr-file" function converts the "mcr" file to the microload format and installs it as an "MCR" partition on a disk. This compact representation can be loaded by the Device Driver on the disk controller board when directed to do so by the processors bootstrap PROM. This format provides for the loading of I-mem, A/M memories, D-mem, and main memory. On the Explorer II it also provides load data and initialization instructions for additional onboard IO space structures. The Explorer II MCR format is specified in Appendix A. 2.10 INTERFACE BETWEEN BOOT PROM AND MICROLOADS When a microload is loaded by the boot ROMs, certain information is passed to the microload in dedicated A memory locations. The following A memory locations are used for the purpose of passing parameters between the boot ROM and microloads: variable name A memory location -------------- ----------------- A-BOOT-COMMAND-BLOCK #x3F8 A-BOOT-LOD-DEVICE #x3F9 A-BOOT-MEMORY #x3FA A-BOOT-MONITOR #x3FB A-BOOT-KEYBOARD #x3FC A-BOOT-DEVICE #x3FD A-BOOT-MCR-NAME #x3FE A-BOOT-LOD-NAME #x3FF 2-20 Software Design Notes Bootstrap Loading The boot ROM sets up the following locations as parameters passed to a microload that is loaded: A-BOOT-MEMORY is set to Fs999999 where s is the slot number of either the first memory board found or (if in secondary mode) the memory specified for this processor in the Command Block received from the STBM Primitive. A-BOOT-MONITOR is set to designate the system monitor. The slot number is in the most significant byte and the unit number is in the three least significant bytes. A-BOOT-KEYBOARD is set to designate the system keyboard. The format is the same as for a-boot-monitor. A-BOOT-DEVICE is set to designate the boot device. The format is the same as for a-boot-monitor. A-BOOT-MCR-NAME contains the name of the microload in ASCII little endian format. A-BOOT-LOD-NAME contains the name of the load band. The format is ASCII little endian. If a load band was not selected, this word will contain a value of binary zero. The boot ROM will only set up A-BOOT-COMMAND-BLOCK if the Explorer processor is being booted as a secondary processor, in which case it shall have the NuBus address of the Command Block. If Menuboot is run, it will store the system load name in A-BOOT- LOD-NAME in ASCII little endian format. If the system load is on a different unit than the microload, then A-BOOT-LOD-DEVICE will be set to that unit. Otherwise, it will contain the same value as A-BOOT-DEVICE. If Menuboot is not run, A-BOOT-LOD-DEVICE will contain a value of binary zero. The system microcode must check this variable to determine where to get the system load. In order for Menuboot (or other WCS microcode programs) to request the load of another microload into WCS, there are special processor dependent mechanisms that must be used to reenter ROM. The following A memory locations must be set up for all processors: A-BOOT-MEMORY, A-BOOT-MONITOR, A-BOOT-KEYBOARD, A- BOOT-DEVICE, A-BOOT-MCR-NAME. For the Explorer I the requesting code must turn off the PROM-disable and Bus-Error-Trap-Enable bits in the Machine Control Register (MCR) and then jump to PROM location #x1E. For the Explorer II the requesting code must enable refresh, IROM, and memory cycles on the Machine Control Register (MCR), set the highest M-memory register to #xC3, and then jump to IROM address at #xFF. The Explorer II ROM code also supplies information to the downloaded code about the type of load which has just occured. 2-21 Bootstrap Loading Software Design Notes PDL location 0 is loaded with a value indicating the boot type: 0 = STBM, default mode 1 = STBM, non-default 2 = Secondary, default 3 = Secondary, non-default 4 = Special RAM load mode 2.11 CONFIGURATION PARTITION, PRIM ALGORITHM, AND DOWNLOADING A Configuration Partition is a 17 block disk partition which supplies boot time parameters for a system. These include information such as which software shall be loaded by each downloadable processor and controller and values which allocate ownership of system resources amongst processors. The partition is divided into two parts: the partition header and the configuration modules. 1. The partition header is one block long and is divided into two parts which are both a half block long. The first half of the headers contains the following: a. At offset 0 the four characters "CNFG" are found. These characters are used to validate the fact that this is a configuration partition. b. The next two characters are used as a CRC value. The "primitive" does not use this. c. The next four characters are used as the generation and revision values. The "primitive" does not use these values. d. The remaining portion of the first half of the configuration partition is available for comment space. 2. The entries in the second half of the header are called pointers. Pointers are 16 bytes long. The following byte values are relative to offset X200 of the header block. The pointer values are: a. Bytes 0,1: A pointer to a configuration module. The pointer is relative to the start of the configuration partition. If the pointer value is 0, this implies that this entry is empty. b. Bytes 2,3: Length in blocks of the configuration partition. c. Bytes 4 - 7: A boot timeout. This is primarily for multiprocessing systems and is not used by 2-22 Software Design Notes Bootstrap Loading the Explorer. d. Bytes 8 - B: The count of configuration entries. This value will be discussed in the configuration module portion of this section. e. Bytes C,D: A CRC value for the configuration module associated with this entry. f. Bytes E,F: The board type. If the board associated with this entry is a processor, then the value in this position is equal to the processor value found in the processor configuration ROM at location FSFFFF9C. For a controller, this value is equal to the disk partition type assigned to the download software for a particular controller. g. Bytes 10,11: Implies via a 1 in a bit position, what slot the board may be in. For instance, an Explorer I board can only be in slot six so bit six would be set to a one for the Explorer I board. Some boards can be in any slot so this value would be all ones for those boards. Notice a configuration partition assumes a sixteen slot chassis. h. Bytes 12,13: Indicated board type. The value 1 indicates that this entry expected a processor board. A 2 indicates that this entry expected a downloadable controller. No other values have meaning. i. Bytes 14 - 1F: Reserved. 3. The next entries in the configuration partition are called configuration modules. They can be accessed by another processor when they are in main memory. This feature is not used by the Explorer processor. However, much of the information in the configuration module is used by the Explorer "primitive". The following byte values are relative to the beginning of the configuration module. The information in the configuration module is as follows: a. Bytes 0 - 3: The busy system flag. This flag is used when the configuration is in memory. The Explorer "primitive" does not use this field. b. Bytes 4 - 7: NuBus memory base address. This is not used by the Explorer "primitive". c. Bytes 8 - B: Monitor slot and unit. This value 2-23 Bootstrap Loading Software Design Notes is set up by the Explorer Primitive. d. Bytes C - F: Keyboard slot and unit number. This value is set up by the Explorer "primitive". e. Bytes 10 - 13: Disk slot and unit number where the Lisp MCR partition is to be found. The Explorer "primitive" expects this value to already be set up. If a value of all ones(-1) is found, a default disk is assumed. The assumed default disk is the disk from which the Explorer "primitive" was loaded. If bytes 12,13 of the pointer entry is a 2, then this entry is the disk address of a download software partition. f. Bytes 14 - 17: A four-character ASCII name of either the Lisp MCR partition or the download software partition. Bytes 12,13 of the pointer entry pointing to this configuration module indicates which one of the two this is. Note, all four characters must be exactly as found on disk. A name with less than four characters must be blanked filled. g. Bytes 18 - 1B: The disk slot and unit number of the configuration partition currently being used by the Explorer "primitive". This value is set up by the Explorer "primitive". h. Bytes 1C - 1F: The four character ASCII name of the configuration partition being used by the Explorer "primitive". This is set up by the Explorer "primitive". i. Bytes 20 - 23: The synchronization flag. This is for multiple processors and not used by the Explorer "primitive". j. Bytes 24 - 43: The 32 character hardware identification value. This value is used only when downloading is required (bytes 12,13 of the pointer field = 2). This is a part number followed by a three character ID. This value must match exactly the information found in the configuration ROM or the board to be downloaded or no download occurs. k. Bytes 44 - 63: A list of 32 byte ASCII entry. The number of entries in the list is in bytes 8 - B of the pointer entry for this configuration module. Note, these entries are predefined and are strictly formatted. A removal or addition of a blank within these ASCII entries will cause the 2-24 Software Design Notes Bootstrap Loading "primitive" to fail. For an Explorer the entries are as follows: - Entry 0: The part number and id value as described above. - Entry 1: ASCII value "Explorer Processor" or "Explorer II Processor". The Explorer primitive keys off the string "Explorer". - Entry 2: "Slots owned: (ASCII slot numbers each separated by a space). This entry is not used by the Explorer primitive. - Entry 3: "Load Slot .(Single digit ASCII slot number of the disk unit containing the Lisp load band)". - Entry 4: "Load Unit :(Six digit ASCII unit number of the disk containing the Lisp load band)". Note, if either entry 3 or 4 is an asterisk, then a default disk is used to load the Lisp load band. The disk defaulted to is the same disk from which the primitive was loaded. - Entry 5: "Load Name :(name of the Lisp load band)". If an asterisk is used, then the first Lisp load bank with the default bit set in the disk partition table is used. The primitive searches for a partition of type Explorer or of type TI Lisp. 2.11.1 The Algorithm. The following describes the algorithm in determining if a board in the system matches and entry in the configuration partition. If a match is made then either a download occurs or a CPU entry is pushed on the stack. First, the primitive scans each NuBus slot searching for board in a NuBus slot begining with slot 0. If a board is found a search is made through the pointer entries in the configuration 2-25 Bootstrap Loading Software Design Notes partition to find a 1 bit in the corresponding bit position in bytes 10,11 of the pointer entry. If a match is not found, the search for a board in higher slot numbers continues. If a match is found, the primitive fetches bytes 12,13 of the matching pointer. If the board found is not the same type as specified in bytes 12,13 of the pointer the above search continues. The "Same Type" check fetches byte 12,13 of the pointer to determine if the pointer entry expected a controller board or a CPU in this slot. If the board in the slot was a controller and the pointer entry of the configuration partition expected a a controller board, the the controller type is checked. If the types compare then a download is performed assuming there is a download software partition for this board. If the board type was a CPU and the pointer expected a CPU, the the configuration module address for this CPU is pushed onto a stack for later use; this assumes the CPU types matched. If no match occurs, then the slot search continues. The algorithm is complete when all slots have been examined. 2.11.2 Downloading. Downloading is a method to patch ROM code on a controller board by inserting new code into the RAM portion of the board and using the RAM resident code rather than the ROM resident code. Previous discussions indicated that the "primitive" performed the downloading. This is only partially correct. Once the primitive has determined that the a board is to be downloaded, the disk is searched for the software partition associated with that board. The software partition contains Diagnostic Engine Code which has been previously discussed in this section. The Diagnostic Engine code performs the actual downloading. The software partition found by the primitive contains the Diagnostic Engine code in the first portion and the ROM replacement code in the second portion of the partition. Once the Diagnostic Engine Code partition has been loaded by the primitive, it is then interpreted by the primitive's DE code interpreter. At the completion of the DE code's execution, an error indicator is checked by the primitive. If an error occurred during downloading, an error message is generated. Otherwise the algorithm continues. 2-26