Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on March 5, 2021 6:23 am wrote:
> Nowadays things have changed, the EFI system is a lot more complicated, its whole behaviour/specification
> is under NDA (Non Disclosure Agreement), and secure boot will stop you implementing anything
> which is not approved by the manufacturer - or not supported by Window 10.
> So basically none of your sophisticated idea can be implemented, if ECC has to be supported
> it has to be done by the EFI BIOS (Windows10 do not want to hear about ECC), and you get
> what Linus was complaining about: a machine-check exception with no way to know even the
> processor which triggered the ECC error or the address which caused the problem.
> That is what people call progress: a nice background image telling you how intelligent you
> are by having bought this top of the range brand of PC, during the whole Windows boot time.

Rubbish. The basic technique I described is applicable to traditional BIOS and (U)EFI PC boot ROMs, CoreBoot, u-Boot on ARM, or any other boot system. (The main difference being that it's almost certainly easier to communicate the required information across a less kludgey boot loader interface.)

The basic concept of a chain of boot loaders, each of which uses a limited subset of system resources (including RAM), followed by a "final OS" which tries to use everything, is pretty universal.

The point is that you have a safe-but-slow fallback of initializing all of RAM. Each stage in the boot loader chain verifies that the following stage can handle uninitialized ECC, or falls back if not. (One thing I forgot to include explicitly

Getting all the details right would involve a lot of grovelling through standards (the latest UEFI specification is 2557 pages!), but that's the textbook definition of a Small Matter of Programming: conceptually straightforward but hellishly laborious.