UEFI News and Commentary

Wednesday, May 24, 2006

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.

No comments: