Alpha/Linux Wiki

Alpha is supported in the mainline Linux kernel under arch/alpha. This page describes how to build a kernel for an Alpha system, natively or with a cross compiler, how to choose a configuration for a particular system, the Alpha-specific kernel parameters, how to debug a kernel, how Alpha patches reach the kernel, and how to report a bug.

The Alpha port has three maintainers: Richard Henderson, Matt Turner, and Magnus Lindholm. Its status in the MAINTAINERS file is "Odd Fixes", and its list is linux-alpha@vger.kernel.org. ¹⁾ Alpha changes are collected in lindholm/alpha.git and mattst88/alpha.git. ^{2) 3)}

Since Linux 6.10, the kernel requires an EV56 (21164A) or later processor, and Linux 6.9 is the last version for the EV4, EV45, and EV5. ⁴⁾ See Current Status: Processor baseline.

A kernel is built on an Alpha system in the usual way. Alpha has one configuration in the tree, arch/alpha/configs/defconfig, a generic configuration. ⁵⁾ It turns on CONFIG_ALPHA_LEGACY_START_ADDRESS, so a kernel built from it does not boot on the Titan, Wildfire, and Marvel systems; see Kernel start address. A running distribution kernel's configuration is usually a better starting point, since it enables the drivers and file systems the distribution relies on. It is in /boot/config-release, or in /proc/config.gz if the kernel was built with CONFIG_IKCONFIG_PROC; make olddefconfig then answers the questions for options that are new in the source tree with their defaults.

zcat /proc/config.gz > .config
make olddefconfig
make menuconfig
make -j$(nproc)
make modules_install
cp arch/alpha/boot/vmlinux.gz /boot/vmlinuz-$(make -s kernelrelease)
cp System.map /boot/System.map-$(make -s kernelrelease)

Alpha has no make install target, so the kernel is copied to /boot by hand. ⁶⁾ If the root file system or its drivers are not built into the kernel, an initramfs is then generated with the distribution's tool, such as update-initramfs -c -k release on Debian or dracut on Gentoo, and an entry for the new kernel is added to /etc/aboot.conf; see aboot. aboot 2.0 cannot load a kernel file split into more than four extents from an ext4 file system, ⁷⁾ and versions before 2.0 do not read XFS; ⁸⁾ see aboot: File systems. Keeping the entry for the previous, working kernel makes it easy to go back to it from the SRM prompt.

The default target on Alpha is boot, which produces a gzip-compressed ELF image, arch/alpha/boot/vmlinux.gz. ⁹⁾ aboot loads either the compressed or the uncompressed image; the uncompressed vmlinux is needed for QEMU (see QEMU).

bootimage, bootpfile, and bootpzfile build images that SRM boots directly, from disk or over the network with BOOTP, without aboot. aboot's own netabootwrap is usually a better choice for network booting, since its images can include an initrd. See Network booting.

A native build on real hardware is slow, so most kernel development is done with a cross compiler and tested in QEMU before real hardware.

Any cross compiler targeting alpha-linux-gnu builds the kernel. The CROSS_COMPILE prefix depends on where the compiler comes from; see Cross compilers. Current kernels need at least GCC 8.1 and binutils 2.30. ¹⁰⁾

The configuration can be copied from the target system's /proc/config.gz as for a native build. The modules are installed into a staging directory, from which they are copied to the target's /lib/modules along with the kernel:

make ARCH=alpha CROSS_COMPILE=alpha-linux-gnu- olddefconfig
make ARCH=alpha CROSS_COMPILE=alpha-linux-gnu- -j$(nproc)
make ARCH=alpha CROSS_COMPILE=alpha-linux-gnu- INSTALL_MOD_PATH=$PWD/staging modules_install

The kernel reaches the target system by copying arch/alpha/boot/vmlinux.gz and the modules over the network, or, for repeated testing, by booting it from the network with an image made by aboot's netabootwrap, which avoids touching the target's disk; see Network booting. Under QEMU, the uncompressed vmlinux is passed to QEMU directly; see QEMU: Kernel development.

The kernel builds only with GCC and GNU binutils. LLVM has had no Alpha back end since 2011, so LLVM=1 does not work, and the Rust support in the kernel is not available on Alpha. See Current Status.

The kernel is compiled with -mno-fp-regs and -ffixed-8, and passes -Wa,-mev6 to the assembler so that it never silently emulates an instruction the target lacks. A generic kernel is built with -mcpu=ev56 -mtune=ev6. A kernel configured for one system uses that system's processor: -mcpu=ev56 for the 21164A systems, -mcpu=pca56 for the AlphaPC 164SX and 164RX, and -mcpu=ev6 or -mcpu=ev67 for the 21264 systems. ¹¹⁾

The system type is chosen under "Alpha system type" in the configuration. A generic kernel runs everywhere, while one configured for a specific system is smaller and faster, because the kernel can call the chipset's routines directly instead of through the machine vector. A kernel built for one system panics with "Unsupported system type" on any other. ^{12) 13)} Distribution kernels are generic.

Other Alpha-specific options:

• CONFIG_ALPHA_EV67 should be set on DP264 systems with 21264A or later CPUs, and is set automatically for the platforms that only take them. ¹⁴⁾
• CONFIG_ALPHA_QEMU builds a kernel that runs only under QEMU. A generic kernel detects QEMU by itself. See qemu-palcode.
• CONFIG_SRM_ENV exposes the SRM environment variables under /proc/srm_environment.
• CONFIG_VERBOSE_MCHECK decodes machine checks; see Debugging.
• CONFIG_NR_CPUS defaults to 32 for generic and Marvel kernels and to 4 for the others, since the kernel's other platforms with working SMP support have at most four processors. ¹⁵⁾

CONFIG_ALPHA_LEGACY_START_ADDRESS decides where the kernel is loaded in memory. It is the one option that commonly makes a generic kernel fail on some systems.

• With the option off, the kernel is linked to load at 16 MiB (physical address 0x1000000), above the larger consoles of the Titan, Wildfire, and Marvel systems. ^{16) 17)}
• With the option on, the kernel loads at the old address, 3 MiB (0x300000), which boot loaders that do not read the kernel's ELF headers, APB and old versions of MILO, have hardcoded. A generic kernel built this way leaves out Titan, Wildfire, and Marvel support entirely. ^{18) 19)}

For a generic kernel, the option is a question under "Kernel hacking", since arch/alpha/Kconfig.debug is included from the generic debugging menu. It defaults to off, but arch/alpha/configs/defconfig turns it on, so a generic kernel built from make defconfig does not run on the DS15, DS25, ES45, GS80, GS160, GS320, ES47, ES80, or GS1280. A kernel for those systems, or one meant to run everywhere, must be built with the option off. A kernel configured for a single system sets the option automatically: on for every platform except Titan, Wildfire, and Marvel. ^{20) 21) 22)}

aboot reads the load address from the ELF headers and boots a kernel built either way, so the option is only needed with APB or an old MILO.

A running kernel shows whether it was built with the option: its "Major Options" line, among the first boot messages, includes LEGACY_START. ²³⁾ Debian's alpha-generic kernel is built with the option off, so its configuration can serve as the starting point for a kernel for these systems; Gentoo's gentoo-kernel uses the same configuration. Gentoo's minimal install CD carries kernels built both ways: gentoo with the option on, and gentoo_nolsa with it off. See Installation: Distribution kernels for the sources.

Besides the kernel's generic parameters, an Alpha kernel reads these from its command line: ²⁴⁾

Most kernel problems are debugged the same way as on any other architecture, from the kernel log on a serial console. A few things are specific to Alpha.

• Early hangs. A kernel that stops before printing anything can often be made to show how far it got with srmcons or console=srm, which print through the SRM console before the kernel's serial driver starts. ²⁶⁾
• Magic SysRq. With CONFIG_MAGIC_SYSRQ, which the defconfig enables, a BREAK on the serial console followed within five seconds by a command key triggers a SysRq command, for example t for a list of tasks or w for blocked tasks. ²⁷⁾ On a system booted from SRM, SysRq b halts to the SRM console instead of rebooting. ²⁸⁾
• netconsole. CONFIG_NETCONSOLE sends kernel messages over UDP to another machine, for systems without a usable serial port. ²⁹⁾
• Machine checks. A machine check is the hardware's report of an error, such as a memory, cache, or PCI bus error, and on real hardware often points to a failing component rather than a kernel bug. CONFIG_VERBOSE_MCHECK makes the kernel decode the error registers of the chipset and processor into readable text instead of a bare error code; CONFIG_VERBOSE_MCHECK_ON and the verbose_mcheck= parameter set the level. ³⁰⁾
• gdb. Alpha has no kgdb support, but a kernel running under QEMU can be debugged with gdb through QEMU's gdb stub. See QEMU: Kernel development.

Alpha patches follow the kernel's normal process, described in the kernel's own Submitting patches guide. A patch that touches arch/alpha goes by email to linux-alpha@vger.kernel.org, with the maintainers on Cc. scripts/get_maintainer.pl lists them:

git format-patch -1 -o outgoing/
./scripts/get_maintainer.pl outgoing/*.patch
git send-email --to linux-alpha@vger.kernel.org --cc ... outgoing/*.patch

The list is archived on lore.kernel.org, which is the easiest way to follow it and to apply a series under discussion, for example with b4 am message-id. Patches that also touch generic code are sent to the subsystem's own list and maintainers as well, as get_maintainer.pl reports.

Accepted patches are collected in the maintainers' trees on git.kernel.org and sent to Linus Torvalds during the merge window, as a pull request tagged alpha-for-vx.y. Alpha changes also reach mainline through other trees: tree-wide cleanups, system call additions, and changes to generic infrastructure that Alpha adopts, such as the generic entry code merged for Linux 7.3. ³¹⁾

Before sending a patch, it should at least build as a generic kernel and boot under QEMU. Changes to code that QEMU does not emulate, such as a chipset other than Tsunami, need testing on the hardware, and the list is the place to ask someone with the system to test.

Report Alpha kernel bugs to linux-alpha@vger.kernel.org. A report should include:

• the kernel version and whether it is a distribution or a mainline kernel,
• the system model and CPU, from /proc/cpuinfo or the SRM show config command,
• the console firmware version (show version at the SRM prompt),
• the full kernel log from boot, captured from a serial console if the system does not come up,
• the kernel configuration, if it is not a distribution kernel.

For a regression, the last kernel version that worked and the first that failed are the most useful information, and a git bisect between them is better still. Bisecting is practical with a cross compiler and a network boot, or under QEMU if the problem reproduces there.

The kernel's own Reporting issues guide describes the process in general. Known problems are tracked in the alphalinux/issues repository, and trackers for the other projects are listed on Bugs.

• Installation
• Toolchains
• Systems, for the kernel platform of each system
• Operating Systems: Linux, for the systems removed in Linux 6.10