summaryrefslogtreecommitdiffstats
path: root/sys/boot/efi/libefi
Commit message (Collapse)AuthorAgeFilesLines
* Merge from current r294767,294769,295408imp2016-02-111-2/+2
| | | | | | | | r294767: Parse command line arguments in loader.fi r294769: Allow newlines to be treated as whitespace when parsing args r295408: Implement -P command line option in for EFI booting. Approved by: re@ (gjb@)
* Fix ia64 build failures in EFI platformsmh2016-02-111-0/+6
| | | | | | | | | | | | | | | | | | The MFC of the recent EFI work to stable/10 caused build breakage under ia64. It was not apparent that there was EFI code outside the EFI tree as this is not the case in HEAD, however in stable/10 there is for ia64. This change does the following: * Re-enables libefi for ia64 under gcc. * Adds the ignore for unsupported pragma's when building libefi for ia64. * Adds the missing parameter to efi_handle_lookup in the ia64 loader. This is a direct commit as ia64 is no longer supported after 10.x Approved by: re (marius) Sponsored by: Multiplay
* MFC r294068, r294265smh2016-01-281-1/+23
| | | | | | | | | | | MFC r294068: Add EFI ZFS boot support MFC r294265: Fix broken DPRINTF and wire up EFI_DEBUG so -DEFI_DEBUG to make works. Relnotes: Yes Sponsored by: Multiplay
* MFC r281169, r293724, r293796, r294029, r294041, r294058smh2016-01-284-2/+4
| | | | | | | | | | | | | | | | | | | | | | MFC r281169 (by andrew): Make global variabled only used in this file static MFC r294058: Make common boot file_loadraw name parameter const MFC r294041: Remove unused reg param from fdt_fixup_memory MFC r293724: Enable warnings in EFI boot code MFC r293796: Fix typo in libefi.c MFC r294029: Only build EFI components on supported compilers Sponsored by: Multiplay
* MFC r293233: loader.efi: add terminal emulation supportemaste2016-01-202-18/+403
| | | | | | | This is based on the vidconsole implementation. Submitted by: Toomas Soome <tsoome@me.com> Relnotes: Yes
* MFC r281524 by andrew@: Use MACHINE in the efi loader when it is what we meanemaste2016-01-071-1/+1
| | | | | | | It may not be the same as MACHINE_CPUARCH, it just happened to be the case the architectures this code currently supports. Fixes build failure reported by Oliver Pinter.
* MFC r280047: build x86-specific files in amd64 loader.efiemaste2015-12-211-4/+0
| | | | | | | This was originally done for the arm and arm64 loader.efi and is MFC'd here to ease future UEFI loader MFCs. Sponsored by: The FreeBSD Foundation
* MFC r285246: Avoid creating invalid UEFI device pathemaste2015-07-281-5/+18
| | | | | | | | | | | | | The UEFI loader on the 10.1 release install disk (disc1) modifies an existing EFI_DEVICE_PATH_PROTOCOL instance in an apparent attempt to truncate the device path. In doing so it creates an invalid device path. Perform the equivalent action without modification of structures allocated by firmware. PR: 197641 Submitted by: Chris Ruffin <chris.ruffin at intel.com>
* MFC 279950:jhb2015-04-091-1/+1
| | | | | | Enable bzipfs support in the EFI loader. - Add bzipfs to the list of supported filesystems in the EFI loader. - Increase the heap size allocated for the EFI loader from 2MB to 3MB.
* MFC 279949:jhb2015-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | The System V ABI for amd64 allows functions to use space in a 128 byte redzone below the stack pointer for scratch space and requires interrupt and signal frames to avoid overwriting it. However, EFI uses the Windows ABI which does not support this. As a result, interrupt handlers in EFI push their interrupt frames directly on top of the stack pointer. If the compiler used the red zone in a function in the EFI loader, then a device interrupt that occurred while that function was running could trash its local variables. In practice this happens fairly reliable when using gzipfs as an interrupt during decompression can trash the local variables in the inflate_table() function resulting in corrupted output or hangs. Fix this by disabling the redzone for amd64 EFI binaries. This requires building not only the loader but any libraries used by the loader without redzone support. Thanks to Jilles for pointing me at the redzone once I found the stack corruption.
* MFC r271762: Switch to text mode in UEFI bootemaste2014-09-221-0/+10
| | | | | | | | | The loader previously failed to display on MacBooks and other systems where the UEFI firmware remained in graphics mode. Submitted by: Rafael Espindola Approved by: re
* MFC r271475 by ambrisko:emaste2014-09-191-0/+4
| | | | | | Add support for serial and null console to UEFI boot loader. Approved by: re
* MFC UEFI loaderemaste2014-09-044-11/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MFC consists of the following SVN revisions: 258741 261568 261603 261668 263115 263117 263968 264078 264087 264088 264092 264095 264115 264132 264208 264261 264262 264263 264319 265028 265057 268974 Detailed commit messages: r258741: Note that libstand is 32-bit on amd64 and powerpc64 r261568: Build libstand as a 64-bit library on amd64 The 32-bit bootloaders now link against libstand.a in sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a to be 32-bit. r261603: Don't force efi to a 32-bit build on amd64 r261668: Build libstand as a 64-bit library on ppc64 The 32-bit bootloaders now link against libstand.a in sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a to be 32-bit. This is equivalent to r261568 for amd64. r263115: Add amd64 EFI headers r263117: Connect 64-bit boot ficl to the build It is not yet used, but this will ensure it doesn't get broken. r263968: Use EFI types for EFI values (silences warnings). EFI UINTN is actually a 64-bit type on 64-bit processors. r264078: Put each source file on a separate line This will simplify rebasing the amd64 UEFI patch set. r264087: Build boot/ficl as 64-bit library on amd64 The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32, as is done with libstand32. The native 64-bit ficl will be used by the upcoming UEFI loader. r264088: 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. r264092: Add -fPIC for amd64 r264095: 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. r264115: Fix printf format mismatches r264132: Connect sys/boot/amd64 to the build r264208: Do not build the amd64 UEFI loader with GCC The UEFI loader causes buildworld to fail when building with (in-tree) GCC, due to a typedef redefinition. As it happens the in-tree GCC cannot successfully build the UEFI loader anyhow, as it does not support __attribute__((ms_abi)). Thus, just avoid trying to build it with GCC, rather than disconnecting it from the build until the underlying issue is fixed. r264261: Correct a variable's type for 64-bit Ficl FICL_INT is long. r264262: Fix printf args for 64-bit archs r264263: Add explicit casts to quiet warnings in libefi r264319: Fix EFI loader object tree creation on 9.x build hosts Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi subdirectory was skipped altogether for gcc (since GCC does not support a required attribute). However, during the early buildworld stages ${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build hosts), not the compiler that will eventually be used. This caused "make obj" to skip the efi subdirectory. In later build stages ${COMPILER_TYPE} is "clang", and then the efi loader would attempt to build in the source directory. r265028 (dteske): Disable the beastie menu for EFI console ... which doesn't support ANSI codes (so things like `at-xy', `clear', and other commands don't work making it impossible to generate a living menu). r265057 (nwhitehorn): Turn off various fancy instruction sets... as well as deduplicate some options. This makes the EFI loader build work with CPUTYPE=native in make.conf on my Core i5. r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats Relnotes: Yes Sponsored by: The FreeBSD Foundation
* Typo in a comment.rpaulo2012-12-071-1/+1
|
* MFaltix:marcel2011-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add support for Pre-Boot Virtual Memory (PBVM) to the loader. PBVM allows us to link the kernel at a fixed virtual address without having to make any assumptions about the physical memory layout. On the SGI Altix 350 for example, there's no usuable physical memory below 192GB. Also, the PBVM allows us to control better where we're going to physically load the kernel and its modules so that we can make sure we load the kernel in memory that's close to the BSP. The PBVM is managed by a simple page table. The minimum size of the page table is 4KB (EFI page size) and the maximum is currently set to 1MB. A page in the PBVM is 64KB, as that's the maximum alignment one can specify in a linker script. The bottom line is that PBVM is between 64KB and 8GB in size. The loader maps the PBVM page table at a fixed virtual address and using a single translations. The PBVM itself is also mapped using a single translation for a maximum of 32MB. While here, increase the heap in the EFI loader from 512KB to 2MB and set the stage for supporting relocatable modules.
* Revert previous commit: EFI_STATUS is a 64-bit integral on ia64. Fix themarcel2011-03-161-1/+1
| | | | | | | | compile warning on i386 (where EFI_STATUS is a 32-bit integral) by casting the status argument to u_long instead. Pointy hat: brucec MFC after: 3 days
* Handle memory allocation failures in include().brucec2011-02-231-1/+1
| | | | | | PR: i386/85652 Submitted by: Ben Thomas <bthomas at virtualiron.com> MFC after: 3 days
* Help static analysis by initializing variables that we know cannot bemarcel2011-01-062-0/+2
| | | | used uninitialized, but which cannot be inferred from the code itself.
* MF tbemd: move to using specific architecture makefilesimp2010-08-231-1/+1
|
* Remove file system support based on the simple file system protocolmarcel2010-01-093-443/+267
| | | | | | | | | | | | | | | | | | | | | | | 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
* Major rework of the ia64 loaders. The two primary objectives are:marcel2006-11-0513-1312/+516
| | | | | | | | | | | | | | 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.
* Make this compile on EFI32. The EFI_PHYSICAL_ADDRESS type is alwaysmarcel2006-11-031-1/+1
| | | | 64-bit, even when sizeof(void *) is 32-bit.
* Extend struct devdesc with a unit field, called d_unit. Promote themarcel2006-11-023-9/+6
| | | | | | | | | device (kind) specific unit field to the common field. This change allows a future version of libefi to work without requiring anything more than what is defined in struct devdesc and as such makes it possible to compile said version of libefi for different platforms without requiring that those platforms have identical derivatives of struct devdesc.
* Remove more Alpha bits from the boot code including fixing severaljhb2006-05-121-1/+1
| | | | stale comments.
* Add loader(8) variables for RB_DFLTROOT, RB_MUTE, and RB_PAUSE:ru2005-09-221-2/+8
| | | | "boot_dfltroot", "boot_mute", and "boot_pause" respectively.
* Start each of the license/copyright comments with /*-imp2005-01-052-2/+2
|
* Remove the last vestiges of the userconfig option. None of this actuallyscottl2004-12-011-4/+0
| | | | did anything, so this commit should be considered a NO-OP.
* o Introduce efimd_va2pa() to translate addresses in efi_copy{in|out}()marcel2004-11-282-32/+19
| | | | | and efi_readin(). This removes MD code from copy.c. o Don't unconditionally add pal.S to SRCS. It's specific to ia64.
* This file was repocopied to src/sys/boot/ia64/efi.marcel2004-11-232-387/+0
|
* For variables that are only checked with defined(), don't provideru2004-10-241-1/+1
| | | | any fake value.
* Redefine a PTE as a 64-bit integral type instead of a struct ofmarcel2004-09-231-13/+5
| | | | | bit-fields. Unify the PTE defines accordingly and update all uses.
* o Support the REL32LSB relocation. It's in the ELF file from whichmarcel2004-07-201-9/+18
| | | | | | | | | we construct the EFI image. It doesn't seem to actually end up in the EFI image, AFAICT. o Replace .quad, .long and .short with data8, data4 and data2 resp. The former are gnuisms. o Redefine _start_plabel as a data16 with @iplt(_start) as its value. This is the preferred way to create user PLT entries.
* Fix the creation of EFI images that got broken by the import ofmarcel2004-07-201-1/+1
| | | | | | | | | binutils 2.15. The linker now creates a .rela.dyn section for dynamic relocations, while our script created a .rela section. Likewise, we copied the .rela section to the EFI image, but not the .rela.dyn section. The fix is to rename .rela to .rela.dyn in the linker script so that all relocations end up in the same section again. This we copy into the EFI image.
* Remove advertising clause from University of California Regent's license,imp2004-04-051-4/+0
| | | | | | per letter dated July 22, 1999. Approved by: core
* Reset the text attributes when initializing the console. The EFImarcel2004-03-091-0/+1
| | | | | loader typically doesn't do this so that we end up booting the with whatever the EFI loader has set it to last.
* o Don't build with -fpic. It's not needed and inconsistent with howmarcel2004-02-131-5/+0
| | | | | other constributions are compiled. o Remove powerpc specific additions to CFLAGS.
* Tidy up makefiles.ru2004-02-121-11/+4
| | | | Tested by: marcel
* Convert to __FBSDID.obrien2004-01-045-10/+15
|
* Don't hardcode unit 0 for the current device if we're loaded from anmarcel2003-08-022-1/+15
| | | | | | | | | | | | EFI file system. When booting from a CD and there's already an EFI system partition on the disk, setting the current device to unit 0 will select the harddisk. This invariably breaks installing FreeBSD when other operating systems have been installed before. We obviously want to do the same when we're booting over the network. Maybe later. Based on a patch (from memory) from: arun
* Have the linker script look more like the default linker scriptmarcel2003-07-171-46/+39
| | | | | on ia64. This fixes the breakage caused by the gcc upgrade that resulted in a broken executable.
* sys/ia64/ia64/pal.s has been repocopied to pal.S.ru2003-07-021-1/+1
| | | | | Approved by: marcel Repocopied by: joe
* Enable the i386 loader to load and run an amd64 kernel. If this putspeter2003-05-011-3/+3
| | | | | | | | | | | | | | | things over floppy size limits, I can exclude it for release builds or something like that. Most of the changes are to get the load_elf.c file into a seperate elf32_ or elf64_ namespace so that you can have two ELF loaders present at once. Note that for 64 bit kernels, it actually starts up the kernel already in 64 bit mode with paging enabled. This is really easy because we have a known minimum feature set. Of note is that for amd64, we have to pass in the bios int 15 0xe821 memory map because once in long mode, you absolutely cannot make VM86 calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader metadata startup, just like sparc64 and powerpc. Much of the infrastructure to support this was adapted from sparc64.
* Use __FBSDID rather than rcsid[].obrien2003-04-036-24/+12
|
* Paranoia: Don't use the length of the option string alone tomarcel2003-03-011-1/+1
| | | | | determine whether we have command line options. We expect a valid string pointer as well.
* Increase the block size for reading and writing from 8KB to 1MB andmarcel2003-02-261-4/+7
| | | | | | | introduce a preprocessor define for it. The larger block size significantly speeds up the loading of the kernel. Submitted by: Arun Sharma <arun.sharma@intel.com>
* Simplify page alignment.marcel2003-02-201-11/+4
|
* Pass the HCDP table address to the kernel. If no such table exists,marcel2002-12-102-0/+17
| | | | | | | | | | | | | 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)
* The exit() function has been moved to libefi.c to better deal withmarcel2002-12-101-39/+0
| | | | | | | cleaning up after ourselves. Approved by: re (blankoscheck) German corrections: Alexander (both :-)
* Change the startup code to fix a memory leak and to allow us tomarcel2002-12-102-2/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Remove _putchar, _puts and _puthex. These functions are unused.marcel2002-12-101-101/+2
| | | | Approved by: re (blanket)
OpenPOWER on IntegriCloud