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