Memtest86+ Memory Testing Across BIOS and UEFI Systems

Why Memtest86+ Tests Memory Outside the Running OS

Memtest86+ addresses a specific gap between routine firmware checks and memory testing from a general-purpose operating system. The README says it is a stand-alone tester intended to provide a more thorough check than the memory tests provided by a computer's BIOS. It can access almost all system memory because it does not run under an operating system and is not restricted to memory already consumed by one.

That execution boundary matters when diagnosing faults that appear only after substantial address and pattern coverage. The README does not specify the duration of a complete pass, the exact error thresholds, or a guarantee that every physical defect will be found. It therefore supports using Memtest86+ as a more demanding memory check, but not as proof that all hardware is fault-free.

The intended users are technicians and computer owners testing x86, x86-64, ARM AArch64 or LoongArch64 systems. Supported machine details are narrower than the architecture labels alone imply. For x86, the README describes Pentium-class or later 32-bit and 64-bit CPUs. ARM support is described for most ARMv8-A AArch64 CPUs using UEFI and ACPI, while LoongArch64 support covers the Loongson 3 and Loongson 2 families. Firmware support is therefore part of the product boundary, not an incidental detail.

How Memtest86+ Loads Across BIOS and UEFI

Memtest86+ runs as a bootable image rather than as a conventional application installed under Linux or Windows. The README documents direct loading by legacy BIOS and UEFI firmware, as well as loading through an intermediate bootloader that implements one of the supported Linux boot protocols.

For x86, a 32-bit build can boot directly through 32-bit UEFI when represented as an EFI image, through legacy BIOS in floppy mode, or through intermediate bootloaders using the Linux 16-bit boot protocol. The same image can also use the Linux 32-bit and 32-bit EFI handover protocols. The x86-64 build supports direct 64-bit UEFI booting, legacy BIOS floppy-mode booting, the Linux 16-bit protocol, and Linux 32-bit, 64-bit and 64-bit EFI handover protocols.

AArch64 supports only UEFI. Its build produces an EFI image that can be booted directly or placed at `EFI/BOOT/BOOTAA64.EFI` on removable media. LoongArch64 builds can boot directly through 64-bit UEFI or through a bootloader using the 64-bit EFI handover protocol. This architecture-specific matrix means that a source build cannot simply be assumed to cover every machine that uses the same general CPU family.

When an intermediate bootloader loads Memtest86+, the bootloader treats `mt86plus` as a Linux kernel without an initial RAM disk. It can pass boot parameters that select text or graphics output. Graphics output requires a framebuffer of at least 640x400 pixels and is mandatory in UEFI mode. A larger framebuffer is centered rather than stretched, according to the README.

Building the First x86-64 Memtest86+ Image

Binary stable and nightly development builds are available from memtest.org. That is the documented path for users who do not need to compile the source. The repository also contains a Linux-oriented build process for developers and users who need a target image for a specific architecture.

The README states that builds are tested on Linux and may be possible elsewhere with the GNU toolchain and ELF file format. Required tools are GCC or cross-GCC, binutils and make. `dosfstools`, `mtools` and `xorrisofs` are optional. For the first x86-64 image, change to the architecture build directory and run its standard make target.

After obtaining a local repository checkout, the documented x86-64 build is:

make

The result is an `mt86plus` binary image. The documentation says it can boot directly through 64-bit UEFI when named `mt86plus.efi`, through legacy BIOS in floppy mode, or through an intermediate bootloader using the Linux 16-bit, 32-bit, 64-bit or 64-bit EFI handover protocol. The executable filename, firmware mode and architecture-specific image must be considered together when preparing boot media.

This is a source-build tutorial rather than a flashing tutorial. The README does not provide a USB device-selection command, so a command that writes the image to a particular drive cannot be derived from its instructions.

Creating a Bootable Memtest86+ ISO

The architecture build directories can also produce `memtest.iso` with `make iso`. The README says this image can be used to create a bootable CD, DVD or USB flash drive and can then be started by legacy or UEFI PC firmware. This route is useful when direct raw-image handling is inconvenient, although the documentation does not describe graphical media-writing software.

From the relevant architecture build directory, the documented command is:

make iso

Readers should expect a `memtest.iso` file in that build context. The README distinguishes this from the raw `mt86plus` image. When writing an ISO directly to USB flash storage, it says the image must be dumped to the raw device with `dd` or through a utility with the same behavior. It does not prescribe a universal `dd` command because selecting the target device requires system-specific information.

A direct boot image offers more control over firmware entry and bootloader protocols, while an ISO adds a conventional removable-media path. The project also documents test ISO targets using GRUB as an intermediate bootloader. Those targets require matching GRUB modules for both legacy and UEFI boot, according to the README.

For an intermediate bootloader that does not boot the ISO directly, place `mt86plus` in a partition the bootloader can access and configure that bootloader to treat the file as a Linux kernel with no initial RAM disk. This approach adds a dependency on bootloader storage access and configuration, while direct BIOS or UEFI loading avoids that particular layer.

Architecture-Specific Build Constraints

The x86 and x86-64 builds are straightforward `make` invocations from `build/i586` and `build/x86_64`. Cross-architecture builds require more specific toolchain decisions. The AArch64 Makefile defaults to an `aarch64-linux-gnu-` cross toolchain when the host is not AArch64. A differently named compiler, linker or object-copy utility can be supplied through `CC=`, `LD=` and `OBJCOPY=`.

For LoongArch64 on an x86-64 Linux host, the README directs users to obtain a cross-compiler from the linked Loongson build-tools releases, unpack it under `/opt/LoongArch_Toolchains`, and add its `cross-tools/bin/` directory to `PATH`. The documented environment setup is:

sudo mkdir /opt/LoongArch_Toolchains -p; cd /opt/LoongArch_Toolchains

After extracting the downloaded archive, the README shows this `PATH` change:

export PATH=/opt/LoongArch_Toolchains/cross-tools/bin/:$PATH

The LoongArch64 build then selects the named cross-toolchain commands:

cd build/loongarch64
make CC=loongarch64-unknown-linux-gnu-gcc LD=loongarch64-unknown-linux-gnu-ld OBJCOPY=loongarch64-unknown-linux-gnu-objcopy

These commands describe the build mechanism, not the first boot session. On a native LoongArch64 Linux system, the README instead says to change to `build/loongarch64` and run `make`. AArch64 output requires UEFI, while LoongArch64 output supports direct 64-bit UEFI and 64-bit EFI handover loading.

What Memtest86+ Does Not Diagnose

Memtest86+ is focused on system memory testing. It should not be selected when the primary question concerns processor behavior, firmware stability, storage performance, display problems or a complete platform inventory. The README says the project aims to access almost all memory and provide a more thorough memory check than a BIOS test, but it does not present Memtest86+ as a general hardware diagnostic suite.

There are also limits inherited from the boot environment. AArch64 is documented as UEFI-only. Direct BIOS or UEFI loading is not interchangeable across all architectures, and an intermediate bootloader adds constraints involving the `boot_params` structure, framebuffer format, minimum 640x400 resolution and boot protocol. A machine with unusual firmware behavior may therefore fall outside the combinations the project claims to support even when its CPU is nominally compatible.

The README includes sections for operation, error reporting, troubleshooting and execution time, but their detailed contents are not present in the available excerpt. As a result, exact pass duration, keyboard shortcuts, error-screen interpretation, documented bugs and test-algorithm specifics cannot be stated here. Users who need those details should consult the corresponding sections in `README.md` or the files under `doc/`.

A real alternative is the basic memory test already present in the computer's BIOS. That alternative starts through the same firmware environment but provides less testing depth according to the README. Another route, testing memory only after booting an operating system, is constrained by memory occupied by that OS. The choice is therefore depth and access versus convenience, not two equivalent full-system validators.

Release Cadence, GPLv2 and Upgrade Considerations

Memtest86+ is released under GNU General Public License version 2. The README describes no restrictions beyond the GPL for private or commercial use, but users who redistribute modified or combined versions must examine the `LICENSE` file and determine how the GPL obligations apply. That is a statement about the project's stated licensing terms, not legal advice.

The repository is not archived, and the last push was on 2026-10-16. Recent release history includes v8.10 on 2026-05-16, v8.00 on 2025-11-23, and v7.20 on 2024-11-11. This history indicates that architecture images and boot paths can change between releases, so an upgrade may involve replacing both the binary image and the method used to place or boot it.

The main upgrade cost is platform verification rather than an application package update. Binary users need to match an image to the CPU architecture and firmware mode. Source builders may need to change cross-toolchain overrides. Intermediate-bootloader users must confirm that the configured kernel-style file remains accessible and that the supplied `boot_params` satisfy current display requirements. The repository separates boot, application, library, system, Secure Boot and architecture-specific build areas, which also means a custom deployment should identify precisely which image variant it needs.

Editorial conclusion

Adopt Memtest86+ when the machine's firmware offers only a basic memory check and the suspected failure requires standalone coverage across supported architectures. Do not treat it as a repair utility or a complete platform diagnostic suite. Verify first that your CPU architecture and firmware use a supported boot path, then obtain the matching stable or nightly image from memtest.org or build the appropriate target under build/.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. memtest86plus/memtest86plus on GitHub
3. Project website
4. README
5. Releases