303975 |
11-Aug-2016 |
gjb |
Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, and rename it to RC1.
Update __FreeBSD_version.
Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and the dvd1.iso packages population.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
302408 |
08-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
301306 |
04-Jun-2016 |
andrew |
Use the UEFI event timer to update the time on arm and arm64. The current 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
|
300780 |
26-May-2016 |
jhb |
Add some routines for working with EFI DEVICE_PATH objects.
- 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
|
298826 |
30-Apr-2016 |
pfg |
sys/boot: spelling fixes in comments.
No functional change.
|
295869 |
21-Feb-2016 |
andrew |
Make efi_time and EFI_GetTimeOfDay static, neither are used by other parts of the efi code.
Sponsored by: ABT Systems Ltd
|
295320 |
05-Feb-2016 |
smh |
Fix EFI multi device boot support
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
|
294068 |
15-Jan-2016 |
smh |
Add EFI ZFS boot support
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
|
294060 |
15-Jan-2016 |
smh |
Modularise EFI boot loader
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
|
293724 |
12-Jan-2016 |
smh |
Enable warnings in EFI boot code
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
|
293268 |
06-Jan-2016 |
smh |
Fix _MSC_EXTENSIONS checks
Use #ifdef instead of #if checks to prevent warnings generated by checks to be enabled shortly.
MFC after: 2 weeks Sponsored by: Multiplay
|
293244 |
06-Jan-2016 |
emaste |
Introduce and use new EFI_ERROR_CODE macro for EFI errors
Submitted by: smh MFC after: 1 week
|
292625 |
22-Dec-2015 |
emaste |
Revert accidental whitespace changes included with r292623
|
292623 |
22-Dec-2015 |
emaste |
Support a.out format in nlist only on i386
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
|
287317 |
31-Aug-2015 |
marcel |
Add support for the UGA draw protocol. This includes adding a 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
|
281526 |
14-Apr-2015 |
andrew |
Add support for arm64 to loader.efi and boot1.efi
Reviewed by: emaste Sponsored by: The FreeBSD Foundation
|
281156 |
06-Apr-2015 |
andrew |
Add support to the efi boot1 and loader for 32-bit ARM. This will be used by the future qemu virt support.
Differential Revision: https://reviews.freebsd.org/D2238 Reviewed by: emaste
|
279038 |
20-Feb-2015 |
imp |
Allow EFI and ACPI to be included together. When ACPI is included 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
|
278234 |
05-Feb-2015 |
rpaulo |
EFI: print more information about EFI Tables.
This adds the GUIDs for DXE, HOB, Memory Type Information and Debug Image Info.
|
274439 |
12-Nov-2014 |
andrew |
Add the FDT table GUID. This is used to pass the device tree blob from UEFI 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
|
272105 |
25-Sep-2014 |
emaste |
Remove duplicated header content
I fail at patch(1).
MFC after: 3 days
|
271762 |
18-Sep-2014 |
emaste |
Switch to text mode in UEFI boot
The loader previously failed to display on MacBooks and other systems where the UEFI firmware remained in graphics mode.
Submitted by: Rafael EspĂndola
|
268351 |
07-Jul-2014 |
marcel |
Remove ia64.
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
|
264095 |
04-Apr-2014 |
emaste |
Support UEFI booting on amd64 via loader.efi
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
|
264088 |
03-Apr-2014 |
emaste |
Merge efilib changes from projects/uefi
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.
|
263115 |
13-Mar-2014 |
emaste |
Add amd64 EFI headers
Sponsored by: The FreeBSD Foundation
|
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.
|
143250 |
07-Mar-2005 |
stefanf |
Don't try to use 'typedef struct foo' if just 'struct foo' makes more sense and works on all compilers. This also removes the need for __CC_SUPPORTS_FORWARD_REFERENCE_CONSTRUCT in <sys/cdefs.h>.
OK'ed by: marcel, dfr
|
143176 |
06-Mar-2005 |
stefanf |
Fix typos in a comment.
|
143063 |
02-Mar-2005 |
joerg |
netchild's mega-patch to isolate compiler dependencies into a central 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
|
139738 |
05-Jan-2005 |
imp |
Start each of the license/copyright comments with /*-
|
138141 |
28-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.
|
123399 |
10-Dec-2003 |
jhb |
Fix typo in comment.
|
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)
|
107686 |
08-Dec-2002 |
marcel |
Add the GUID of the DIG64 HCDP table.
|
96893 |
19-May-2002 |
marcel |
An almost mechanical sweep to replace C++ style comments with C style comments. This is not an attempt to conform to style(9). Such has lower priority.
|
96755 |
16-May-2002 |
trhodes |
More s/file system/filesystem/g
|
92656 |
19-Mar-2002 |
peter |
gcc-3.1 likes to have extra { } around the internal array initializers in the GUID templates.
|
86588 |
19-Nov-2001 |
peter |
Lookup the EFI_FPSWA driver and pass the interface pointer through to the kernel before we call ExitBootServices(). I've typed the definitions in efifpswa.h from the Intel FPSWA manual (urk).
|
86584 |
19-Nov-2001 |
peter |
This is used in C, not C++. functions with no args have func(void) in our kernel.
|
85892 |
02-Nov-2001 |
mike |
o Add new header <sys/stdint.h>. o Make <stdint.h> a symbolic link to <sys/stdint.h>. o Move most of <sys/inttypes.h> into <sys/stdint.h>, as per C99. o Remove <sys/inttypes.h>. o Adjust includes in sys/types.h and boot/efi/include/ia64/efibind.h to reflect new location of integer types in <sys/stdint.h>. o Remove previously symbolicly linked <inttypes.h>, instead create a new file. o Add MD headers <machine/_inttypes.h> from NetBSD. o Include <sys/stdint.h> in <inttypes.h>, as required by C99; and include <machine/_inttypes.h> in <inttypes.h>, to fill in the remaining requirements for <inttypes.h>. o Add additional integer types in <machine/ansi.h> and <machine/limits.h> which are included via <sys/stdint.h>.
Partially obtain from: NetBSD Tested on: alpha, i386 Discussed on: freebsd-standards@bostonradio.org Reviewed by: bde, fenner, obrien, wollman
|
77943 |
09-Jun-2001 |
dfr |
First approximation of an ia64 EFI loader. Not functional.
|