Talk:UEFI

BROKEN: Creating disk images, linux, root not required

I followed the instructions to create a disk image without root, and discovered that the mcopy commands are broken. mcopy (at least on Ubuntu 16.04.1) doesn't have a -i option. I also checked and mformat doesn't have a -i option, so I'm not sure why that step didn't fail. I have no idea how to fix this, so I'm leaving a comment here. Sdp 10:38, 23 December 2016 (CST)

I figured it out. -i wasn't the issue, that's a common option on all mtools (though, I would say it's very poorly documented). The issue was that mcopy requires a destination that the instructions omitted. The correct form to copy main.efi to the disk is: "mcopy -i temp.img main.efi ::", in which the :: is the destination and indicates that the file should be copied to the disk image temp.img. Sdp 10:58, 23 December 2016 (CST)

For QEMU in particular, some mention of the "-hda fat:rw:dirname" option seems worthwhile. It saves a *ton* of trouble when debugging/testing. --Johnwilson 00:16, 5 December 2017 (CST)

Rewriting some content

All the GDB debugging stuff for UEFI/OVMF/QEMU has been moved to its own page: Debugging UEFI applications with GDB. It was too bulky and specific to include here. Intx13 09:20, 24 November 2015 (CST)

I'm starting to remove the older content, particularly the irrelevant stuff about there being no multibooting menus and the "biased mode" section. The useful content from those sections that wasn't already incorporated elsewhere has been included. Intx13 08:52, 20 November 2015 (CST)

I'm rewriting some content in this article, hopefully clarifying the example and providing more detail for new UEFI developers. Expect there to be some redundancy as I work on it over the next few days. -Intx13 15:03, 10 November 2015 (CST)

I saw a lot of instances of "UEFI BIOS" usage. But is it technically correct? I have read that that specific usage is confusing. I believe most of them can simply be replaced with "UEFI system" (especially "UEFI BIOSs" with "UEFI systems"). You won't find such usage in either Arch wiki or Wikipedia (as of now -- used to be there). Critiqjo 02:18, 15 November 2015 (CST)

I think it's technically correct ("the best kind of correct") in the sense that it refers to a BIOS ROM that adheres to the UEFI specification for platform initialization and application loading. "UEFI system" makes sense in the context of the UEFI specification, where the BIOS is the system being specified, but here, it would sound like that refers to a UEFI-compatible PC. How about "UEFI firmware"? Then we could draw a distinction between "legacy firmware" and "UEFI firmware", both of which are BIOS loaded from ROMs. The term "firmware" isn't used too much on PCs though. Intx13 12:11, 19 November 2015 (CST)

I went ahead and changed references to "UEFI BIOS" to "UEFI firmware" where it was appropriate. I left "legacy BIOS" alone. That way, "BIOS" only appears in legacy contexts, and "UEFI" is not interchanged with "BIOS" (although it would be correct to do so!) Feedback is appreciated! Intx13 12:45, 19 November 2015 (CST)

Wow! I just read the updates from that time and it looks great! The updated Secure Boot section was especially interesting to me (I'm not a bare-metal dev). Sorry I didn't reply earlier -- my context got switched at the time! --Critiqjo 14:19, 30 July 2016 (CDT)

GPT

I'm thinking that GPT should probably be a completely separate page.. Brendan 15:12, 29 July 2011 (UTC)

Agreed. But first, we need some content for it :) --Love4boobies 13:49, 1 August 2011 (UTC)

GCC Cross-Compiler Target

> The result of this process is a 44 kB PE executable file main.efi. On a real project you'll probably want to use make or another build tool, and may need to build a cross-compiler.

Ok, but it should say what is the target for a GCC cross-compiler, since they use GCC above... Glauxosdever 03:39, 10 July 2016 (CDT)

Also, binutils no longer seems to target efi-app targets, in GNUEFI they use objcopy from elf to binary and it says in the documentation they create the header manually in assembler. If anyone knows the steps for this, it would make a great addition here. --Kieran 02:10, 3 August 2016 (CDT)

Best bet for now is probably to use x86_64-w64-mingw32-gcc as per UEFI Bare Bones until something more appropriate is added to gcc John 04:08, 3 August 2016 (CDT)

GCC 8.3.0 ( From the Ubuntu repos ) seems to include the efi-app-x86_64 target, even if it's not included in the list of targets printed out using objcopy --info. That might be a bug with binutils. --Ajxs 17:41, 13 August 2019 (CDT)

32- vs. 64-bit

My own early experiments seem to suggest that UEFI itself (on Intel I mean) is either 32-bit or 64-bit (and even a 64-bit-capable CPU may have 32-bit UEFI in ROM, on older systems anyway), and the 64-bit version does *not* contain backward-compatibility with 32-bit UEFI programs. Is this correct? If so it's kind of a huge deal (every 32-bit OS needs to have both 32- and 64-bit versions of the loader) and it seems as if it deserves being mentioned loudly here. Also I believe the default 32-bit loader is named \EFI\BOOT\BOOTIA32.EFI, not \EFI\BOOT\BOOT.EFI . That's what the spec and my tests with 32-bit OVMF show, anyway. --Johnwilson 00:14, 5 December 2017 (CST)

This I believe is correct. Hence, if you want a 64 bit OS, but have a 32 bit UEFI, you still need to set up long mode yourself. I'm not sure if compatibility mode would work with the runtime services - boot services are clearly out as UEFI still has control of the paging structures. --Bellezzasolo 06:00, 5 December 2017 (CST)

While technically correct; it's less troublesome than you might assume. Microsoft have stated that they will never support 32-bit UEFI on 80x86 (and as far as I know they haven't), so the number of 80x86 computers with 32-bit UEFI is "almost zero" (mostly limited to a few old Apple machines, which are relatively quirky for other reasons). Also (potentially excluding old Apple machines) it's extremely likely that any computer with 32-bit UEFI (if any actually exist?) also supports BIOS and is already configured to boot using BIOS by the end user and/or manufacturer. Essentially; you can ignore 32-bit UEFI (and only support BIOS and 64-bit UEFI). --Brendan 11:22, 6 December 2017 (CST)

Excellent logic -- thank you! --Johnwilson 00:46, 8 December 2017 (CST)

Arm UEFI calling convention

The page currently shows:

> Calling Conventions

> UEFI specifies the following calling conventions:

> [...]

> SMC for ARM UEFI functions

I don't think that's correct, can you provide any reference for this?

From my understanding, the OS kernel and UEFI run on the same EL. When UEFI hands over control to the OS kernel it hands over a pointer to the EFI_SYSTEM_TABLE, which includes pointers to functions the OS kernel can call. These functions are then called by simply jumping to the given address, not by executing an SMC.

Looking at how the Linux kernel interacts with UEFI on Arm, I cannot see any SMCs being used to call UEFI functionality.

SMCs are usually used by UEFI to forward the request from the OS kernel to the trusted world, e.g. for variable storage or firmware updates, but I don't think that's relevant when describing the UEFI calling convention.