UEFI App Bare Bones: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
No edit summary
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(29 intermediate revisions by 11 users not shown)
Line 1: Line 1:
{{BeginnersWarning}}
{{BeginnersWarning}}
{{FirstPerson}}
{{Rating|2}}
{{Rating|2}}


In this tutorial we will create a hard drive or ISO image containing a bare bones UEFI application for the x86-64 platform.
In this tutorial, developers will create a hard drive or ISO image containing a bare bones UEFI application for the x86-64 platform.


You are recommended to have read and fully understood the [[Bare Bones]] tutorial first. The [[UEFI]] page provides some background to the UEFI boot process and should also be consulted first.
It is recommended to have read and fully understood the [[Bare Bones]] tutorial first. The [[UEFI]] page provides some background to the UEFI boot process and should also be consulted first.


This tutorial uses the header files and GUID definitions from the [https://sourceforge.net/projects/gnu-efi/ gnu-efi] project, but does '''not''' use the gnu-efi build system, but rather the MinGW-w64 or LLVM/Clang toolchain.
This tutorial uses the header files and GUID definitions from the [[GNU-EFI]] project, but does '''not''' use the gnu-efi build system, but rather the MinGW-w64 or LLVM/Clang toolchain.


== Prerequisites ==
== Prerequisites ==


You will need a [[GCC Cross-Compiler]] targeting the '''x86_64-w64-mingw32''' target (for PE output), and the [https://sourceforge.net/projects/gnu-efi/ '''gnu-efi'''] package to compile the actual kernel. If you already have a copy of LLVM/clang, it will too work as a cross-compiler. To build the EFI filesystem image we use [[MTools]] and optionally [https://github.com/jncronin/mkgpt '''mkgpt'''] if you also want to create a hard disk image. To run under an emulator, we use '''qemu-system-x86_64''' and the [http://tianocore.sourceforge.net/wiki/OVMF '''x64 OVMF firmware''']. If you wish to build a CD image, you will also need '''xorriso''' (in [[mkisofs]] emulation mode).
Developers will need a [[GCC Cross-Compiler]] or Clang targeting the '''x86_64-w64-mingw32''' target (for [[PE]] output), and the [https://sourceforge.net/projects/gnu-efi/ '''gnu-efi'''] package (for UEFI headers). Most Linux distros provide cross-compilers for this target, so it's usually not necessary to build it yourself. This example does not link against [[GNU-EFI]] or follow its build process; only the headers are used.


To build the EFI filesystem image, developers can use [[MTools]] or [https://github.com/jncronin/mkgpt '''mkgpt'''] to create a hard disk image. To build a CD image, '''xorriso''' (in [[mkisofs]] emulation mode) will be needed. To run under an emulator, it is best to use '''qemu-system-x86_64''' coupled with the [http://tianocore.sourceforge.net/wiki/OVMF '''x64 OVMF firmware'''].
Under an apt-based system (e.g. Debian/Ubuntu) you can run <source lang="bash">sudo apt-get install qemu binutils-mingw-w64 gcc-mingw-w64 xorriso mtools

wget http://www.tysos.org/files/efi/mkgpt-latest.tar.bz2
Under an apt-based system (e.g. Debian/Ubuntu), developers can run: <syntaxhighlight lang="bash">sudo apt-get install qemu ovmf gnu-efi binutils-mingw-w64 gcc-mingw-w64 xorriso mtools</syntaxhighlight>
tar jxf mkgpt-latest.tar.bz2

cd mkgpt && ./configure && make && sudo make install && cd ..</source> and then separately download OVMF and extract the OVMF.fd file somewhere, and also gnu-efi.
To install mkgpt you can run these commands:<syntaxhighlight lang="bash">git clone https://github.com/jncronin/mkgpt.git
cd mkgpt
automake --add-missing
autoreconf
./configure
make
sudo make install</syntaxhighlight>


== Testing the emulator ==
== Testing the emulator ==
Line 22: Line 28:
Now is a good time to check the emulator is working successfully with the OVMF firmware.
Now is a good time to check the emulator is working successfully with the OVMF firmware.


<source lang="bash">qemu-system-x86_64 -L OVMF_dir/ -bios OVMF.fd</source>should launch qemu and dump you at a UEFI shell prompt.
<syntaxhighlight lang="bash">qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd</syntaxhighlight>should launch qemu and launch a UEFI shell prompt.


== Preparing the files ==
== Preparing the files ==
Line 28: Line 34:
=== hello.c ===
=== hello.c ===


Create a file with the following:
Next, create a file with the following:
<source lang="c">#include <efi.h>
<syntaxhighlight lang="c">#include <efi.h>
#include <efilib.h>
#include <efilib.h>


Line 41: Line 47:


/* Say hi */
/* Say hi */
Status = ST->ConOut->OutputString(ST->ConOut, L"Hello World\n\r");
Status = ST->ConOut->OutputString(ST->ConOut, L"Hello World\r\n"); // EFI Applications use Unicode and CRLF, a la Windows
if (EFI_ERROR(Status))
if (EFI_ERROR(Status))
return Status;
return Status;
Line 60: Line 66:


return Status;
return Status;
}</source>
}</syntaxhighlight>


=== gnu-efi/lib/data.c ===
=== gnu-efi/lib/data.c ===


We will also bring in the data.c file from the gnu-efi distribution, as this contains many predefined GUIDs for the various UEFI services. To avoid bloat and unnecessary dependencies on the rest of gnu-efi, you will need to edit it to remove the references to 'LibStubStriCmp', 'LibStubMetaiMatch' and 'LibStubStrLwrUpr' (simply make all the members of the LibStubUnicodeInterface structure be NULL).
Developers will also need bring in the data.c file from the gnu-efi distribution, as this contains many predefined GUIDs for the various UEFI services. To avoid bloat and unnecessary dependencies on the rest of gnu-efi, it will need to be edited to remove the references to 'LibStubStriCmp', 'LibStubMetaiMatch', and 'LibStubStrLwrUpr' (simply set all the members of the LibStubUnicodeInterface structure be NULL).


=== gnu-efi/lib/lib.h ===
=== gnu-efi/lib/lib.h ===


data.c includes this file. We copy it as-is to our source directory.
data.c includes this file. It must be copied as-is to the source directory.


== Building ==
== Building ==


To build, we use our cross-compiler:
To build, use the cross-compiler:
<source lang="bash">
<syntaxhighlight lang="bash">
# compile: (flags before -o become CFLAGS in your Makefile)
# compile: (flags before -o become CFLAGS in the Makefile)
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o hello.o hello.c
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o hello.o hello.c
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o data.o path/to/gnu-efi/lib/data.c
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o data.o path/to/gnu-efi/lib/data.c
# link: (flags before -o become LDFLAGS in your Makefile)
# link: (flags before -o become LDFLAGS in the Makefile)
x86_64-w64-mingw32-gcc -nostdlib -Wl,-dll -shared -Wl,--subsystem,10 -e efi_main -o BOOTX64.EFI hello.o data.o -lgcc
x86_64-w64-mingw32-gcc -nostdlib -Wl,-dll -shared -Wl,--subsystem,10 -e efi_main -o BOOTX64.EFI hello.o data.o
</syntaxhighlight>
</source>
Note here that '--subsystem 10' specifies an EFI application for ld.
Note here that '--subsystem 10' specifies an EFI application for ld.


=== Under LLVM/clang ===
=== Under LLVM/clang ===
The build sequence under LLVM/clang is essentially the same, although you do have the advantage of having ''all'' targets installed by default:
The build sequence under LLVM/clang is essentially the same, although there is the advantage of having ''all'' targets installed by default:


<source lang="bash">
<syntaxhighlight lang="bash">
CFLAGS='--target x86_64-unknown-windows
CFLAGS='-target x86_64-unknown-windows
-ffreestanding
-ffreestanding
-fshort-wchar
-fshort-wchar
-mno-red-zone
-mno-red-zone
-Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol'
-Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol'
LDFLAGS='--target x86_64-unknown-windows
LDFLAGS='-target x86_64-unknown-windows
-nostdlib
-nostdlib
-Wl,-entry:efi_main
-Wl,-entry:efi_main
Line 99: Line 105:
clang $CFLAGS -c -o data.o path/to/gnu-efi/lib/data.c
clang $CFLAGS -c -o data.o path/to/gnu-efi/lib/data.c
clang $LDFLAGS -o BOOTX64.EFI hello.o data.o
clang $LDFLAGS -o BOOTX64.EFI hello.o data.o
</syntaxhighlight>
</source>


Passing '--target x86_64-unknown-windows' to clang tells it to compile for x86_64 "Windows". This is quite not the same as 64-bit UEFI PE yet, but as before the "freestanding" part makes it a good kernel image. An example of this toolchain is found in the [https://github.com/c-util/c-efi c-efi] project.
Passing '--target x86_64-unknown-windows' to clang tells it to compile for x86_64 "Windows". This is quite not the same as 64-bit UEFI PE yet, but as before the "freestanding" part makes it a good kernel image. An example of this toolchain is found in the [https://github.com/c-util/c-efi c-efi] project.


Note the '-mno-red-zone' part we use here too -- it is a [https://stackoverflow.com/questions/25787408/why-cant-kernel-code-use-a-red-zone bad idea] to use a red zone for your kernel code if you are thinking about using interrupts. You should do it with GCC too, but read [[Libgcc without red zone]] for the extra work you need to do.
Note the '-mno-red-zone' part used here as well -- it is a [https://stackoverflow.com/questions/25787408/why-cant-kernel-code-use-a-red-zone bad idea] to use a red zone for kernel code if interrupts are to be implemented. It should be done with GCC as well, but read [[Libgcc without red zone]] for the extra work needed to be done.


== Creating the FAT image ==
== Creating the FAT image ==
{{Main|Bootable Disk}}


Next, you will need to create a FAT filesystem image.
Next, create a FAT filesystem image.
<source lang="bash">
<syntaxhighlight lang="bash">
dd if=/dev/zero of=fat.img bs=1k count=1440
dd if=/dev/zero of=fat.img bs=1k count=1440
mformat -i fat.img -f 1440 ::
mformat -i fat.img -f 1440 ::
Line 114: Line 121:
mmd -i fat.img ::/EFI/BOOT
mmd -i fat.img ::/EFI/BOOT
mcopy -i fat.img BOOTX64.EFI ::/EFI/BOOT
mcopy -i fat.img BOOTX64.EFI ::/EFI/BOOT
</syntaxhighlight>
</source>

Now, we can either use this as a USB stick image directly or embed it in HD image or CD image.


=== Running as a USB stick image ===
=== Running as a USB stick image ===


You can either write it directly to a USB stick and use in in a UEFI machine, or run it in qemu:
The FAT image can either be written directly to a USB stick and used in in a UEFI machine, or it can be run directly in QEMU:


<source lang="bash">qemu-system-x86_64 -L OVMF_dir/ -bios OVMF.fd -usb -usbdevice disk::fat.img</source>
<syntaxhighlight lang="bash">qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -usb -usbdevice disk::fat.img</syntaxhighlight>


=== Creating and running the HD image ===
=== Creating and running the HD image ===
Line 128: Line 133:
The HD image is a disk image in the [[GPT]] format, with the FAT image specially identified as a 'EFI System Partition'.
The HD image is a disk image in the [[GPT]] format, with the FAT image specially identified as a 'EFI System Partition'.


<source lang="bash">mkgpt -o hdimage.bin --image-size 4096 --part fat.img --type system
<syntaxhighlight lang="bash">mkgpt -o hdimage.bin --image-size 4096 --part fat.img --type system
qemu-system-x86_64 -L OVMF_dir/ -bios OVMF.fd -hda hdimage.bin</source>
qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -hda hdimage.bin</syntaxhighlight>


=== Creating and running the CD image ===
=== Creating and running the CD image ===
The iso image is a standard ISO9660 image which contains our FAT image as a file. A special El Torito option then points EFI aware systems to this image to be loaded. You can either burn the CD image to a CD and run it in a UEFI machine, or run it in QEMU:
The ISO image is a standard ISO9660 image which contains the FAT image as a file. A special El Torito option (-e) then points EFI aware systems to this image to be loaded. The CD image can either be burned to a CD and ran in a UEFI machine, or run directly in QEMU:
<source lang="bash">mkdir iso
<syntaxhighlight lang="bash">mkdir iso
cp fat.img iso
cp fat.img iso
xorriso -as mkisofs -R -f -e fat.img -no-emul-boot -o cdimage.iso iso
xorriso -as mkisofs -R -f -e fat.img -no-emul-boot -o cdimage.iso iso
qemu-system-x86_64 -L OVMF_dir/ -bios OVMF.fd -cdrom cdimage.iso</source>
qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -cdrom cdimage.iso</syntaxhighlight>


== What to do next? ==
== What to do next? ==


You may want to try using some more of the EFI boot services, e.g. to read more files from your FAT image, manage memory etc (see the [http://www.uefi.org/specifications UEFI Specifications] page for further documentation of this).
Developers may want to try using some more of the EFI boot services, e.g., to [[Loading files under UEFI|read more files]] from the FAT image, manage memory, set up [[GOP|graphical frame buffer]] etc. (see the [http://www.uefi.org/specifications UEFI Specifications] page for further documentation of this).

There is also a finished app bare bone which supports both Linux and Windows (Visual Studio), see [https://github.com/pbatard/uefi-simple uefi-simple].


== Common problems ==
== Common problems ==


Some UEFI hardware implementations require that the FAT image is in the FAT32 format (rather than FAT12 or FAT16). OVMF does not have this limitation, so you will not see such a problem in QEMU. The minimum size of a FAT32 filesystem is, however, around 32 MiB so you will need to generate a much bigger image and pass the '-F' option to mformat.
Some UEFI hardware implementations require that the FAT image is in the FAT32 format (rather than FAT12 or FAT16). OVMF does not have this limitation, so developers will not see such a problem in QEMU. However, the minimum size of a FAT32 filesystem is around 32 MiB, so developers will need to generate a much larger image and pass the '-F' option to mformat.


== See also ==
== See also ==
Line 150: Line 157:
* [[UEFI]]
* [[UEFI]]
* [[UEFI ISO Bare Bones]]
* [[UEFI ISO Bare Bones]]
* [[GNU-EFI]]
* [[POSIX-UEFI]]


[[Category:Bare bones tutorials]]
[[Category:Bare bones tutorials]]
[[Category:Firmware]]
[[Category:UEFI]]
[[Category:UEFI]]

Latest revision as of 05:44, 9 June 2024

WAIT! Have you read Getting Started, Beginner Mistakes, and some of the related OS theory?
Difficulty level

Medium

In this tutorial, developers will create a hard drive or ISO image containing a bare bones UEFI application for the x86-64 platform.

It is recommended to have read and fully understood the Bare Bones tutorial first. The UEFI page provides some background to the UEFI boot process and should also be consulted first.

This tutorial uses the header files and GUID definitions from the GNU-EFI project, but does not use the gnu-efi build system, but rather the MinGW-w64 or LLVM/Clang toolchain.

Prerequisites

Developers will need a GCC Cross-Compiler or Clang targeting the x86_64-w64-mingw32 target (for PE output), and the gnu-efi package (for UEFI headers). Most Linux distros provide cross-compilers for this target, so it's usually not necessary to build it yourself. This example does not link against GNU-EFI or follow its build process; only the headers are used.

To build the EFI filesystem image, developers can use MTools or mkgpt to create a hard disk image. To build a CD image, xorriso (in mkisofs emulation mode) will be needed. To run under an emulator, it is best to use qemu-system-x86_64 coupled with the x64 OVMF firmware.

Under an apt-based system (e.g. Debian/Ubuntu), developers can run:

sudo apt-get install qemu ovmf gnu-efi binutils-mingw-w64 gcc-mingw-w64 xorriso mtools

To install mkgpt you can run these commands:

git clone https://github.com/jncronin/mkgpt.git
cd mkgpt
automake --add-missing
autoreconf
./configure
make
sudo make install

Testing the emulator

Now is a good time to check the emulator is working successfully with the OVMF firmware.

qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd

should launch qemu and launch a UEFI shell prompt.

Preparing the files

hello.c

Next, create a file with the following:

#include <efi.h>
#include <efilib.h>

EFI_STATUS efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
    EFI_STATUS Status;
    EFI_INPUT_KEY Key;

    /* Store the system table for future use in other functions */
    ST = SystemTable;

    /* Say hi */
    Status = ST->ConOut->OutputString(ST->ConOut, L"Hello World\r\n"); // EFI Applications use Unicode and CRLF, a la Windows
    if (EFI_ERROR(Status))
        return Status;

    /* Now wait for a keystroke before continuing, otherwise your
       message will flash off the screen before you see it.

       First, we need to empty the console input buffer to flush
       out any keystrokes entered before this point */
    Status = ST->ConIn->Reset(ST->ConIn, FALSE);
    if (EFI_ERROR(Status))
        return Status;

    /* Now wait until a key becomes available.  This is a simple
       polling implementation.  You could try and use the WaitForKey
       event instead if you like */
    while ((Status = ST->ConIn->ReadKeyStroke(ST->ConIn, &Key)) == EFI_NOT_READY) ;

    return Status;
}

gnu-efi/lib/data.c

Developers will also need bring in the data.c file from the gnu-efi distribution, as this contains many predefined GUIDs for the various UEFI services. To avoid bloat and unnecessary dependencies on the rest of gnu-efi, it will need to be edited to remove the references to 'LibStubStriCmp', 'LibStubMetaiMatch', and 'LibStubStrLwrUpr' (simply set all the members of the LibStubUnicodeInterface structure be NULL).

gnu-efi/lib/lib.h

data.c includes this file. It must be copied as-is to the source directory.

Building

To build, use the cross-compiler:

# compile: (flags before -o become CFLAGS in the Makefile)
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o hello.o hello.c
x86_64-w64-mingw32-gcc -ffreestanding -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol -c -o data.o path/to/gnu-efi/lib/data.c
# link: (flags before -o become LDFLAGS in the Makefile)
x86_64-w64-mingw32-gcc -nostdlib -Wl,-dll -shared -Wl,--subsystem,10 -e efi_main -o BOOTX64.EFI hello.o data.o

Note here that '--subsystem 10' specifies an EFI application for ld.

Under LLVM/clang

The build sequence under LLVM/clang is essentially the same, although there is the advantage of having all targets installed by default:

CFLAGS='-target x86_64-unknown-windows 
        -ffreestanding 
        -fshort-wchar 
        -mno-red-zone 
        -Ipath/to/gnu-efi/inc -Ipath/to/gnu-efi/inc/x86_64 -Ipath/to/gnu-efi/inc/protocol'
LDFLAGS='-target x86_64-unknown-windows 
        -nostdlib 
        -Wl,-entry:efi_main 
        -Wl,-subsystem:efi_application 
        -fuse-ld=lld-link'
clang $CFLAGS -c -o hello.o hello.c
clang $CFLAGS -c -o data.o path/to/gnu-efi/lib/data.c
clang $LDFLAGS -o BOOTX64.EFI hello.o data.o

Passing '--target x86_64-unknown-windows' to clang tells it to compile for x86_64 "Windows". This is quite not the same as 64-bit UEFI PE yet, but as before the "freestanding" part makes it a good kernel image. An example of this toolchain is found in the c-efi project.

Note the '-mno-red-zone' part used here as well -- it is a bad idea to use a red zone for kernel code if interrupts are to be implemented. It should be done with GCC as well, but read Libgcc without red zone for the extra work needed to be done.

Creating the FAT image

Main article: Bootable Disk

Next, create a FAT filesystem image.

dd if=/dev/zero of=fat.img bs=1k count=1440
mformat -i fat.img -f 1440 ::
mmd -i fat.img ::/EFI
mmd -i fat.img ::/EFI/BOOT
mcopy -i fat.img BOOTX64.EFI ::/EFI/BOOT

Running as a USB stick image

The FAT image can either be written directly to a USB stick and used in in a UEFI machine, or it can be run directly in QEMU:

qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -usb -usbdevice disk::fat.img

Creating and running the HD image

The HD image is a disk image in the GPT format, with the FAT image specially identified as a 'EFI System Partition'.

mkgpt -o hdimage.bin --image-size 4096 --part fat.img --type system
qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -hda hdimage.bin

Creating and running the CD image

The ISO image is a standard ISO9660 image which contains the FAT image as a file. A special El Torito option (-e) then points EFI aware systems to this image to be loaded. The CD image can either be burned to a CD and ran in a UEFI machine, or run directly in QEMU:

mkdir iso
cp fat.img iso
xorriso -as mkisofs -R -f -e fat.img -no-emul-boot -o cdimage.iso iso
qemu-system-x86_64 -L OVMF_dir/ -pflash OVMF.fd -cdrom cdimage.iso

What to do next?

Developers may want to try using some more of the EFI boot services, e.g., to read more files from the FAT image, manage memory, set up graphical frame buffer etc. (see the UEFI Specifications page for further documentation of this).

There is also a finished app bare bone which supports both Linux and Windows (Visual Studio), see uefi-simple.

Common problems

Some UEFI hardware implementations require that the FAT image is in the FAT32 format (rather than FAT12 or FAT16). OVMF does not have this limitation, so developers will not see such a problem in QEMU. However, the minimum size of a FAT32 filesystem is around 32 MiB, so developers will need to generate a much larger image and pass the '-F' option to mformat.

See also