UEFI, it's an open standard
... understand it's not evil, just some of it's implementers are. The subject of UEFI carries a lot of FUD around it because of some nasty moves on Microsofts part in how it 'certifies' windows hardware, but not of that has to do with the Standards. That's just someone else policy on top of its mechanisms. https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-wo... This came up as an after meeting discussion from Chris Tyler's talk this month. Please read the article before making snap reply to this (I did it over a few bus rides, it's not short. But a heck of a lot short then the actual standards docs). -- Scott Sullivan
On 15 October 2015 at 08:00, Scott Sullivan <scott@ss.org> wrote:
Please read the article before making snap reply to this (I did it over a few bus rides, it's not short. But a heck of a lot short then the actual standards docs).
Scott, for those of us unable to commit the brain cells to the whole piece right now, thank you for the TL;DR version -- Evan Leibovitch Geneva, CH Em: evan at telly dot org Sk: evanleibovitch Tw: el56
On Thu, Oct 15, 2015 at 02:00:32AM -0400, Scott Sullivan wrote:
... understand it's not evil, just some of it's implementers are.
The subject of UEFI carries a lot of FUD around it because of some nasty moves on Microsofts part in how it 'certifies' windows hardware, but not of that has to do with the Standards. That's just someone else policy on top of its mechanisms.
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-wo...
This came up as an after meeting discussion from Chris Tyler's talk this month.
Please read the article before making snap reply to this (I did it over a few bus rides, it's not short. But a heck of a lot short then the actual standards docs).
Certainly the change from MBR partition table to GPT is a great change. Much much better partition table design. Running in 32 or 64bit sure beats the old BIOS code, and the services provided are much better than the old BIOS software interrupt calls. It isn't perfect (rom code being interpreted forth and hence architecture independant in openfirmware makes a lot of sense, but intel would hate anything that doesn't lock you into their architecture. It would be awful if your video rom could run on a non x86 machine after all). I do wonder actually why arm went with UEFI rather than openfirmware, although x86 users are at least starting to be familiar with UEFI so I guess it is less scary than openfirmware (although if Apple was able to use openfirmware, it can't be that scary for the user). Certainly the secureboot feature that UEFI can provide is not a bad one. The only bad thing is how Microsoft and some system vendors are choosing to use it. As long as the owner of the machine can choose the trust keys, it is a good feature. If you take that away, then it stops being a good feature, since you no longer own your hardware. -- Len Sorensen
On October 15, 2015 11:28:23 AM EDT, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
I do wonder actually why arm went with UEFI rather than openfirmware, although x86 users are at least starting to be familiar with UEFI so I guess it is less scary than openfirmware (although if Apple was able to use openfirmware, it can't be that scary for the user).
Do you mean 'ARM' the fab-less design company. ARM the 100+ licensees that design the SoCs. The 1000s of board design and manufactures. Or ARM the community of software devs and distributions. Because on thing Chris was trying to make clear is it is the last group that is organizing and leading the push to have the middle group adopt a common boot path. ARM the company doesn't really care here because they've sold the designs and can focus on the next one. -- Scott Sullivan
On Fri, Oct 16, 2015 at 12:44:02PM -0400, Scott Sullivan wrote:
Do you mean 'ARM' the fab-less design company. ARM the 100+ licensees that design the SoCs. The 1000s of board design and manufactures. Or ARM the community of software devs and distributions.
I mean whatever part of the community seems to have decided UEFI and ACPI was the way to go for 64bit arm servers. After all openfirmware has been around for years, is supported by linux, and already used by powerpc, mips, and a few x86 systems (and probably others too). Would have probably saved them a few years too by not having to first get UEFI and ACPI into a state where they could be used as standards. To some extent a lot of arm developers are also somewhat indirectly already used to openfirmware too, since devicetree is in fact based on openfirmware's way of telling the kernel about the system, which is why all the function calls for devicetree in the kernel are of_* calls. In fact using openfirmware would mean your drivers would work the same whether you boot from openfirmware or with u-boot with a devicetree dtb. No difference at all. UEFI means you have to be different from the embedded systems. Of course on servers they may simply be assuming everything is going to be PCIe based, and hence device detection is not an issue to worry about. So at least from my point of view, the arm server community probably fucked up and wasted a lot of time. But maybe there were reasons to not stick with something that was already done. Maybe they didn't like IEEE standards. :) The only thing I can see going for UEFI is that some people are getting used to it on x86 (although a lot of people clearly are not used to it at all yet).
Because on thing Chris was trying to make clear is it is the last group that is organizing and leading the push to have the middle group adopt a common boot path.
ARM the company doesn't really care here because they've sold the designs and can focus on the next one.
Oh certainly. -- Len Sorensen
participants (3)
-
Evan Leibovitch -
Lennart Sorensen -
Scott Sullivan