Memtest86 v6.00 with UEFI support released
memtest.org
memtest.org
and memtest86 from passmark has a lot of nice features that aren't available MemTest86+, includin UEFI support, writing logs to disk, fully 64bit code, additional RAM tests, benchmarking, row hammer testing and more?
and passmark shows that: https://www.memtest86.com/compare.html
Memtest86plus ???
> Add support for SDRAM
Surely it had support for SDRAM before, since DDR, DDR2, ... are all SDRAM.
Edit: I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM", referring to Single Data Rate SDRAM.
I have seen some dumb naming choices in my time but that might just take the cake.
Every machine in the shop, every server deployed, every customer repair (industrial control) gets memtest86+ after assembly and before going any further.
In that situation, it's so nice to actually have some evidence to point to (a photo of the test results screen).
We had a Dell R640 rackmount that arrived and part of our burn-in testing is running memtest, which said one of the modules had a problem. I contacted Dell support and they had me run the Dell built in memory test, which IIRC took something less than an hour. Memtest was taking around a day to generate this error. Dell support didn't want to replace it because their built in test wasn't showing anything.
This was maybe the 5th or 6th same model server we had gotten and all of them were clean, so I really didn't want to put this into production. Could have been a memory problem, could have been CPU or motherboard issue...
Went back and forth a few times, and finally contacted our sales person asking them what our return window was for the server. They reached out to support, who contacted us and said "Fine, we'll send you a replacement, but only this one time!" Usually I've gotten really good support from Dell Pro Support, but this time I was pretty disappointed.
As I said, Pro Support has been fantastic for every other issue I've had, it was just this one memory issue.
For comparison, a couple years ago we had a machine in production that system load went crazy on, 300-400 in "uptime". Nothing was really goning on on the machine. I ended up with 2-3 engineers helping me out as the path of the sun moved me into different support regions. They couldn't pin it down to any specific thing, but ended up replacing a couple SSDs, the RAID card, and the backplane. I'm pretty sure it was the LiteOn SSDs soiling the sheets, but that's what they ended up doing and we've been good since then.
Memtest, I love you.
Windows is (was?) so deeply intertwined with x86 that MS bastardized their early ARM platform with ACPI and UEFI so they didn't have to write a new kernel HAL. Perhaps this has changed since Win RT.
The RPi can also run tianocore, an open source reference uefi.
The question is why would you want to? Almost nothing in the UEFI world beyond core system boot is actually used in practice, and even there all the hard/interesting bits (device selection and bootstrapping, initial security and signature checks) have to happen before UEFI entry anyway. So it's all duplicated code. Your BIOS has a bunch of boot hooks that have to run before UEFI starts, then UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite.
It's all just a mess. Frankly if you want an implementation of a clean but featureful boot environment for PCs that extends across architectures, look to Chromebooks.
And in fact has been; aarch64 UEFI exists (ex. https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefia... )
> The question is why would you want to? Almost nothing in the UEFI world beyond core system boot is actually used in practice, and even there all the hard/interesting bits (device selection and bootstrapping, initial security and signature checks) have to happen before UEFI entry anyway. So it's all duplicated code. Your BIOS has a bunch of boot hooks that have to run before UEFI starts, then UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite.
Because it's a universal interface for arbitrary OSs to boot without having to special-case every single new board as it comes out. You can take a single standard install media and use it to install on any UEFI ARM board, because they all boot and hand off hardware discovery to the kernel in the same way.
To be clear, I would have preferred that the universal booting solution was Open Firmware. But I'm pragmatic; UEFI is already widely used, so I'd rather have any universal standard rather than a fragmented ecosystem of non-standard options. I don't care that it's ugly, I care that it works and that it can get the market buy-in.
> Look at ChromeOS.
ChromeOS is a single OS from a single vendor, albeit running on multiple architectures. I don't know enough to know how beautiful it can be internally, but in practice a boot firmware that can't boot arbitrary BSD and Linux OSs is useless to me, and the ChromeOS firmware is, to my knowledge, only supported on Chromebook hardware and by ChromeOS and a tiny number of Linux distros that target Chromebook hardware. Ecosystem effects matter.
To make it as easy as possible for people to transition from x86 to arm - having a compatible firmware interface means you don't need to entirely rewrite your deployment tooling when you start deploying arm servers.
> Your BIOS has a bunch of boot hooks that have to run before UEFI starts
What? There is no BIOS on a UEFI system.
> UEFI has to have all of its own drivers for storage and filesystems, just to load an OS kernel that has another driver suite.
Well, yes, you need to have the ability to access the hardware that the OS is on in order to get to the OS. The only way you avoid that is to put the kernel in flash and jump to it directly, but then you're incompatible with existing general-purpose operating systems.
This is... true, but only as an issue of semantics. There are absolutely duplicated framebuffer and storage drivers in the firmware of modern PCs (and probably TPM & CSME too, though that's not my world) (Edit: also USB and PS/2 input device handling). Those BIOS (yes, "BIOS" -- that's what the people who write it call it) splash screens aren't using UEFI, nor is the initial boot device selection in most cases I'm aware of.
UEFI seems clean (well, cleanER) only when viewed from downstream.
If you're using a desktop machine with a plug-in GPU, the driver for the GPU is carried on the card itself. That driver is implemented according to the UEFI specification. There's no way to initialise the hardware in order to display a splash screen unless you're already running the DXE layer (Driver eXecution Environment - there's a clue in the name), so the splash screen is absolutely using UEFI. For devices with on-board GPUs you could theoretically do something different, but I haven't seen any vendors shipping PEI drivers (they have a different header) and I've pulled apart a lot of firmware images in my time. Storage devices are subject to similar constraints (if you've got a plug-in SAS controller the firmware has no idea how to speak to anything attached to it until DXE time). Boot Device Selection is also part of the UEFI spec, and is one of the meaningful benefits of UEFI over legacy BIOS (eg, the OS being able to explicitly request what gets booted next through a generic interface).
There is some potential duplication between the PEI and DXE layers, since you need to access the TPM (for example) in both phases, and also some storage code ends up in PEI because you need to handle stuff like self-encrypting drive unlock on resume and aren't going to execute any of the DXE layer. Looking through a real world UEFI tree, the only USB code in PEI is to support recovery from USB after a bad flash, and I can't find any input device handling there at all.
So I'm honestly not sure what you're talking about. It could be that you're calling PEI "BIOS" and DXE "UEFI", but even then most of what you're describing doesn't seem to line up with real-world implementations. A lot of UEFI is ugly and overcomplicated, but pointing at something that only tries to solve a small subset of the problems (like the Chromebook implementation) as an example of how things should be done isn't really a great argument. UEFI is actually effectively solving two separate problems here - it's ensuring the hardware is in a well-defined state and also providing an environment for drivers to make use of that hardware. Both are required for booting a system, but only one is required for the resume path[1]. The ChromeOS firmware doesn't have to deal with any drivers or bootloaders or early boot code that isn't supplied with the device, so can skip a whole bunch of this.
[1] Yes, ACPI does delegate most of this work to the OS, not to the firmware. But there's still a bunch of setup that needs to occur before handing control back to the OS - imagine the (real) case of an Intel SATA controller that can be configured to expose a legacy IDE compatibility interface, a spec-compliant AHCI interface, or a weird Intel-specific "RAID" interface. An OS using generic AHCI drivers has no idea about any of this, so it's up to the firmware to set the chip back up correctly before handing control to the OS. This is assuming traditional S3 - in S0ix environments we rely on runtime power management of the chip to get it to power consumption so low there's no benefit to actually powering off the chip and having to deal with reprogramming it from cold, and maybe once the entire world has transitioned to S0ix we can get rid of some of the complexity here.