Talk:UEFI/Archive 1

Archive 1

Archive 2

Untitled

I have significantly reworked the article to address most of the comments on this page. I've added several references to the article. The most significant one is to an Intel presentation describing why EFI is better than the traditional PC BIOS, and how it is designed as a replacement for it. I've worded the article to reflect how EFI was described in the presentation, and I've attributed this thinking to Intel.

I think it's pretty neutral. I certainly don't have a TC (or licensing or patent or...) axe to grind. If others agree, then maybe we can remove the NPOV tag...

I've also left the information regarding FAT issues on the talk page below. These are certainly an issue for providers of EFI systems and Open Source operating systems, but I don't think that an article describing EFI needs to get bogged down in a patent discussion: it's certainly not an issue particularly specific to EFI as compared to any other computer technology. You wouldn't include a huge patent debate in a digital camera article, even though they use FAT, too...

Tmassey 20:06, 12 January 2006 (UTC)

cleanup tag

This article wouldn't need its cleanup tag anymore if there were some headers. --Michiel Sikma 20:16, 17 January 2006 (UTC)

Recent edits

I noticed this page was being cleaned up at the same time I was attempting to do the same thing. I went with my version as I feel it is cleaner, more organized, and represents more significant content changes than the other version. I wish I could have it done sooner, so as to save the other person some work. If there are any significant and important changes in the other version that should be incorporated, please do so (I'm not that great at reading the diff pages—they're not very helpful sometimes)—Kbolino 22:12, 23 January 2006 (UTC)

What EFI really is

EFI is actually quite a few things. First of all is it not completely a bios replacement. It provides no means for performing the POST or setup. However it does act like a replacement bios in the sense of providing a low level continuously available system for interfacing with the hardware.

It is interesting that Intel's sample implementation has one form in which it uses to bios to implement its features. There is a second form that can be loaded by the bios'es initial program loader, that once loaded ignores the bios completely. (And basically forces the bios out of memory to provide its own services.)

The normal implementation of EFI has a bios-like chip that runs the POST and then does loads EFI, usually from a flash or NVRAM chip, but it could be from the harddrive also.

The advantage of a flash chip is that EFI applications providing recovery or diagonstic utilities could be placed on the chip, and used even when the hard drive is not working.

Back to what EFI is: Besides the bios replacement that uses drivers loaded in memory, allowing more flexibility tha the IBM bios, EFI is also a pre-boot Micro-OS. It runs EFI applications, which include boot loaders, diagnostic utilities or the EFI shell.

Really it is quite interesting. It would be nice if this page better reflected what EFI really is. 17:40, 5 July 2006 (UTC)

article gone

I couldn't see the article. I got the page for a non-existent article. I hope this is a temporary problem. --MarSch 09:37, 17 September 2006 (UTC)

Intel 945 chipsets and EFI

Intel currently offers PC motherboards supporting EFI. All boards that use the Intel 945 chipset series support EFI. However, no vendor has yet taken advantage of this. A firmware update could enable EFI on these motherboards, but no such update has yet been released, most likely because there is no EFI-capable 32-bit version of Microsoft Windows.

This sounds:

• unlikely, probably a rumor
• nearly everything I can find about this sounds like it came straight from this article
• this is ambiguous regarding whether it's talking about boards with the 945 series chipsets (my ABIT 945P-based mobo has a plain old Award BIOS - no EFI there) or mobos sold under the Intel name with a 945 chipset

-memodude 07:17, 26 November 2006 (UTC) oops...just made an idiot out of myself - did a little more research and the Intel brand 945 series mobos really do have EFI support. -memodude 07:28, 26 November 2006 (UTC)

The EFI Shell paragraph

This section contains this sentence: The shell can be viewed as a functional replacement for MS-DOS.

I comment on it because to me, first it's wrong, then it supposes that MS-DOS was present on all BIOS based machines. It's wrong because EFI can't be a replacement for an OS, minimal, simplistic as can be DOS, EFI does not have the same function, for example, in MS-DOS, as in other OS you can launch a program that targets it, etc... So no, EFI Shell is not a functional replacement for MS-DOS Second, I said it assumes that prior to EFI all BIOS machines must have had MS-DOS installed since it is a replacement, and everyone having even little knowledge of computing knows that it's wrong, Linux does not boot with DOS, nor does Windows NT (since the first one, NT 3.xx), nor FreeBSD, so let's not keep on making people think that MS-DOS, Windows, etc, etc has always been around.

I suggest that this sentence is removed, there's no comparison possible with MS-DOS or any other systems.

83.113.193.227 09:29, 11 January 2007 (UTC)

I clarified the paragraph a bit. Just like you don't need DOS today to boot Windows or Linux, you do not need the EFI shell either. The shell allows you to do the kind of things DOS does today; the most interesting ones are device-level tests (particularly for manufacturing environments) and device-level init (i.e. RAID set creation or modification). --Gribeco 19:25, 11 January 2007 (UTC)

Apple and EFI

"In 2006, Apple shipped their first Intel-based Macintosh computers with EFI, replacing Open Firmware on their iMac and MacBook Pro models."

This is unclear as to whether it implies that Apple shipped their first computer with EFI or not. (I'm not sure of this myself, but I'm pretty sure this is the case.) Rewording it might be better: "In 2006, Apple shipped their first Macintosh computers with EFI, replacing Open Firmware on their new Intel-based iMac and MacBook Pro models." That seems a bit clearer to me. Paul^C/_T+ 19:51, 13 January 2006 (UTC)

I agree: this was not clear. The new IntelMac's are EFI based. However, there have never been OpenFirmware Intel Mac's: the developer computers were BIOS-based, not OF. I've changed the text to read: "In 2006, Apple Computer shipped their first Intel-based Macintosh computers with EFI instead of OpenFirmware, which had been used on their previous PowerPC-based systems.[3]" Thoughts?

Tmassey 20:42, 13 January 2006 (UTC)

Under the heading "Platforms that use EFI or the Framework" it is stated "Using Boot Camp, which includes a compatibility support module, these systems are also able to boot Windows XP."

This is flat out wrong. Boot Camp is an application which 1. is a partition wizard and 2. burns a drivers CD. Windows can install, boot, and run on any Intel based Mac whether Boot Camp is used or not.

It makes things (a lot) easier for end users but is no way a technical requirement what-so-ever. Everything Boot Camp does is either already provided with OS X or can be replaced with a simple download.

Some of the EARLY Intel based Macs had some technical glitches booting Windows due to Apples implementation of EFI did NOT emulate BIOS. Apple released a "Firmware update" that fixed this at the same time they released Boot Camp (Beta) for public download. This has caused tons of confusion to non-technical Mac users.

"Boot Camp" is one the single most misused terms in the Mac Universe on message boards everywhere, and the above mentioned statement certainly does not help.

I clarified the wording. Obviously, a CSM is needed to boot Windows. The shrink-wrapped iMac with older firmware does not include a CSM, and is therefore not able to boot Windows on its own. Because the E in EFI stands for Extensible, the CSM can be loaded from an external device, such as a file system on a disk. --Gribeco 15:24, 29 March 2007 (UTC)

Merge

What is the goal of the merge? It seems like a bad idea to me, but I have little background as I see no item supporting it. Jabencarsey 20:33, 16 April 2007 (UTC)

I'm not keen on a merge either, since the UEFI Forum owns other specifications besides EFI (including the Platform Initialization Specification), and PI definitely warrants another article (the lack of publicly available sources is an impediment at this point). --Gribeco 21:41, 20 April 2007 (UTC)

Neutrality Issue

Am I just blowing smoke here or does anyone else find it biased that under the Apple section, their largest competitor - by a large margin - is the only one listed as being "Legacy"? Or for that matter, the use of "Legacy" in general? Afterall, there's a lot of debate as to whether or not EFI even confers any major benefits. Even referring to BIOS as "Legacy" this early on in EFI's early, - still - mostly experimental, and widely unsupported days is more than just a tiny bit biased. Now, I might agree that AGP is legacy hardware, or that the versions of Windows that ran off of MSDOS such as Windows95 and 98 are legacy operating systems. They're hardly in use anymore. Windows 2000 sure, that's legacy. Referring to BIOS as "legacy" in the entire article this early on, and while I may not be a fan of Windows (not going to push my system of choice because I don't want to revive a 25 year old flame war, yes, it's that outdated) but referring to Windows by name as "Legacy" in the Apple section just reeks of bias to me. 24.252.142.184 (talk) 08:25, 10 February 2009 (UTC)

"Legacy" in this context refers to an architecture with a large installed base, to which no enhancements have been proposed for a while. All current (and future) industry-standard firmware enhancements are EFI-centric. --gribeco (talk) 15:28, 10 February 2009 (UTC)

HP 8000 series printer w/ EFI

"In 2007 HP released the series multifunction printers with EFI compliant firmware.[12]"

You've got to be kidding me. A printer? With EFI? What for!? To run Linux, right? I'm looking forward to when my microwave has EFI and Linux...

Actually, I looked at the cited page, and I didn't find that. I looked on Google. I didn't find an Extensible Firmware Interface (EFI) printer. Can someone find some evidence that there are EFI-running printers, manufactured by HP? The datasheet/specsheets/overview mention nothing of this.

jdstroy (talk) 06:54, 10 December 2008 (UTC)

OK, I think I've found this "EFI" on printers thing: EFI PrintMe. There's a company called EFI that makes printer software, but it's unrelated to the Extensible Firmware Interface. I'm going to remove the line in the article until we can get something solid for Extensible Firmware Interface being in a printer. Feel free to revert or put it back in if you've got something good. Here's the relevant line:

In 2007 HP released the 8000 series multifunction printers with EFI compliant firmware.

jdstroy (talk) 22:32, 27 April 2009 (UTC)

Figure in "Contents" section

I see 2 problems with this figure: (1) (Minor) I think it needs more arrows, to clarify flow of control; and (2) (Major) It isn't referenced, explained, or discussed anywhere in the accompanying text. I find it confusing. "Boot manager" is merely mentioned in passing in a single sentence without explaining what it is, and "EFI binaries," "Value add implementation" (should this be "added"?), and "API-specified" aren't defined at all. Even the caption ("Interaction between the EFI boot manager and EFI drivers") is confusing because there are 3 other blue blocks, in addition to the one labeled "Driver" (and note the singular vs. plural discrepancy).Therealdp (talk) 13:12, 6 July 2009 (UTC)

Comparison to OpenFirmware?

Most non-Intel systems use OpenFirmware, I'd like to see a point-by-point pros & cons comparison of UEFI to OF (and specifically, to the common OF extensions found on powerpc, sparc) linas (talk) 18:02, 9 June 2010 (UTC)

"the older BIOS firmware interface present in all IBM PC-compatible personal computers."

Is this still true? The source cited is ten years old, and it seems to be contradicted by this:

"Some PC and laptop makers are already using UEFI as are many firms that make embedded computers. More...will result as motherboard makers complete the shift to using it."

http://www.bbc.co.uk/news/technology-11430069 .87.231.185.251 (talk) 06:19, 4 October 2010 (UTC)

Mouseover text to EBC stating that EBC means "EFI BYTE CODE".

Somebody plz add that. Thanks —Preceding unsigned comment added by 93.220.32.197 (talk) 20:24, 2 November 2010 (UTC)

Platforms that use UEFI or the Framework

This section needs either an explanation of or a link to an explanation of "the Framework." Apparently, it's equivalent with something called "InsydeH2O," but the article about its creator (Insyde Software), for which a link is given, provides no info about it

Also, "EDK" is undefined. Therealdp (talk) 12:53, 6 July 2009 (UTC)

Here is the word for word explanation from AMI's whitepaper on Aptio 4 "Aptio®: The Complete UEFI Product Solution"

The Intel Platform Innovation Framework for UEFI (also known as "the Framework") is a set of specifications developed by Intel to describe a product-strength firmware implementation based on EFI. While UEFI specifies the OS-to-firmware interface, the Framework specifies the structure used to build the firmware beneath the OS-to-firmware interface. Aptio 4.x is based on the Framework, allowing firmware components to leverage a documented set of architectural protocols. This structure allows Aptio to incorporate code from Intel‟s “Tiano” implementation of the Framework, and also leverage the open source EFI Development Kit (EDK) distributed at tianocore.org. Rrostie (talk) 00:22, 9 January 2011 (UTC)

EFI vs UEFI and 3TB Hard Drives

I noticed it says "this article is within the scope of WikiProject Apple Inc" at the top of this page. What does any of this have to do with apple? Maybe it did when EFI was new, and Apple was the only company to use it outside of servers. There is also something at the top of the page that talks about splitting UEFI away from EFI, yet I see no discussion about this anywhere. It looks to me like a whole new article about UEFI needs to be written from scratch. I have already started on some of it, I have been collecting the basic facts and sources on my own MediaWiki site at http://www.rostie.net/wiki/Above_2TB which is specifically about the new 3 TB hard drives that require UEFI to create a bootable partition in Windows 2.2TB or bigger. I am still confused about whether or not any current motherboards meet the requirements for a 2.2TB boot partition. I have found that there are 3 vendors that make a UEFI bios, but I haven't seen that anyone uses it in consumer hardware yet. Rrostie (talk) 00:47, 9 January 2011 (UTC)

32-bit Windows and booting from UEFI

"Microsoft does not offer support for 32-bit UEFI"

Isn't windows 8 going to have 32-bit UFI support? If so it should be mentioned. — Preceding unsigned comment added by 58.178.195.203 (talk) 11:16, 8 July 2011 (UTC)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2581408 — Preceding unsigned comment added by 115.248.50.21 (talk) 06:44, 29 September 2011 (UTC)

Criticism

This page needs a criticism section.

For example the comments by Linus: http://kerneltrap.org/node/6884 —Preceding unsigned comment added by 213.114.213.236 (talk) 02:33, 17 January 2008 (UTC)

There, I added a section.

I am not sure what to make of Ronald G Minnichs DRM-enabler suggestion, perhaps EFI just makes System Management Mode coding easier? Leaving it out for now anyway.

--82.182.37.3 (talk) 22:22, 20 January 2008 (UTC)

I don't think Ronald G's statement that EFI 'disables' fully opensource BIOSes like coreboot is at all accurate. If I understand correctly, EFI in implementation is really a standardized version of the existing module systems used by most consumer BIOSes, and if the coreboot wiki is correct, there have been somewhat successful efforts to port the Tianocore EFI environment to coreboot, proving that it is possible to have a pure FOSS EFI implementation. As for a 'DRM-enabled BIOS', an EFI implementation doesn't suddenly enable this to happen, the BIOS has always been able to mess with stuff. The Operating System assumes that when it starts executing, it gets full control over the hardware, no matter how it was bootstrapped; it's already been demonstrated that this is exploitable thanks to the Blue Pill rootkit. The more I think about it, the less it makes sense that this would come from someone who actually wrote the type of low-level code required of a BIOS implementation. Can we confirm this interview came from him? If so, anyone got a sourceable counter-argument to Ronald's claim that can be used in the article? --121.223.25.191 (talk) 11:15, 11 July 2008 (UTC)

Using UEFI does not enhances system performance or boot times; it is only an additional layer between the BIOS and the hardware. In most cases UEFI is slower when comparing boot times to legacy BIOS settings if the standard is properly implemented. This is because the regular BIOS need to hand off control to UEFI for boot. The only advantages from a proper implementation come when working with large hard drives by adding an additional abstraction layer. On poor improper implementations to the UEFI when this hand off does not happen each time you can see boot times significantly reduced, however this comes at a staggering price of system stability. This is expected because at this time UEFI is still considered experimental. The reason some systems see improved boot times from UEFI is because UEFI remembers at what the last setup was and guesses things have not changed, this is the basically the purpose of BIOS: add stability by checking the hardware is present and working. Source: https://help.ubuntu.com/community/UEFIBooting

Using UEFI comes again comes at the cost of security as well since hardware encryption keys can be intercepted when passing through UEFI to the operating system. Window's developers make a fatal flaw in that they assume UEFI is secure, but I have not seen any documentation on how or why it is more secure than direct interaction with the BIOS. UEFI itself can be compromised and therefore would allow the OS security to be compromised. Source: http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

Further more, this is just a hardware fix that Intel (a major supporter of the program) has created to deal with issues of their other hardware; "Interest in EFI has been growing steadily, and the Promoter companies believe that broad adoption requires industry management and control." -- from http://www.uefi.org/about/ — Preceding unsigned comment added by 67.112.74.4 (talk) 23:11, 7 December 2011 (UTC)

Microsoft

We should probably mention how Microsoft wishes to lock out other operating systems — Preceding unsigned comment added by 86.161.42.4 (talk) 17:24, 14 January 2012 (UTC)

Comment moved from article

"Seriously this article says that UEFI is architecture independant, and then in the next paragraph says its limited to little-endian machines, this is 100% contractictory, sure the operating system part of it (and not the important hardware side which is propritary) is written in C so can be recompiled for other little endian 32 bit machines, WOOP DE DOO!" I have moved the above comment from the top of the article.--Racklever (talk) 08:10, 11 April 2012 (UTC)

Secure boot

The article contains a criticism section about secure boot, yet it does not contain a section actually explaining it. I think this is a significant subject, and including that details on the controversy without mentioning the feature itself could be POV pushing. ViperSnake151  Talk  16:20, 9 September 2012 (UTC)

Is it possible to dual boot two OS' in different partitions of a GPT disk on a UEFI, i.e. such as Ubuntu and Win7? If so, shouldn't this be mentioned in terms of the limitations or restrictions the UEFI scheme holds? — Preceding unsigned comment added by 85.72.108.171 (talk) 03:15, 8 October 2012 (UTC)

Move mention of Microsoft OS from "Disk device compatibility"

Under "Disk device compatibility" section, there is mentioning which Microsoft operating systems support GPT. This needs to be moved to "OS compatibility", UEFI has nothing in common with Windows. 93.129.26.164 (talk) 16:17, 16 October 2012 (UTC)

Secure Boot incident

Would this be a RS for the first incident that already compromised Secure Boot ? 80.132.72.239 (talk) 18:13, 7 December 2012 (UTC)

These revoked certificates have not been used to sign UEFI payloads. --gribeco (talk) 18:20, 7 December 2012 (UTC)

But they could have been. But you are right this would be OR. 80.132.72.239 (talk) 18:29, 7 December 2012 (UTC)

Pictures are bad; they lack sequencing and logic

The pictures

"Extensible Firmware Interface's position in the software stack" and "Interaction between the EFI boot manager and EFI drivers" are lacking logic.

It is not clear what happens first, what follows from what and what influences what.

For example, the box "Hardware" in the first picture seems unrelated to other objects in the picture. Why it lies there, at all?

Another example: in the second picture, it is not clear where the process begins and whether there are a few parallel processes running or all occurs one after another. Maybe use numbers to make reading the picture easier. Is the time going from bottom to top? This sounds unusual, please reverse. — Preceding unsigned comment added by 2607:F470:14:2:A109:F90F:EF46:E45F (talk) 23:23, 14 February 2013 (UTC)

Practical UEFI

Most people reading this article want to know this: What do I need to know about UEFI? This would lead to questions like this: Where is UEFI on the hard drive? Exactly how does it boot different operating systems? Does it take care of the boot sequence? How do you boot removable media with UEFI? The summary stops short of briefly and clearly answering these practical questions. The rest of the article is written at a level of detail only pedants, enthusiasts, and UEFI developers could possibly appreciate. The practical information may still be in there. It's just sparsely distributed and difficult to find. See https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface for comparison.

If this is how the article is supposed to look, then just ignore this, but in that case, I do have one more question: Who decided how it should look?

Etoombs (talk) 18:22, 24 May 2013 (UTC)

Yeah, (U)EFI has remained as a technical spec for some years, only recently has it got wider practical adoption. That may explain why the article looks over technical. I guess it can use a section to explain the boot process like what BIOS does. Actually nobody really decides anything here. It just looks like how it is left to be. Iconv (talk) 15:15, 31 May 2013 (UTC)

ArchWiki references

ArchWiki is a publicly editable wiki, so using references from there is discouraged by WP:USERGENERATED. However, I'd suggest we keep them for now, until other verifiable sources are found. They're still quite valuable. Thoughts? -- Dsimic (talk) 14:28, 25 September 2013 (UTC)

The part about Linux kernel configuration should be easily citable directly from the kernel documentation files, I think. This is purely technical information, which I think is quite safe to source from a first-party source. Though we have to keep WP:NOTMANUAL in mind. A source which is technically WP:SELFPUB (and definitely should not be used alone, for WP:NPOV reasons, among others), but I would be willing to defend as reliable would be Matthew Garrett's blog. Keφr 14:53, 25 September 2013 (UTC)

Totally agreed on the Linux kernel configuration, will replace that reference in the next hour or so. -- Dsimic (talk) 15:04, 25 September 2013 (UTC)

Done... One less to go. :) -- Dsimic (talk) 15:57, 25 September 2013 (UTC)

ESP on MBR disks

Although UEFI specification mentions that ESP can reside on MBR disks, the practice says it's pretty much unsupported, meaning that only GPT disks are allowed to contain an ESP. Anyway, why would anybody want an MBR disk to hold an ESP? Additionally, some UEFI implementations are immediately switching into the CSM when MBR boot disk is found, effectively preventing UEFI-style booting. Thoughts? -- Dsimic (talk) 17:47, 14 November 2013 (UTC)

Actually, we're here to provide hard facts without too much discussion about them, and we have it all covered in this article — both UEFI specs, and practical experiences. -- Dsimic (talk) 02:45, 15 November 2013 (UTC)

Hello. I'm writing from my desktop booted from ESP on MBR. I think the bug you mentioned is an exception in some implementations. The norm should be supported. Iconv (talk) 23:01, 10 December 2013 (UTC)

Hello there! You're right, and the article has been rectified in the meantime to reflect that, please see the UEFI booting section; a quote from there:

"Supported partition table schemes include MBR and GPT, as well as El Torito volumes on optical disks."

That's according to the actual UEFI specs, and it makes us covered. Any different behavior is pretty much a plain bug, in a false attempt to provide additional "convenience" or whatever. — Dsimic (talk) 23:24, 10 December 2013 (UTC)

Pronunciation

Could someone produce an audio file pronuncing UEFI or provide an IPA (International Phonetic Alphabet) transliteration of its pronunciation? Sofia Koutsouveli (talk) 18:40, 20 March 2014 (UTC)

Hm, would that improve the clarity? Currently, there's the "pronounce it like 'unify' without the n" description, what should be good enough – if you agree. — Dsimic (talk | contribs) 03:59, 22 March 2014 (UTC)