code uses the GetTime function from the Runtime Service, however this has
been shown to not return a useable time on many arm64 UEFI implementations.
Reviewed by: jhb, smh
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D6709
- efi_lookup_devpath() uses the DEVICE_PATH_PROTOCOL to obtain the
DEVICE_PATH for a given EFI handle.
- efi_lookup_image_devpath() uses the LOADED_IMAGE_DEVICE_PATH_PROTOCOL
to lookup the device path of the device used to load a loaded image.
- efi_devpath_name() uses the DEVICE_PATH_TO_TEXT_PROTOCOL to generate
a string description of a device path. The returned string is a CHAR16
string that can be printed via the recently added '%S' format in
libstand's printf(). Note that the returned string is returned in
allocated storage that should be freed by calling
efi_free_devpath_name().
- efi_devpath_last_node() walks a DEVICE_PATH returning a pointer to the
final node in the path (not counting the terminating node). That is,
it returns a pointer to the last meaninful node in a DEVICE_PATH.
- efi_devpath_trim() generates a new DEVICE_PATH from an existing
DEVICE_PATH. The new DEVICE_PATH does not include the last
non-terminating node in the original path. If the original DEVICE_PATH
only contains the terminating node, this function returns NULL.
The caller is responsible for freeing the returned DEVICE_PATH via
free().
- efi_devpath_handle() attempts to find a handle that corresponds to a
given device path. However, if nodes at the end of the device path do
not have valid handles associated with them, this function will return
a handle that matches a node earlier in the device path. In particular,
this function returns a handle for the node closest to the end of the
device path which has a valid handle.
Sponsored by: Cisco Systems
This builds on the modular EFI loader support added r294060 adding a
module to provide ZFS boot support on EFI systems.
It should be noted that EFI uses a fixed size memory block for all
allocations performed by the loader so it may be necessary to tune this
size.
For example when building an image which uses mfs_root e.g. mfsbsd, adding
the following to /etc/make.conf would be needed to prevent EFI from running
out of memory when loading the mfs_root image.
EFI_STAGING_SIZE=128
Submitted by: Eric McCorkle
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Make EFI boot loader modular in preparation for adding ZFS support.
This is a partial commit of the D4515.
Submitted by: Eric McCorkle
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4515
Set WARNS if not set for EFI boot code and fix the issues highlighted by
setting it.
Most components are set to WARNS level 6 with few being left at lower
levels due to the amount of changes needed to fix at higher levels.
Error types fixed:
* Missing / invalid casts
* Missing inner structs
* Unused vars
* Missing static for internal only funcs
* Missing prototypes
* Alignment changes
* Use of uninitialised vars
* Unknown pragma (intrinsic)
* Missing types etc due to missing includes
* printf formatting types
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4839
r247216:
Add the ability for a device to have an "alias" handle.
r247379:
Fix network device registration.
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points
at the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition".
The existing EFI partition code only looks for logical partitions and
so the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other media
as well as the loader will live in the EFI system partition, not on the
partition containing the kernel.
r247381:
Remove a scatalogical debug printf that crept in.
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
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.
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)
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)
