UEFI

From Omnia
Jump to navigation Jump to search

UEFI - Unified Extensible Firmware Interface

UEFI - http://www.uefi.org/home/

UEFI stands for "Unified Extensible Firmware Interface".

"The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is meant as a replacement for the Basic Input/Output System (BIOS) firmware interface, present in all IBM PC-compatible personal computers. In practice, most UEFI images have legacy support for BIOS services. It can be used to allow remote diagnostics and repair of computers, even without another operating system.

The original EFI (Extensible Firmware Interface) specification was developed by Intel. Some of its practices and data formats mirror ones from Windows. In 2005, UEFI deprecated EFI 1.10 (final release of EFI). The UEFI specification is managed by the Unified EFI Forum." (Unified Extensible Firmware Interface - Wikipedia - http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface)

UEFI Specification

UEFI - UEFI Specifications and Tools - http://www.uefi.org/specs

  • "The UEFI Specification Version 2.3.1 is now available"

UEFI - Download the Standard - http://www.uefi.org/specs/download

Mount EFI GPT Partition Table

How to mount a partition on a disk that has an EFI GPT partition table in Debian GNU/Linux 5.0.3 (Lenny) - http://www.pjc.me.uk/efi-gpt/index.html

Check the kernel was compiled with EFI support: 

# cat /boot/config-2.6.26-2-686 | grep EFI
CONFIG_EFI=y
CONFIG_FB_EFI=y
CONFIG_EFI_VARS=m
CONFIG_EFI_PARTITION=y

The fdisk command shows only a placeholder partition. This is normal. 

fdisk -l /dev/sda

List the real partitions on the disk using parted. 

parted /dev/sda print

To mount a partition, use the mount command in the same way you usually would. 

mount /dev/sda2 /mnt/test

efibootmgr

RHEL 6 efibootmgr

Sample listing: 

# efibootmgr
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0006,0007,0000,0002,0003,0004,0005,0001
Boot0000  PLDS DVD-ROM DS-8D3SH
Boot0001* CentOS
Boot0002* Broadcom NetXtreme Gigabit Ethernet (BCM5720)
Boot0003  Broadcom NetXtreme Gigabit Ethernet (BCM5720)
Boot0004  Broadcom NetXtreme Gigabit Ethernet (BCM5720)
Boot0005  Broadcom NetXtreme Gigabit Ethernet (BCM5720)
Boot0006* Red Hat Enterprise Linux
Boot0007* iomemory-vsl

Verbose listing: (wrapped text manually) 

# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0006,0007,0000,0002,0003,0004,0005,0001
Boot0000  PLDS DVD-ROM DS-8D3SH                         ACPI(a0841d0,0)PCI(1f,2)03120a00040000000000
Boot0001* CentOS                                        HD(1,100,c800,3d12ea1f-d9b0-42d2-8bd2-9e913a68bc89)File(\EFI\redhat\grub.efi)
Boot0002* Broadcom NetXtreme Gigabit Ethernet (BCM5720) ACPI(a0841d0,0)PCI(1,1)PCI(0,0)MAC(d4ae52af4a47,0)
Boot0003  Broadcom NetXtreme Gigabit Ethernet (BCM5720) ACPI(a0841d0,0)PCI(1,1)PCI(0,1)MAC(d4ae52af4a48,0)
Boot0004  Broadcom NetXtreme Gigabit Ethernet (BCM5720) ACPI(a0841d0,0)PCI(1,0)PCI(0,0)MAC(d4ae52af4a49,0)
Boot0005  Broadcom NetXtreme Gigabit Ethernet (BCM5720) ACPI(a0841d0,0)PCI(1,0)PCI(0,1)MAC(d4ae52af4a4a,0)
Boot0006* Red Hat Enterprise Linux                      HD(1,800,64000,bf97c896-3e48-4b7f-8d55-95319e4188ee)File(\EFI\redhat\grub.efi)
Boot0007* iomemory-vsl                                  ACPI(a0841d0,0)PCI(3,0)PCI(0,0)030a1400475e1f89883e294781fa05d869a1b070HD(1,100,c800,d9
                                                                  fd3d98-f517-44f5-9350-08d0cb720c68)File(\EFI\redhat\grub.efi)

Enable (Activate) boot entry: (marked with asterisk) 

efibootmgr --active --bootnum 7

Disable (Deactivate) boot entry: 

efibootmgr --inactive --bootnum 7

Create entry: (and sets to active and adds to top of boot order) 

efibootmgr --create --disk /dev/fioa
efibootmgr --create --disk /dev/fioa --label "Ken RHEL"

Set next boot: 

efibootmgr --bootnext 7
# adds "BootNext: 0005" to listing

Set timeout: (in seconds) 

efibootmgr --timeout 5
efibootmgr --delete-timeout

Boot order: (any not listed will be erased) 

efibootmgr --bootorder 3,4,1,6
efibootmgr --delete-bootorder

Delete entry: ([bootnum] is in hex, safer to disable boot items) 

efibootmgr --delete-bootnum --bootnum 7

WARNING: careful - any device that is deleted, but detected on next boot will be automatically added to the *top* of the boot order!

Options: 

efibootmgr version 0.5.4
usage: efibootmgr [options]
        -a | --active         sets bootnum active
        -A | --inactive       sets bootnum inactive
        -b | --bootnum XXXX   modify BootXXXX (hex)
        -B | --delete-bootnum delete bootnum (hex)
        -c | --create         create new variable bootnum and add to bootorder
        -d | --disk disk       (defaults to /dev/sda) containing loader
        -e | --edd [1|3|-1]   force EDD 1.0 or 3.0 creation variables, or guess
        -E | --device num      EDD 1.0 device number (defaults to 0x80)
        -g | --gpt            force disk with invalid PMBR to be treated as GPT
        -H | --acpi_hid XXXX  set the ACPI HID (used with -i)
        -i | --iface name     create a netboot entry for the named interface
        -l | --loader name     (defaults to \EFI\redhat\grub.efi)
        -L | --label label     Boot manager display label (defaults to "Linux")
        -n | --bootnext XXXX   set BootNext to XXXX (hex)
        -N | --delete-bootnext delete BootNext
        -o | --bootorder XXXX,YYYY,ZZZZ,...     explicitly set BootOrder (hex)
        -O | --delete-bootorder delete BootOrder
        -p | --part part        (defaults to 1) containing loader
        -q | --quiet            be quiet
           | --test filename    don't write to NVRAM, write to filename.
        -t | --timeout seconds  set boot manager timeout waiting for user input.
        -T | --delete-timeout   delete Timeout.
        -u | --unicode | --UCS-2  pass extra args as UCS-2 (default is ASCII)
        -U | --acpi_uid XXXX    set the ACPI UID (used with -i)
        -v | --verbose          print additional information
        -V | --version          return version and exit
        -w | --write-signature  write unique sig to MBR if needed
        -@ | --append-binary-args file  append extra args from file (use "-" for stdin)

PXE

elilo

uefielilo/elilo.efi

PXE Request Order: 

# For IP: 10.50.143.51 (0A328F33)
uefielilo/elilo.efi
uefielilo/0A328F33.conf
uefielilo/0A328F33.conf
uefielilo/0A328F-x86_64.conf
uefielilo/0A328F-x86_64.conf
uefielilo/0A328F.conf
uefielilo/0A328F.conf
uefielilo/0A32-x86_64.conf
uefielilo/0A32-x86_64.conf
uefielilo/0A32.conf
uefielilo/0A32.conf
uefielilo/0A-x86_64.conf
uefielilo/0A-x86_64.conf
uefielilo/0A.conf
uefielilo/0A.conf
uefielilo/elilo-x86_64.conf
uefielilo/elilo-x86_64.conf
uefielilo/elilo.conf

grub

uefigrub/grub.efi

PXE Request Order: 

# For IP: 10.50.143.124 (0A328F7C)
uefigrub/grub.efi
uefigrub/84BD617D-0011-D911-855A-14B1B9CF7700
uefigrub/01-00-02-C9-BA-07-24
uefigrub/0A328F7C
uefigrub/0A328F7
uefigrub/0A328F
uefigrub/0A328
uefigrub/0A32
uefigrub/0A3
uefigrub/0A
uefigrub/0
uefigrub/efidefault

Booting UEFI

EFI System partition (ESP)

Fat32 partition with boot loader here: 

\EFI\BOOT\BOOTX64.EFI

"For 64-bit UEFI implementations, the path to file that is booted is \EFI\BOOT\BOOTX64.EFI. UEFI boot loader searches all filesystems it can access for this file, and when it finds it, it is executed. As I already said, if the file isn't found, booting continues with legacy BIOS. UEFI boot loader can read MBR or GPT partition tables, and can only read FAT32 partitions. This includes USB drives, so it is possible to boot EFI shell from FAT32-formatted USB pen." [1]

UEFI Shell

See UEFI Shell

tianacore

tianacore (UEFI Reference Code) - http://sourceforge.net/apps/mediawiki/tianocore/

GPT Partition

See GPT

UEFI Application Development

UEFI Programming - First Steps - http://x86asm.net/articles/uefi-programming-first-steps/ 

#include <efi.h>

EFI_STATUS main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
  return EFI_SUCCESS;
}

Compiling it with MS Visual C (supply your own path to EFI toolkit): 

cl /c /Zl /I"{EFI_Toolkit}\include\efi" /I"{EFI_Toolkit}\include\efi\em64t" hello.c

Here we set path to common EFI headers, and to platform-specific EFI headers. The /c switch disables linking (we will link separately for better readability), and /Zl disables dependency on default libc libraries.

Linking: 

link /entry:main /dll /IGNORE:4086 hello.obj

Now we have windows DLL, we just need to change PE subsystem value to EFI. For that, EFI Toolkit contains simple (buggy) utility that changes subsystem to one of 3 EFI values. We find this utility in EFI_Toolkit\build\tools\bin\fwimage.exe. To set subsystem to EFI app, we'll use it like this: 

fwimage app hello.dll hello.efi

Produced file hello.efi should now be functional empty EFI application. We just need to copy it to our FAT32 partition, reboot to EFI shell, and test it: 

Shell> fs0:
fs0:> .\hello.efi

Criticism of UEFI

"Implementation provided for UEFI was Tiano, that is written in C, not Assembler, which is still standard for BIOS development. Disadvantage of C over Assembler is that produced code is considerably bigger, and so motherboards require more Flash RAM, and their production price increases. " [2]

EDK11

"The EFI Development Kit (EDK) contains the public part of the original reference EFI implementation developed by Intel. It includes source code, makefiles and binaries for the reference EFI Shell. Build tips (targets) include a Win32 (NT32) UEFI emulator and DUET (Developer’s UEFI Emulation) which create an emulated environment where you can test EFI applications and code without the need for an actual EFI-enabled Platform.

One of the major problems with the EDK is that the build environment is very much Microsoft Windows centric. This reflects the heritage of the EDK. EFI was initially developed for the IA64 (Merced/Itanium) platform and the EDK, running on 32-bit Windows NT X86, was used by engineers in a number of companies to develop the firmware utilities and boot managers for their initial Itanium offerings. I was one of those people who used the EDK back in the early 2000s.

In order to build the EDK out of the box, you need specific versions of Microsoft Visual Studio (VS2003 or VS2005) and a specific version of the Microsoft Assembler (MASM 6.15). I have built both 32-bit and 64-bit versions of DUET using Visual Studio 2010 by modifying some of the build scripts but there is no easy replacement for MASM 6.15. If you do not already have a copy, or cannot obtain a copy, you cannot build the EDK. The assembler included with Visual Studio is not sufficient.

Officially the EDK11 is the response to the UEFI community’s request for a better build and version tracking environment for UEFI and PI (Platform Initialization) development. From a developer’s perspective, the main difference between EDK and EDK11 is the enhanced build environment. Gone are the dependencies on Visual Studio and MASM. In its place is a much more logical partitioning of the source code into what is termed packages and a much more flexible build system. The end result is that the EDK11 build system is much easier to port to new platforms.

For a number of years the EDK was hosted by TianoCore on their own website. However in the last year the project was opened up and moved to SourceForge in the form of a main project and a number of subprojects. In November 2010 a snapshot of the EDK11 called UEFI Development Kit 2010 was released which contained a Unix package." (EDK11 UEFI Emulator on Fedora 14 « Musings - http://blog.fpmurphy.com/2011/01/edk2-uefi-emulator-on-fedora-14.html)

--- tianocore ---

SourceForge.net: tianocore - http://sourceforge.net/apps/mediawiki/tianocore

"This is the community site surrounding the open source components of Intel's implementation of UEFI. To learn how to use UEFI see our start using UEFI page. To learn more about getting involved in the community see our how to contribute page. EDK II is a modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications."

ArchLinux UEFI

Unified Extensible Firmware Interface - ArchWiki - https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface

UEFI SCT

Self Certification Test (SCT)

See UEFI SCT

RHEL 6.3

RHEL 6.3 UEFI Partition Layout: 

LVM Volume Groups
  VolGroup   15680 MB
    lv_root  11648 MB  /          esx4
    lv_swap   4032 MB             swap

Hard Drives
  sda - partition table (GPT)
    sda1       200 MB  /boot/efi  EFI System Partition
    sda2       500 MB  /boot      ext4
    sda3     15682 MB  VolGroup   physical volume (LVM)

Boot loader installed to /dev/sda1

Root: /dev/mapper/VolGroup-lv_root

Issues

RHEL6 - Trying to allocate 971 pages for VMLINUZ

Trying to allocate 971 pages for VMLINUZ
[Linux-EFI, setup=0x100d, size=0x3ca030]
   [Initrd, addr=0x7ddf4000, size=0x1d0850d]

"There is a grub issue here with Centos/RHEL6 and hence this is still being tracked for a solution.." [3]

"You are not authorized to access bug #670266."

References:

keywords

UEFI EFI

Retrieved from "https://aznot.com/index.php?title=UEFI&oldid=5180"