History log of /freebsd-9.3-release/sys/boot/efi/include/efilib.h
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
# 267654 19-Jun-2014 gjb

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

# 225736 22-Sep-2011 kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)


# 201941 09-Jan-2010 marcel

Remove file system support based on the simple file system protocol
as this only allows us to access file systems that EFI knows about.
With a loader that can only use EFI-supported file systems, we're
forced to put /boot on the EFI system partition. This is suboptimal
in the following ways:
1. With /boot a symlink to /efi/boot, mergemaster complains about
the mismatch and there's no quick solution.
2. The EFI loader can only boot a single version of FreeBSD. There's
no way to install multiple versions of FreeBSD and select one
at the loader prompt.
3. ZFS maintains /boot/zfs/zpool.cache and with /boot a symlink we
end up with the file on a MSDOS file system. ZFS does not have
proper handling of file systems that are under Giant.

Implement a disk device based on the block I/O protocol instead and
pull in file system code from libstand. The disk devices are really
the partitions that EFI knows about.

This change is backward compatible.

MFC after: 1 week


# 164010 05-Nov-2006 marcel

Major rework of the ia64 loaders. The two primary objectives are:
1. Make libefi portable by removing ia64 specific code and build
it on i386 and amd64 by default to prevent regressions. These
changes include fixes and improvements over previous code to
establish or improve APIs where none existed or when the amount
of kluging was unacceptably high.
2. Increase the amount of sharing between the efi and ski loaders
to improve maintainability of the loaders and simplify making
changes to the loader-kernel handshaking in the future.

The version of the efi and ski loaders are now both changed to 1.2
as user visible improvements and changes have been made.


# 163898 02-Nov-2006 marcel

Sync the EFI headers with version 1.10.14.62 of the Intel sample EFI
implementation. This re-introduces C99 style comments that previously
were replaced by original C comments.


# 138141 27-Nov-2004 marcel

o Introduce efimd_va2pa() to translate addresses in efi_copy{in|out}()
and efi_readin(). This removes MD code from copy.c.
o Don't unconditionally add pal.S to SRCS. It's specific to ia64.


# 107733 10-Dec-2002 marcel

Pass the HCDP table address to the kernel. If no such table exists,
NULL is passed. The address of the HCDP table can be found by
iterating over the configuration tables in the EFI system table.
To avoid more duplication, a function can be called with the GUID
of interest. The function will do the scanning. Use the function
in all places where we iterate over the configuration tables in
an attempt to find a specific one.

Bump the loader version number as the result of this.

Approved by: re (blanket)


# 107723 10-Dec-2002 marcel

Change the startup code to fix a memory leak and to allow us to
accept load options (=command line options).

The call graph changes from *entry*->efi_main->efi_init, where
efi_main is the EFI equivalent of main to *entry*->efi_main->main,
where main is what you'd expect. efi_main now is what efi_init was.
The prototype of main follows that of C. The first argument is argc
and the second is argv. There is no third argument.
Allocation of heap pages is now handled by the EFI library and it
now deallocates the pages when main() returns or when exit() is
called. This allows us to safely return to the boot manager (or
EFI shell) without leaks. EFI applications are responsible to free
all memory themselves.

Handling of the load options is a bit tricky. There are either no
load options, load options in ASCII or load options in Unicode.
The EFI library will translate the ASCII options to Unicode options
as to simplify user code. Since the load options are passed as a
single string (if present) and main() accepts argc and argv, the
startup code also has to split the string into words and build the
argv vector. Here the trickiness starts. When the loader is started
from the EFI shell, argv[0] will automaticly load the program name.
In all other cases (ie through the boot manager), this is not the
case. Unfortunately, there's no trivial way to check. Hence, a
set of conditions is checked to determine if we need to fill in
argv[0] ourselves or not. This checking is not perfect. There are
known cases where it fails to do the right thing. The logic works
for most expected cases, though. This includes the case where no
options are given.

Approved by: re (blanket)


# 77943 09-Jun-2001 dfr

First approximation of an ia64 EFI loader. Not functional.