Two per-CPU streams alternate NT-store bursts of a fresh PRSG sequence with read-verify of the previous round, forcing write-to-read turnarounds and row conflicts; odd rounds insert idle gaps to provoke PMIC load steps. Targets DDR5-era interface faults (link SI, marginal XMP/EXPO training, voltage droop) that on-die ECC cannot correct
Moving PRSG vector kernels from mov_inv_rng.C to a shared module in tests/
Run the random sequence test (now #4) and Modulo-20 (now #6) before the 64-bit shifting pattern test (now #8), so that every fault class is probed early in the pass.
Trade the walker's redundant repetitions (3 -> 1 iteration, plus only every other offset on the fast first pass) for more never-repeating work (random sequence 24 -> 96 rounds, Modulo-20 6 -> 9), at unchanged pass time.
Replace tests 5 & 8 with a single moving inversions test using per-lane
xorshift sequences and non-temporal stores. Kernels (inline asm) are picked
at runtime via the new system/simd module: AVX2, SSE2 or scalar, with the
tier shown in the test name.
Fix and enable the AVX/XCR0 startup code and decode the XSAVE/AVX/AVX2 CPUID flags.Suite shrinks from 11 to 10 tests.
* build: Change the memtest.efi to mt86plus on LoongArch
Change the main binary from memtest.efi to mt86plus.
* build: Add GRUB iso support on LoongArch64
Enable the GRUB iso support on LoongArch64, it requires the LoongArch64
Linux ENV, so it is not possible create it on x86-64 Linux ENV.
* README: Add LoongArch content
Added LoongArch info and how to build, adjusted some style.
Signed-off-by: Chao Li <lichao@lonogson.cn>
* Merge bootsect.S and setup.S into header.S
Currently, Memtest86+ provides two (three counting mbr.S) different
headers: bootsect.S and header.S that together with setup.S are used
to build the final binaries:
- bootsect.S for booting from the legacy BIOS, used in memtest.bin.
- header.S for booting from the UEFI, used in memtest.efi.
Both support loading by an intermediate bootloader. Also, both are
derived from the Linux kernel, but from a very different chapter in its
evolution. FDD loading was removed a very long time ago, many, many
years before adding PE/COFF headers for UEFI. Also, the PE/COFF headers
are large (even larger for x86-64) and take a lot of very limited space,
leaving almost no headroom for the actual code.
This commit merges bootsect.S and setup.S into header.S adding BIOS
(FDD) loading support, which should eventually enable to maintain a single,
all-in-one binary that can be booted either by an intermediate bootloader
(such as GRUB or LILO), UEFI and BIOS. Easier and less confusing for users,
as I have continued to see cases when people assume memtest.bin is needed
for non-UEFI systems, even if never intended for FDD loading.
To ensure we have enough space for both the boot code (limited to 512B
including Linux boot header and address of the New EXE header) and
UEFI headers, the PE/COFF headers got moved into the ".setup" section
of the code where *currently* we have 1024B total and about 90B free.
Should more space be needed in the future, we can grow that section or
perhaps even better - move PE/COFF into its own section that will not
even need to be loaded.
Overall, the code got copied from bootsect.S and setup.S with very, very
minimal changes, most importantly:
- Dedicated routine for printing strings (print_string) got added and
lives in the ".bootsect" section.
- Print "Loading " message almost immediately after BIOS loads and
calls code from the .bootsect" section, even before setting up
the custom FDD parameter table. The sooner the better.
- Set DX to 0x0000, as the code depends on its value. While the BIOS is
expected to set DL register to the boot drive number which is 0 for FDD,
to my knowledge there is no guarantee for DH to have any particular
value. Also, when executing "MZ" signature as x86 instructions,
the original value of DX becomes instantly and irrevocably lost. This
is fine as we only support booting from FDD anyway.
- Print "Memtest86+" and its version after loading the ".setup" section.
We can get the string from mt86plus_version (kernel_version), no need
to duplicate in the boot sector where we are very space limited and as
a bonus we can provide the version information.
As diffstat shows a lot of code changed and added, it may be easier use
the following commands:
diff -Nur bootsect.S header.S
diff -Nur setup.S header.S
While there are several more changes and fixes I would like to make in the
boot code (some of them were already included in the earlier RFC version
[1] before we got UEFI signing support added) for now I tried this to be as
least disruptive as possible and avoid unnecessary code changes to make
the review easier.
[1] https://github.com/memtest86plus/memtest86plus/pull/136
* Bye bye memtest.bin and memtest.efi, long live mt86plus
With the efi binary providing the BIOS floppy loading functionality,
there is no need to support separate memtest.bin file any longer.
Remove memtest.bin from {build32,build64}/Makefile, replace memtest.bin
amd memtest.efi with mt86plus eveywhere to avoid confusion with
other memtests.
Also, unify build32/Makefile and build64/Makefile by removing
unnecessary differences between them, like extra spaces or
different OBJS order.
Finally, update README.md, HOW_TO_DEBUG_WITH_GDB.md and other
places that had a reference to memtest.{bin,efi}. Note that for
debug_memtest.sh, mt86plus.efi is used.
* badram: Make DEFAULT_MASK depend on ARCH_BITS, not x86_64 architecture.
* badram: Don't display leading zeros for BadRAM addresses.
* badram: Merge patterns immediately when there is no additional cost.
The current algorithm only starts merging patterns when num_patterns
equals MAX_PATTERNS, which can lead to having several patterns that
could have been merged into one at no additional cost. e.g.
patterns = [
(0x00, 0xfffffffffffffff8),
(0x08, 0xfffffffffffffff8)
]
can appear, even though
patterns = [
(0x00, 0xfffffffffffffff0)
]
represents the exact same addresses at the same cost.
So, at the same time as we test whether an address is already covered,
also check if we can cheaply combine the new address with an existing
pattern.
* badram: Factor out code that wraps to a new line when necessary.
In preparation for next commit.
* badram: Add more modes for recording/displaying error maps.
The original code just supported recording and displaying patterns suitable
for use with the Linux BadRAM extension or GRUB badram command. With some
minor changes it can be made to record address ranges and display them
either in the format used by the Linux memmap boot command line option
or as a simple list of memory page numbers (which can be used with the
Windows bcdedit program).
* badram: Increase the number of stored patterns/ranges.
* Update README to include the new error reporting modes.
This was mentioned in the individual test descriptions in the README,
but easily missed (issue #384). Add a note in the BadRAM section of
the README and also in the error display heading.
* Add boot option to rotate screen display through 90 degrees.
Some machines have a detachable display that can be used in either
portrait or landscape orientations, and require software to rotate
the displayed image accordingly. There is no way to detect the
current orientation through the BIOS, so provide a boot option to
control this. Hopefully we only need to support one (+90 degree)
angle.
Note that the rotate option only works in graphical mode. When booted
by a legacy BIOS using text mode, we have to rely on the BIOS to do
what's necessary.
* Extend boot command line options for display screen control.
Replace "rotate" option with "screen.rhs-up" and "screen.lhs-up" to
allow rotation in either direction. Add a "screen.mode=<w>x<h>"
option to set a preferred width <w> and height <h> for the UEFI
frame buffer. Also allow "screen.mode=bios" to use the default
UEFI frame buffer resolution.
* Add more debug output for EFI frame buffer mode.
* Replicate command line parsing of screen options in efisetup.c.
Trying to do it only once in screen.c didn't work, because static
variables initialied to zero are placed in the bss section, and we
don't zero the bss section until after efisetup() is executed.
The resulting code is in fact smaller, because the compiler can
optimise better when everything is local.
* Add a boot command line option for efisetup debug.
* Improve EFI debug test screen pattern.
* Document the new screen and efidebug boot command line options.
* Fix typo in README.
Read the memory controller configuration (instead of just relying on SPD data) to get the actual live settings.
Currently supported platforms:
* Intel SNB to RPL (Core 2nd Gen to Core 13th Gen) - Desktop only (no Server nor Mobile)
* AMD SMR to RPL (Zen to Zen4) - Desktop only (no Server, Mobile nor APU).
Individual commits below for archival:
* First functions skeleton for reading IMC/ECC Registers
* Change directory name from 'chipsets' to 'mch' (Memory Controller Hub)
* Add Intel HSW and fix new files encoding
* First Intel HSW IMC implementation
* Add an option to disable MCH registers polling
* Remove old include from Makefiles
* Better Makefile and padding fixes
* Statically init 'imc' struct to generate string relocation record
* Small typos & code fixes
* Add IMC support for Intel Core 6/7/8/9th Gen (SKL/KBL/CFL/CML) This is a bit more complex than Haswell and below because MMIO switched to 64-bit with Skylake (lot of) betatesting needed
* Add IMC read support for Intel SNB/IVB (2nd/3rd gen Core)
* Fix hard-lock on Intel SNB/IVB due to wrong access type on MCHBAR pointer
* Move AMD SMN Registers & offsets to a specific header file
* Add IMC Read support for AMD Zen/Zen2 CPUs
* Change 'IMC' to 'MCH' in Makefiles to match actual mch/ directory
* Add IMC Reading support for Intel ADL&RPL CPUs (Core Gen12&13)
* Add support for Intel Rocket Lake (Core 11th Gen) and AMD Vermeer
* Add IMC reading for AMD Zen4 'Raphael' AM5 CPUs
* Various Cleanup #1
Change terminology from Intel-based 'MCH' (Memory Controller Hub) to more universal 'IMC' (Integrated Memory Controller) Integrate imc_type var into imc struct. Remove previously created AMD SNM header file
* Various Cleanup 2
* Change DDR5 display format for IMC specs
DDR5 Freq can be > 10000 and timings up to 63-127-127-127, which overwflow the available space.
This commit remove the raw frequency on DDR5 (which may be incorrect due to Gear mechanism) and leave a bit of space to display the Gear engaged in the future
* For 64-bit images, use the physical address as the test pattern in test 2.
This will make it easier to diagnose faults.
* Disable test 1 by default (issue #155).
Test 2 provides the same test coverage. Test 1 may make it slightly easier
to diagnose faults with a 32-bit image, so leave it as an option.
* For 32 bit images, use the physical address to generate the offset in test 2.
Detecting a stage change and using that to reset the offset counter
could fail when the config menu was used to skip to the next test
(issue #224).
* Avoid FAIL banner being partially overwriten by new errors
* Remove beta on main title
* Remove v6 Beta Disclaimer & some README.me changes for release
Most legacy BIOSs will support USB legacy keyboard emulation. Using that
will avoid having to reserve memory for the USB drivers, and should
improve the chance of having a working keyboard without having to work
around various USB device quirks.
* Add new heap manager.
* Convert OHCI driver to use new heap manager.
* Convert UHCI driver to use new heap manager.
* Convert EHCI driver to use new heap manager.
* Convert XHCI driver to use new heap manager.
* Convert SMP to use new heap manager.
* Add a "usbinit" boot option to handle various buggy USB devices.
This replaces the "keyboard=buggy-usb" option, and adds a second
workaround to handle the problem seen in issue #107.
When USB keyboard detection is enabled, physical memory pages are reserved
for use by the USB drivers. The physical memory map exposed by pmem.h does
not indicate where the ACPI tables reside, so we may end up using pages
that contain ACPI tables (or for that matter, the boot parameters and boot
command line). So rather than introduce a more complicated memory allocation
scheme, make sure we have finished with all the data passed to us by the
BIOS and/or boot loader before we start probing for USB devices.
The only downside to this is that it is no longer possible to interactively
disable parsing of the ACPI tables - that can now only be done by using the
"nosmp" boot option.
Sam Demeulemeester
Sam DemeulemeesterandBerbe
Gabriel Mongaras
David Corvaglia
Chao Li
01e3
martinwhitaker
a1346054
Sam Demeulemeester
Martin Whitaker