Since the efipart rewrite, the chain command was looking for device
handle using interface applicable only for net devices. Disk
partitions and zfs pools need their own approach to find the proper handle.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D12287
Rename boot1's wcslen to ucs2len, which we can't use in userland
because wchar in userland is unsigned, not short. Move it into
efichar.c. Also spell '* 2' as '* sizeof(efi_char)' and add 1 for the
trailing NUL to transition the FreeBSD boot env vars to being NUL
terminated on the same line...
Sponsored by: Netflix
Record the file path for boot1.efi as the UEFI environemnt variable
FreeBSDBootVarGUID:Boot1Path. Record the device this came from as
FreeBSDBootVarGUID:Boot1Dev. While later stages of the boot may be
able to guess these values by retrieving UEFIGlobal:BootCurrent and
groveling through the correct UEFIGlobal:BootXXXX, this provides
certanty in the face of behavior from any part of the boot loader
chain that might "guess" what to do next. These env variables are
volatile and will disappear on reboot.
Sponsored by: Netflix
Make the return type of efi_main uniform. Declare the Exit() function
as not returning. Move efi_main's declaration to the proper header.
Sponsored by: Netflix
Move the efi_main routine out of libefi into sys/boot/efi/loader.
Since boot1 has its own efi_main routine, this effectively prevents
boot1 from linking with libefi. By moving it out, we can share code
better (though though some refactoring with boot1's efi_main and
loader.efi's efi_main is definitely in order).
Sponsored by: Netflix
This patch moves code necessary for the fmtdev functionality from
loader to libefi, allowing other applications to make use of it
Submitted by: Eric McCorkle
Differential Revision: https://reviews.freebsd.org/D11862
This patch adds additional EFI utility functions to convert errno
values to EFI_STATUS errors, as well as EFI times to UNIX times.
Submitted by: Eric McCorkle
Differential Revision: https://reviews.freebsd.org/D11858
This patch moves some EFI ZFS functions from loader to libefi,
allowing them to be used by anything that links against libefi.
Submitted by: Eric McCorkle
Differential Revision: https://reviews.freebsd.org/D11855
This patch adds definitions and utility code for creating EFI drivers
using the EFI_DRIVER_BINDING_PROTOCOL.
Submitted by: Eric McCorkle
Differential Revision: https://reviews.freebsd.org/D11852
The EFI memory descriptor 64-bit aligns PhysicalStart on both 32- and
64-bit platforms. Make the padding explicit for i386 EFI.
Submitted by: Siva Mahadevan <smahadevan@freebsdfoundation.org>
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11301
Rewrite EFI part device interface to present disk devices in more
user friendly way.
We keep list of three types of devices: floppy, cd and disk, the
visible names: fdX: cdX: and diskX:
Use common/disk.c and common/part.c interfaces to manage the
partitioning.
The lsdev -l will additionally list the device path.
Reviewed by: imp, allanjude
Approved by: imp (mentor), allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8581
Since we have dedicated libefi/env.c file for variable support, the following
changes are done:
Simple cstyle changes in env.c
Moved efi variable related commands from loader/main.c to libefi/env.c
Did create function to set "efi-version" environment variable in env.c.
This function does serve two purposes: for first a small clean up of the
loader main(), and for second, it does replace the otherwise unused
efi_variable_support hack.
A bit of cleanup of ficl backend functions. The TEST_MAIN has no meaning,
and removed few memory leaks.
The forth code is updated to use "efi-version" variable, instead of ficl
environment check.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D9165
With clang 4.0.0, the EFI API header causes the following warning:
In file included from sys/boot/efi/loader/bootinfo.c:43:
In file included from sys/boot/efi/loader/../include/efi.h:52:
sys/boot/efi/include/efiapi.h:534:32: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
(EFIAPI *EFI_RESERVED_SERVICE) (
^
Add VOID to make it into a real prototype.
Reviewed by: imp, emaste, tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9132
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
Fix EFI boot support when presented with multiple valid boot partitions
across multiple devices.
It now prefers to boot from partitions that are present on the underlying
device that the boot1 image was loaded from. This means that it will boot
from the partitions on device the user chose from EFI boot menu in
preference to those on other devices.
Also fixed is the recovery from a failed attempt to boot, from a seemingly
valid partition, by continuing to trying all other available partitions
no matter what the error.
boot1 now use * to signify a partition what was accepted from the preferred
device and + otherwise.
Finally some error messages where improved and DPRINTF's with slowed boot
to aid debugging.
ZFS will still be preferred over UFS when both are available on the boot
device.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D5108
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
i386 is the only current FreeBSD architecture that ever used a.out
format.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D4687
command called 'uga' to show whether UGA is implemented by the
firmware and what the settings are. It also includes filling
the efi_fb structure from the UGA information when GOP isn't
implemented by the firmware.
Since UGA does not provide information about the stride, we
set the stride to the horizontal resolution. This is likely
not correct and we should determine the stride by trial and
error. For now, this should show something on the console
rather than nothing.
Refactor this file to maximize code reuse.
PR: 202730
first, EFI will use its definitions for {,U}INT{8,16,32,64} and
BOOLEAN. When EFI is included first, define ACPI_USE_SYSTEM_INTTYPES
to tell ACPI that these are already defined.
Differential Revision: https://reviews.freebsd.org/D1905
to the loader in a similar way to the ACPI tables.
This will be used on arm64 but is not specific to the architecture.
Sponsored by: The FreeBSD Foundation
The loader previously failed to display on MacBooks and other systems
where the UEFI firmware remained in graphics mode.
Submitted by: Rafael Espíndola
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
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.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
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.
place.
This moves the dependency on GCC's and other compiler's features into
the central sys/cdefs.h file, while the individual source files can
then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to
refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42.
By now, GCC and ICC (the Intel compiler) have been actively tested on
IA32 platforms by netchild. Extension to other compilers is supposed
to be possible, of course.
Submitted by: netchild
Reviewed by: various developers on arch@, some time ago
