4 ms·

Is there potential for UEFI-based aarch64 systems? Or is the code too specific to x86?

MisterTea 4y ago
Already done. https://en.wikipedia.org/wiki/Windows_RT#History https://en.wikipedia.org/wiki/Windows_RT#History 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.
- xxpor 4y ago
  UEFI/APCI is still a huge UX improvement over a device tree based solution.
  - MisterTea 4y ago
    That is not saying much as anything is better than device trees. We can do better.
ajross 4y ago
UEFI is just a (somewhat/very clumsy) C API, there's nothing particularly x86-specific about it. Obviously some aspects like access to particular devices is going to be platform-dependent, but there's no reason it couldn't be used wherever. 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.
- yjftsjthsd-h 4y ago
  > but there's no reason it couldn't be used wherever. And in fact has been; aarch64 UEFI exists (ex. https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefiacpi-firmware-aims-to-make-the-board-sbbr-compliant/ 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.
  - ajross 4y ago
    You're doing the thing where you confuse the need for a feature with the need for a particular implementation of that feature. Again, UEFI is really awful. Look at ChromeOS.
    - yjftsjthsd-h 4y ago
      > You're doing the thing where you confuse the need for a feature with the need for a particular implementation of that feature. Again, UEFI is really awful. 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.
mjg59 4y ago
Assuming you mean "potential for memtest86+ on UEFI-based aarch64 systems" - memtest86+ takes over the entire system, rather than relying on firmware services. In that respect it's more like a kernel rather than an app, and so involves a lot of architecture-specific setup code - the UEFI port here is more about being able to jump into the memtest86+ "kernel" from the UEFI firmware than making it a generic UEFI application. It also needs guarantees around memory access that aren't provided by C, so there's assembly code to do that. And finally, a lot of the hardware interaction seems to assume a PC-type platform. I don't think there's anything impossible to port to aarch64 here, but it looks like a fair amount of work.
- sigjuice 4y ago
  Thanks! Yes, I meant "potential for memtest86+ ..."

Already done. https://en.wikipedia.org/wiki/Windows_RT#History https://en.wikipedia.org/wiki/Windows_RT#History 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.

xxpor 4y ago
UEFI/APCI is still a huge UX improvement over a device tree based solution.
- MisterTea 4y ago
  That is not saying much as anything is better than device trees. We can do better.

ajross 4y ago

UEFI is just a (somewhat/very clumsy) C API, there's nothing particularly x86-specific about it. Obviously some aspects like access to particular devices is going to be platform-dependent, but there's no reason it couldn't be used wherever. 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.

yjftsjthsd-h 4y ago
> but there's no reason it couldn't be used wherever. And in fact has been; aarch64 UEFI exists (ex. https://www.cnx-software.com/2020/02/18/raspberry-pi-4-uefiacpi-firmware-aims-to-make-the-board-sbbr-compliant/ 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.
- ajross 4y ago
  You're doing the thing where you confuse the need for a feature with the need for a particular implementation of that feature. Again, UEFI is really awful. Look at ChromeOS.
  - yjftsjthsd-h 4y ago
    > You're doing the thing where you confuse the need for a feature with the need for a particular implementation of that feature. Again, UEFI is really awful. 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.

mjg59 4y ago

Assuming you mean "potential for memtest86+ on UEFI-based aarch64 systems" - memtest86+ takes over the entire system, rather than relying on firmware services. In that respect it's more like a kernel rather than an app, and so involves a lot of architecture-specific setup code - the UEFI port here is more about being able to jump into the memtest86+ "kernel" from the UEFI firmware than making it a generic UEFI application. It also needs guarantees around memory access that aren't provided by C, so there's assembly code to do that. And finally, a lot of the hardware interaction seems to assume a PC-type platform. I don't think there's anything impossible to port to aarch64 here, but it looks like a fair amount of work.

sigjuice 4y ago
Thanks! Yes, I meant "potential for memtest86+ ..."