I have tried EFI booting with Ubuntu 12.04, and found an answer to my own question.
(I haven't upgraded my firmware. I misread the release notes originally - it probably wouldn't be any faster).
Entering firmware setup from the grub-efi boot menu
efibootmgr doesn't seem to support rebooting to firmware setup for me. But grub-efi does. It's able to create an entry for firmware setup in the GRUB boot menu.
You can enter the GRUB boot menu by holding down the shift key "early in the boot process". I press it down immediately after the NumLock light turned on on the keyboard, and that works for me.
If you're curious, I looked at the command as well: it's "fwsetup". I.e. you can enter the GRUB menu, follow the on-screen instructions to switch to the command line, then type "fwsetup" and hit return.
If you do an EFI install from scratch, I believe the menu item will be created automatically. I didn't install as EFI, which meant I had to kick it (see below, step 4).
Converting from BIOS-GPT boot to UEFI-GPT boot without burning an EFI boot CD?
EDIT: this section may work on some systems. However I now believe it relies on extra behaviour which is not part of the UEFI standard. Some day I'll figure out what's happening here.
I was converting an existing install to EFI, without an EFI-enabled boot CD. Some people think this isn't possible. Admittedly, there are a couple of confusing warning messages. I had a look at what was going on. If you can currently enter the firmware setup, then it's not all that bad.
The hard part is you're probably still using an MBR partition table, and you almost certainly need to convert it to GPT. I'm not going to cover conversion from MBR to GPT. Partitioning is always a bit dangerous.
gdisk can convert, but there are quite a few fiddly bits. I haven't listed them all here. But for one, you probably need to shrink the last partition, to make space for the end-of-disk GPT. You can't do that if the partition is mounted, so you'll want to use a boot CD. (I also staged the conversion, making sure I could boot from BIOS-GPT before I tried UEFI-GPT, which involved having to create yet another type of boot partition.).
Assuming you've got GPT set up:
- Install grub-efi. This removed grub-pc, and stopped it from working. (grub-efi actually still worked after I removed it!). Fedora seems a bit different; I've only tried this on Ubuntu. During the install, you will see errors about not being able to access EFI variables, which is because you didn't boot by EFI.
- Power on. Make sure you boot through EFI! This is the system-dependent and worrying part. My system happened to default to MBR boot to start with, so I saw a scary error from GRUB - but it was from the old grub-pc. On my system, it was easy to enter the firmware setup screen at this point (see below), and change the boot priority to "ubuntu" (which was the entry for booting my OS via EFI).
- Now you can redo the grub installation (
grub2-install on Fedora), and it won't show any errors. And now, running
grub2-mkconfig -o /boot/grub/grub.cfg, on Fedora) will create the menu item for entering firmware setup.
Entering the firmware setup/boot menu on my ASUS system
DISCLAIMER: this is not the very latest firmware/board. Your ASUS system may act differently from mine.
My current ASUS firmware notices when the "boot configuration" has changed - e.g. when I installed grub-efi. There's text saying that it's changed if you look at the initial "EZ setup" screen. And, when it detects such a change, it makes it easier to enter the setup screen. What it does is it shows the splash screen with "press DEL to enter setup" for a few seconds. (If you've enabled the "fast boot" option, it normally skips the splash screen).
I think it's also possible to trigger the splash screen by you powering off the system and unplugging it for a minute or so, before rebooting.
On my current firmware, I can enter the firmware setup by blitzing the DEL key during boot, even without the splash screen. However, this is conditional on enabling keyboard support in the firmware.
It's possible to switch the firmware not to probe for keyboards during boot, which is supposed to speed things up. I guess this is the next experiment to try, now I'm more confident about this EFI stuff! (It's plausible it could kill keyboard support in the GRUB boot menu as well. But I should still be able to use grub-set-default, so that GRUB boots the fwsetup entry, and recover that way).