Microsoft & UEFI

According to this report (http://www.vnunet.com/vnunet/news/2156867/microsoft-promises-bios) from WinHEC, Microsoft will begin supporting UEFI officially with the Vista SP1 and Longhorn Server. This is actually consistent with what they said at this year's Intel IDF. However, their previous statements were so careful that many people felt Microsoft was going to pull support entirely (see the other links on the site linked above). Since Microsoft is one of the board members of UEFI, that was pretty embarrassing :-( Microsoft previously stated that they weren't seeing any BIOS vendor support on real platforms for UEFI. It is kind of a chicken-and-egg problem, since if you don't support it in the OS, why would an OEM spend the money speculatively? And if the OEM doesn't build it, the OS won't test it. This is similar to the problems with SMBus battery support in ACPI. Its in the spec but nobody built systems, so the OS never officially supported it. Anyway, this positive comment from Microsoft, combined with Bill Gates mentioning it in his keynote address, should put they nay-sayers away. And if Microsoft decides to only support UEFI for X64 (EMT64/AMD64) on server, that would be great because it gets us away from the EFI32/EFI64 support nightmare (more later, short version is: can't build a BIOS with support for both at the same time) Tim

Insyde, AMD and UEFI

Insyde (as reported here: http://www.tmcnet.com/usubmit/2006/05/22/1658081.htm) put put out a press-release talking about their support of Framework support of AMD processors. They demo'd this at WinHEC running Vista. It wasn't clear whether they actually booted Vista using UEFI or using good ol' INT 19. This is important for Insyde, since they've primarily been living off of PEI/DXE drivers from Intel. Moving silicon support outside the Intel camp shows that their product isn't just tied to Intel. AGESA (mentioned in the article) has been AMD's standard way of delivering code to BIOS vendors in the past. The problem for AMD has been, how to integrate their code as quickly as possible into a new BIOS code base (either one of the BIOS vendors or one of the many customers who purchase source code or have their own BIOS). The answer, to this point, has been encapsulation (the 'E' in AGESA). So what Insyde did was create a PEI-style wrapper and some conventions to handle the call-outs from AMD's code. Seems like a good transition strategy, one which would be obviated if AMD would create their own PEI drivers. Right now, there is still some value for BIOS vendors to create their own code. Many of the silicon vendors haven't switched their own internal support structure to create PEI/DXE modules and at least one major code base (Award, produced by Phoenix) doesn't support PEI currently. If every BIOS code base were to support PEI/DXE, then there is no reason not to produce it in that format. The article contains some technical inaccuracies: I don't think Insyde was really running a UEFI solution in their booth (at least they haven't announced UEFI 2.0 support in the past). They are also playing loose with terminology: UEFI-based PEI and DXE drivers. The UEFI specification does not talk about PEI or DXE. The Platform Initialization Working Group inside of UEFI Incorporated is working on two specifications (PEI & DXE) which have not been released yet, are different in several ways (incompatible ways) from Intel's previous initiatives of the same name, and aren't necessary for the UEFI specification at all.