SRM console is used by Alpha systems as Unix-style boot firmware. Tru64 Unix and OpenVMS depend on it and Linux can boot from it. You can recognize SRM console as a blue screen with a prompt that is presented to you on power-up.
Most Alpha systems have both the SRM and ARC/AlphaBIOS console in their firmware. On one of these machines, if your machine starts up with ARC/AlphaBIOS by default, you can switch to SRM through the "Console Selection" option in the Advanced CMOS Setup menu. To make the change permanent, you should set the os_type environment variable in SRM to "OpenVMS" or "Unix", like this:
>>> set os_type Unix |
Either one will work to boot Linux. However, if you intend to dual-boot OpenVMS on this machine, you must set os_type to "OpenVMS". Conversely, to return to ARC/AlphaBIOS, you can set os_type to "NT".
Some older systems may not have both SRM and ARC in firmware as shipped. On these systems, you will have to upgrade your firmware. See http://ftp.digital.com/pub/DEC/Alpha/firmware for the latest firmware updates and instructions.
A few older systems (primarily evaluation boards such as the 164SX and 164LX) are "half-flash" systems, whose firmware can hold SRM or AlphaBIOS, but not both. If you have one of these machines, you will have to reflash your firmware with the SRM console using the AlphaBIOS firmware update utility. Again, see http://ftp.digital.com/pub/DEC/Alpha/firmware for firmware images and instructions. If you wish to return to AlphaBIOS on these machines, you may rerun the firmware update utility from a floppy in SRM using the fwupdate command. You can also start AlphaBIOS from a floppy using the arc command.
The SRM console works very much like a Unix or OpenVMS shell. It views your NVRAM and devices as a pseudo-filesystem. You can see this if you use the ls command. Also, it contains a fairly large set of diagnostic, setup, and debugging utilities, the details of which are beyond the scope of this document. As in the Unix shell, you can pipe the output of one command to the input of another, and there is a more command that works not unlike the Unix one. To get a full listing of available commands, run:
>>> help | more |
As well, SRM has environment variables, a number of which are pre-defined and correspond to locations in NVRAM. You can view the entire list of environment variables and their values with the show command (there are quite a few of them, so you will probably want to pipe its output to more). You can also show variables matching a "glob" pattern - for example, show boot* will show all the variables starting in "boot".
Environment variables are categorized as either read-only, warm non-volatile, or cold non-volatile. The full listing of pre-defined variables is detailed in the Alpha Architecture Reference Manual. The most useful pre-defined environment variables for the purposes of booting Linux are bootdef_dev, boot_file, boot_flags, and auto_action, all of which are cold non-volatile.
To set environment variables, use the set command, like this:
>>> set bootdef_def dka0 |
If you set an undefined variable, it will be created for you, however it will not persist across reboots.
The bootdef_dev variable specifies the device (using VMS naming conventions - see Section 5.6.1 for an explanation of these) which will be booted from if no device is specified on the boot command line, or in an automatic boot. The boot_file variable contains the filename to be loaded by the secondary bootloader, while boot_flags contains any extra flags. auto_action specifies the action which the console should take on power-up. By default, it is set to HALT, meaning that the machine will start up in the SRM console. Once you have configured your bootloader and the boot-related variables, you can set it to BOOT in order to boot automatically on power-up.
Finally, two helpful console keystrokes you should know are Control-C, which, as in the shell, halts a command in progress (such as an automatic boot), and Control-P, which if issued from the aboot prompt (or other secondary bootloader) will halt the bootloader and return you to the SRM console.
All versions of SRM can boot from SCSI disks and the versions for recent platforms, such as the Noname or AlphaStations can boot from floppy disks as well. Network booting via bootp is supported. Note that older SRM versions (notably the one for the Jensen) cannot boot from floppy disks. Booting from IDE devices is supported on newer platforms ( 164SX, 164LX, 164UX, DS20, DS10, DP264, UP2000(+), UP1000, UP1100 etc..).
Booting Linux with SRM is a two step process: first, SRM loads and transfers control to the secondary bootstrap loader. Then the secondary bootstrap loader sets up the environment for Linux, reads the kernel image from a disk filesystem and finally transfers control to Linux.
Currently, there are two secondary bootstrap loaders for Linux: the raw loader that comes with the Linux kernel and aboot which is distributed separately. These two loaders are described in more detail below.
SRM knows nothing about filesystems or disk-partitions. It simply expects that the secondary bootstrap loader occupies a consecutive range of physical disk sector, starting from a given offset. The information on the size of the secondary bootstrap loader and the offset of its first disk sector is stored in the first 512 byte sector. Specifically, the long integer at offset 480 stores the size of the secondary bootstrap loader (in 512-byte blocks) and the long at offset 488 gives the sector number at which the secondary bootstrap loader starts. The first sector also stores a flag-word at offset 496 which is always 0 and a checksum at offset 504. The checksum is simply the sum of the first 63 long integers in the first sector.
If the checksum in the first sector is correct, SRM goes ahead and reads the size sectors starting from the sector given in the sector number field and places them in virtual memory at address 0x20000000. If the reading completes successfully, SRM performs a jump to address 0x20000000.