Table of Contents
Previous Chapter
Table of Contents
Previous Chapter
The FEP is booted at the direction of a BEP function which commands and controls the process. The Boot FEP executable runs on the FEP. The FEP Manager function loadRunProgram might install fepCtl and fepTimedBias et. al. to initiate a science run. Refer to the FEP Manager Section 25.5.2 Use 2: Reset, load, and run a program on a Front End Processor.
Boot code is copied by the BEP into shared FEP bulk memory(1). The boot code executing in the FEP bulk memory, will provide the BEP with the capability to deliver read, write, and execute commands to the FEP via a mailbox. With these commands the BEP may complete loading of the executable code into the FEP I-cache and begin execution of that Front End Processors stand alone code.
The procedures used to respond to the BEP directives are: startUpFep, bootServerFep and a (separate) copy of the FEP IO Library. No other code is active. When execution of a science run is commanded, the thread of control is passed to the function indicated and this boot code is effectively abandoned.
Note: This mechanism is not restricted to initiating science processing. Any code may be copied to the FEP, any code may be overwritten, and any code loaded may be executed and that code may or may not return. Since the thread of control is passed to an executing function, the responsibility to handle the watchdog is also passed to that function.
The Boot FEP provides the following feature:
Figure 187 illustrates the relationship between functions used by the FEP boot procedure.
FIGURE 187. FEP Boot Function Relationships
The FEP boot uses the FEP IO Library to fulfill commands entered into the incoming MailBox.
The hardware locations of the MicroBoot Word (0xBFFFFFFC), reset vector (0xBFC00000), and general exception vector (0xBFC00180) are specified in section 2.2.2.3.1 of DPA Hardware Specification & System Description, Table 10. FEP Memory Map (Rev B). (The MicroBoot Word is aliased to 0xA017FFFC.) The linker must be constrained to establish the beginning of this boot code at the reset vector. When the reset line is released, execution will begin at the reset address.
With interrupts disabled, should a hardware exception be detected, control will pass to the exception vector. Code has been provided to copy the contents of relevant registers to shared memory. The client process may interrogate it to discern and record the cause of failure.
The MicroBoot word contains a "sequence to initialize critical configuration parameters that are not accessible under software control."(2) Located at 0xBFFFFFFC, it is initiated upon reset.
The functions startUpFep and bootServerFep are copied into FEP shared memory by the BEP while holding the FEP in a reset state. When released, the FEP will reference its microboot address and begin executing the startUpFep code.
startUpFep will initialize registers: setting kernel mode, disabling interrupts, mapping the general exception vector, setting co-processor 0 to usable, clearing the interrupt mask, and clearing the software interrupts in co-processor 0. (There are no additional co-processors.) The mongoose is then configured with no DMA and running with a single wait state. Because the stack size is declared during initial compilation, the stack pointer address is located at the maximum offset (minus this function's save area of 24 bytes). The global data pointer (gp) is assigned to the linker defined symbol _gp.
C program specifications expect the global data area (.bss) to be cleared. The address of the first word and the end have been provided by the linker. The process enters a loop which will write zeros into those memory locations. The process then calls the monitor function bootServerFep to service commands from the BEP. Should that function ever return, startUpFep will continue execution from its first statement.
In the event that an anomalous condition is encountered which transfers control to the exception vector; startUpFep will copy the FEP CPU cause register, and the Coprocessor status, cause, and exception program counter registers to FAULT_DATA in shared memory. The watchdog will be set to expire quickly.
bootServerFep establishes a buffer for commands and for the FIOgetNextCmd status variable. It first calls FIOinit to initialize the FEP IO Library pointers and structures used in communicating commands from the BEP mail box. Next it enters a forever loop in which it calls FIOtouchWatchdog to keep the mongoose watchdog counter from reaching zero and resetting the CPU and calls FIOgetNextCmd to have the library functions interrogate the BEP mailbox for any read, write, or execute in memory commands, to which other library functions will respond and fulfill. Commands other than those mentioned are not honored. Usually the BEP uses these functions to complete loading of memory and to begin executing a loaded function. Refer to FEP IO Library Section 39.0 for a more detailed description of the library functions.
Next Chapter