Here is a note describing SROM and FlahsROM Firmware on the L2 Alpha nodes and organized by development phases. Philippe Laurens //\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\ "Normal" Booting sequenc, for reference (e.g. start VMS, UNIX or NT) ======================================= SROM Firmware ------------- The booting sequence for the PC164 starts with loading the serial ROM (SROM) program into the on-chip L1 Instruction Cache (ICache). The SROM program lives in the ICache and can thus not be any bigger than 8 kB. This step is supported by the 21164 architecture and happens automatically after a power up or system reset. This SROM program does the following 1. Initialize the CPU’s Internal Processor Registers. 2. Set up the on-chip L1 and L2 caches (DCache and SCache). 3. Perform the minimum I/O subsystem initialization necessary to access the TOY clock and the system’s flash ROM. 4. Detect CPU speed using the TOY clock. 5. Set up memory and BCache parameters based on the speed of the CPU. 6. Wake up the DRAMs. 7. Initialize the Level 3 off-chip cache (BCache). 8. Test the entire system memory. 9. Scan the system flash ROM for a special header that specifies where and how the system flash ROM firmware should be loaded. 10. Copy the contents of the system flash ROM to main memory and begin flash ROM code execution. No user intervention is needed (nor possible without modifying jumper settings) and no screen output is generated during this phase. Flash ROM Firmware ------------------ The content of the Flash ROM, often called "the firmware", will depend on the operating system that must be booted. UNIX and VMS use something called 'the Alpha SRM Console', while NT uses something called 'the ARC Console (for Advanced RISC Computing)', sometimes called 'AlphaBIOS'. This Firmware provides Power-Up diagnostics and initialization of the system, plus an interface for the operator to select the source of the operating system to be loaded. This firmware includes the operating system primary bootstrap mechanism with necessary minimum process management, memory management code, and drivers for the SCSI and ethernet ports. The SRM console also includes 'examine' and 'deposit' commands. It is not clear to me whether, once fully booted, any of these operating systems use any of the Flash ROM code (unlike PC BIOS code). I believe VMS and UNIX do not, while NT might. The Flash ROM Firmware boots the operating system by reading the appropriate disk and directory, or by asking for help over the network using BOOTP. Depending on the configuration, these actions happen automatically or after user input at the console. PC164 Evaluation Board development environment (including our Alpha-VME Cards) ============================================== SROM Firmware ------------- Nothing Special, cf above. Flash ROM Firmware ------------------ There is a special Debug Monitor Firmware image that comes with the Software Development Kit. This image must be loaded and replaces the previous SRM or ARC firmware that came with the PC164 (some system's FlashROM are big enough to hold several images, but not on the PC164). The Debug Monitor Firmware supports loading a program from different sources (ROM, serial line, or ethernet). One can then run the program, step through the program, set breakpoints, examine and change memory location. The limitation is that this debugging is all in assembly language, with no debugging information (i.e. no routine or variable names). The Debug Monitor Firmware also includes a Ladebug Server, which allows remote, source level debugging from a standard DEC UNIX Alpha system, using the standard DEC UNIX Ladebug debugger. Our development cycle is then: - write code on the Alpha UNIX station in C (maybe C++), - compile the code with the special header files of the SDK, - link the code with the libraries from the SDK and one extra startup routine, - strip the UNIX headers off the executable using the CSTRIP tool of the SDK, - tell the alpha target node to go get the executable using BOOTP/TFTP, - stop execution at a breakpoint on the first line of code on the alpha target, - start the Ladebug server on the alpha target, - start the Ladebug session on the Alpha UNIX node (can be via an X-Window), - view and step through source line code and variables from Ladebug. Level 2 On-line Production Environment ===================================== SROM Firmware ------------- Nothing Special Flash ROM Firmware ------------------ The SDK includes the source code for the Debug Monitor Firmware. We will probably want to modify this default code so that it automatically requests BOOTP information (i.e. get its own IP address), and fetches a pre-defined executable from the UNIX host over TFTP (maybe using the IP address to build a node specific file name and avoid having node specific versions of the firmware). This would happen automatically after power up or system reset. This would avoid having to type some commands at the console every time the system is reset. Another modification to the default Firmware, or probably something done in the executable itself is to automatically start the Ladebug server in order to allow remote debugging and "jumping in" at any later time without needing to first access the local console(s), halt program execution, and start the Ladebug server. We don't know how to do any of the above quite yet, but we expect this is all doable... The other related issue for the production environment is being able to reboot/reload the target nodes without having to physically push buttons. It is currently planned that a special VME register on the Alpha boards will allow TCC to selectively reset a node over VME. During code development, the programmer can use the attached terminal or terminal emulator output to print out all kinds of progress messages using the printf function. But in production environment screen output should be limited to initialization, and other non-time critical phases. We can maybe put out a few characters for monitoring events (it is nice to have a visual cue that the system is running smoothly). The relevant order of magnitude is 1 millisecond per character output. Prototype work and new alpha card commissioning =============================================== SROM Firmware ------------- The SDK contains the source code and the tools to rebuild the Serial ROM image. The SDK can produce a file that is understandable to a standard ROM programmer (Intel Hex format). The SROM contains a mini-debugger in addition to the setup code mentioned earlier. Some jumpers on the motherboard are used to force the SROM code to stop in the SROM Firmware instead of loading the Flash ROM. There is a special RS232 port on the motherboard (separate from the COM1/COM2 ports which hang from the ISA bus) to connect a VT100 and communicate with the SROM mini-debugger. We can use the SROM mini-debugger to examine and deposit data in control registers and thus do some limited hardware debugging. For example to check out and exercise the first prototype alpha boards and for an initial poking at the Universe VME interface or the magic Bus interface(s). The mini-debugger's primary purpose is to debug hardware up to the point that the memory interface works, thus allowing the Alpha Debug Monitor to be loaded to debug other parts of the system (or user software). The second use of the SROM is to be able to write the Debug Monitor Firmware image (or our own customized version) into a blank FlashROM . This is done by sending an ASCII-encoded file (Motorola S-Record Format) over the RS-232 serial line. The SDK also contains the tools to produce the S-Record file. This implies that instead of connecting a dumb VT100 terminal to the mini-debugger port, one connects to a serial port from an Alpha NT or Alpha UNIX station and use the ULOAD tool of the SDK to download the S-Record file. A motherboard jumper enables/prevents updating the FlashROM. To my understanding, this is what Myron asked us to help with. It would clearly be useful for us to gain some level of expertise with this environment. This may become very valuable later on to diagnose hardware problems with our production cards. Flash ROM Firmware ------------------ Once a valid Firmware image is loaded (Debug Monitor Firmware, or the ARC, or SRM console) one can update the firmware image from a floppy (or even a CD-ROM for some versions of Firmware). If the FlashROM Firmware becomes corrupted, one can use the SROM mini-debugger to re-write the FlashROM as described just above. But there is a safety net. The default FlashROM image includes a "fail-safe" booter. This is a small (64KB) alternate firmware program that provides a minimum recovery procedure. The fail-safe booter expects to find a floppy with the fwupdate.exe program to load and execute. There is a jumper on the motherboard to force the SROM firmware to load the fail-safe booter instead of the regular Console or Debug Monitor Firmware.