Build is only tested on a Linux system, but should be possible on any system using the GNU toolchain and the ELF file format. The tools required are:

• GCC
• binutils
• make
• dosfstools and mtools (optional)
• xorrisofs (optional)

To build a 32-bit image, change directory into the build32 directory and type make. The result is a memtest.bin binary image file which can be booted directly by a legacy BIOS (in floppy mode) or by an intermediate bootloader using the Linux 16-bit boot protocol and a memtest.efi binary image file which can be booted directly by a 32-bit UEFI BIOS. Either image can be booted by an intermediate bootloader using the Linux 32-bit or 32-bit EFI handover boot protocols.

To build a 64-bit image, change directory into the build64 directory and type make. The result is a memtest.bin binary image file which can be booted directly by a legacy BIOS (in floppy mode) or by an intermediate bootloader using the Linux 16-bit boot protocol and a memtest.efi binary image file which can be booted directly by a 64-bit UEFI BIOS. Either image can be booted by an intermediate bootloader using the Linux 32-bit, 64-bit, or 64-bit EFI handover boot protocols.

In either case, to build an ISO image that can be used to create a bootable CD, DVD, or USB Flash drive, type make iso, The result is a memtest.iso ISO image file. This can then be written directly to a blank CD or DVD, or to a USB Flash drive, which can then be booted directly by a legacy or UEFI PC BIOS.

Note that when writing to a USB Flash drive, the ISO image must be written directly ('dumped') to the raw device, either by using the dd command or by using a utility that provides the same functionality.

When using an intermediate bootloader, either the memtest.bin file or the memtest.efi file should be stored in a disk partition the bootloader can access, and the bootloader configuration should be updated to boot from that file as if it were a Linux kernel with no initial RAM disk. Several boot command line options are recognised, as described below. If using the 16-bit boot protocol, Memtest86+ will use the display in text mode (640x400). If using the 32-bit or 64-bit boot protocols, Memtest86+ will use the display in either text mode or graphics mode, as specified in the boot_params struct passed to it by the bootloader. If in graphics mode, the supplied framebuffer must be at least 640x400 pixels; if larger, the display will be centred. If the system was booted in UEFI mode, graphics mode must be used.

For test purposes, there is also an option to build an ISO image that uses GRUB as an intermediate bootloader. See the Makefile in the build32 or build64 directory for details. The ISO image is both legacy and UEFI bootable, so you need GRUB modules for both legacy and EFI boot installed on your build system (e.g. on Debian, the required GRUB modules are located in packages grub-pc-bin, grub-efi-ia32-bin and grub-efi-amd64-bin). You may need to adjust some path and file names in the Makefile to match the naming on your system.

The GRUB configuration files contained in the grub directory are there for use on the test ISO, but also serve as an example of how to boot Memtest86+ from GRUB.

This is the developer's guide to the Memtest86+ source code. The user's guide can be found in the README.md file in the top level directory.

Code Organisation

The source code is divided into the following categories, each contained in a subdirectory of the same name:

• app

  The main application and framework for running the memory tests.

• boot

  The code that runs from the BIOS or bootloader entry point to the start of the main application.

• lib

  The subset of the C standard library that is used by Memtest86+ plus other hardware-independent low-level support functions.

• system

  Low-level support functions that interface to the hardware.

• tests

  The individual memory tests.

The boot code is mostly written in AT&T syntax x86 assembly language. The remaining code is written in C with a smattering of inline assembly code.

Each category is further subdivided into multiple source files, splitting the code into small units of closely related functionality. For the C code, the API for each unit is defined in a header (.h) file and the implementation (if required) is found in the correspondingly named source (.c) file.

Code Documentation

Doxygen can be used to automatically generate HTML documentation for the API for each code unit from the comments in the C header files. To regenerate the documentation, change directory into the doc subdirectory and run doxygen.

Coding Conventions

C Code

Macro names and enumeration values are written in upper case separated by underscores. All other identifiers are written in lower case separated by underscores. Both excessive length and excessive abbreviation are avoided.

Line length is normally limited to 120 characters.

Indentation is 4 spaces. No hard tab characters are used.

Opening braces for function bodies are put on a new line. Other opening braces are put on the same line as the construct that introduces them.

The C11 dialect is used. In particular, variable declarations and statements are interspersed and loop variables are declared within the for loop construct.

Assembly Code

Labels are written in lower case separated by underscores. Op-codes and register names are written in lower case.

Line length is normally limited to 120 characters.

Indentation is 8 spaces using hard tab characters.

The C preprocessor is used for defining constant values and expressions. Macro names are written in upper case separated by underscores.