SRM, AlphaBIOS and MILO Explained: How Alpha Machines Boot

Every Alpha machine boots through one of a small family of console firmwares, and which one you have decides which operating systems you can run. If you have ever stared at a >>> prompt or a blue AlphaBIOS menu wondering what to do next, this is the map.

Why Alpha has more than one firmware

Digital designed Alpha to run several very different operating systems: OpenVMS, its UNIX (later Tru64), and, after a deal with Microsoft, Windows NT. Each came with its own expectations about how a machine should start up. VMS and UNIX wanted a powerful, scriptable console defined by the architecture itself. NT wanted the ARC firmware model already used on MIPS workstations, with a FAT system partition and a menu-driven boot manager.

Rather than force one model on everyone, Digital shipped both, and Linux, arriving later, learned to live with either. The result is a set of consoles that overlap in some places and are entirely incompatible in others.

The three consoles at a glance

Many Digital systems carried both SRM and AlphaBIOS in flash and could switch between them. API's boards were more specialised: the UP1000 shipped with AlphaBIOS, while the UP2000 used SRM, reflecting their positioning as desktop and server boards respectively.

SRM: the architectural console

SRM takes its name from the Alpha System Reference Manual, which defined how an Alpha console should behave. It is the most capable of the three: it enumerates hardware, runs diagnostics, manages environment variables in non-volatile storage, and boots from disk, tape, CD or network using a consistent device naming scheme.

It is also remarkably consistent across two decades of hardware. A command sequence that works on an early AlphaServer will, give or take a few device names and newer options, work on the last EV7 systems. That stability is a big part of why operators of long-lived OpenVMS and Tru64 installations trusted it.

Essential commands

>>> show config          # CPUs, memory, PCI devices
>>> show dev             # bootable devices: dka0, dqa0, ewa0...
>>> show *               # all environment variables
>>> set console serial   # use serial port for console I/O
>>> init                 # reset and apply changes
>>> boot dka0 -flags 0   # boot disk dka0 with flags "0"

Device names encode the controller type and position: dka for the first SCSI adapter, dqa for IDE, ewa for the first Tulip-family network interface, and so on, followed by a unit number.

Boot variables that matter

bootdef_dev

The default boot device used by a plain boot command or on auto-boot.

boot_osflags

Flags passed to the loader. Their meaning depends on the OS: a root and flag pair for OpenVMS, a mode letter for Tru64, an aboot configuration entry for Linux.

boot_file

An optional file name passed to the secondary loader.

auto_action

What to do at power-on: halt to stop at the prompt, boot to boot automatically, or restart.

console

graphics or serial. If you lose the display, a serial terminal usually brings it back.

os_type

On dual-firmware systems, selects which console loads at power-on. Setting it to nt and running init hands control to AlphaBIOS.

aboot: how Linux boots from SRM

SRM cannot load a Linux kernel on its own. It reads a boot block from the start of the disk, which points to a secondary loader. For Linux that loader is aboot. It understands ext2-family filesystems and ISO9660, reads /etc/aboot.conf, and passes the kernel command line.

# /etc/aboot.conf: entry:partition/path arguments
0:2/vmlinuz ro root=/dev/sda3 console=ttyS0
1:2/vmlinuz.old ro root=/dev/sda3 console=ttyS0
2:2/vmlinuz ro root=/dev/sda3 single

With that file in place, boot dka0 -flags 1 boots the fallback kernel, and boot dka0 -flags i drops into aboot's interactive prompt, where you can type a partition, path and arguments by hand. That interactive mode is the single most useful recovery tool on an SRM Linux box.

aboot requires the disk to use a BSD disklabel with room reserved at the front. Tools such as swriteboot install the loader and abootconf tells it which partition holds its configuration. Our guide to running Linux on Alpha hardware today walks through a full install.

AlphaBIOS and ARC

Early Alpha NT machines used ARC firmware. AlphaBIOS replaced it in the mid-1990s with a friendlier, PC-like setup screen while keeping the same underlying model. It boots operating systems from a FAT system partition, where Windows NT keeps its osloader.exe and hardware abstraction layer, and presents boot choices as a menu.

AlphaBIOS is simple to use but closed to anything that does not follow the ARC conventions. It cannot boot OpenVMS, Tru64 or the BSDs. Linux gets in through MILO, which AlphaBIOS can load as if it were just another OS loader. For more on why NT mattered so much to the platform's commercial story, see Windows NT on Alpha and FX!32.

MILO: the Linux miniloader

MILO, the Linux Miniloader, was built in the late 1990s to boot Linux on machines that lacked SRM. It carries cut-down Linux driver code so it can initialise disks and read an ext2 filesystem, then loads and starts the kernel. It can be launched from AlphaBIOS or ARC, from a floppy using a board's fail-safe loader, and on some boards it could even be flashed in place of the stock firmware.

MILO> show
MILO> boot sda2:vmlinuz root=/dev/sda3 console=ttyS0

MILO has been unmaintained for a long time. It works, but its drivers and filesystem support are frozen at around the turn of the century, so keep a small plain ext2 /boot partition and test new kernels carefully. On boards where an SRM image is available, most people now prefer SRM plus aboot.

Which OS needs which firmware

• OpenVMS: SRM only.
• Tru64 UNIX / Digital UNIX: SRM only.
• Windows NT: AlphaBIOS or ARC only.
• NetBSD and OpenBSD: SRM only.
• Linux: SRM with aboot is the preferred path; AlphaBIOS or ARC with MILO works on boards without SRM.

If you are testing boot procedures before touching real hardware, the ES40 emulator runs a genuine SRM image, while QEMU skips firmware entirely. Our guide to emulating Alpha with QEMU and ES40 covers both.

Further reading on this archive

• Restoring a UP1000 motherboard: including AlphaBIOS firmware recovery.
• UP2000 board: API's SRM-based dual-processor board.
• Compaq, API and Samsung Alpha strategy: the December 1999 announcement that shaped the later platform.