summaryrefslogtreecommitdiffstats
path: root/sys/boot/efi
Commit message (Collapse)AuthorAgeFilesLines
* Allow EFI and ACPI to be included together. When ACPI is includedimp2015-02-203-0/+10
| | | | | | | | 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
* EFI: print more information about EFI Tables.rpaulo2015-02-051-20/+32
| | | | | This adds the GUIDs for DXE, HOB, Memory Type Information and Debug Image Info.
* Fix UEFI PXE boot on a NIC that isn't the first NIC.ambrisko2015-01-301-1/+4
| | | | | | | | | | | | | | | In UEFI it appears all available NICS are present to pass network traffic. This gives the capability to load the loader.efi from disk then set currdev="net3:" and then all I/O will over over the 2nd NIC. On this machine is appears the first handle is the first NIC in IPv4 mode and then the 2nd handle is the first NIC in IPv6 mode. The 3rd handle is the 2nd NIC in IPv4 mode. The fix is to index into the handle based on the unit cached from boot device passed into the loader. Some testing info from a test boot via kenv: currdev="net3:" loaddev="net3:" boot.netif.name="igb1"
* Add the FDT table GUID. This is used to pass the device tree blob from UEFIandrew2014-11-121-0/+2
| | | | | | | | 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
* Remove duplicated header contentemaste2014-09-251-119/+0
| | | | | | I fail at patch(1). MFC after: 3 days
* Switch to text mode in UEFI bootemaste2014-09-182-0/+263
| | | | | | | The loader previously failed to display on MacBooks and other systems where the UEFI firmware remained in graphics mode. Submitted by: Rafael Espíndola
* Add support for serial and null console to UEFI boot loader.ambrisko2014-09-121-0/+4
|
* Supress clang warning for FreeBSD printf %b and %D formatssbruno2014-07-221-0/+4
| | | | MFC after: 2 weeks
* Remove ia64.marcel2014-07-075-862/+0
| | | | | | | | | | | | | | | | | 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
* Add explicit casts to quiet warnings in libefiemaste2014-04-081-4/+6
| | | | Sponsored by: The FreeBSD Foundation
* Support UEFI booting on amd64 via loader.efiemaste2014-04-042-0/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add -fPIC for amd64emaste2014-04-031-0/+3
| | | | Sponsored by: The FreeBSD Foundation
* Merge efilib changes from projects/uefiemaste2014-04-034-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add amd64 EFI headersemaste2014-03-133-1/+860
| | | | Sponsored by: The FreeBSD Foundation
* Don't force efi to a 32-bit build on amd64emaste2014-02-071-8/+1
| | | | Sponsored by: The FreeBSD Foundation
* Typo in a comment.rpaulo2012-12-071-1/+1
|
* boot: use -march=i386 for both i386 and amd64 buildsavg2012-10-201-1/+5
| | | | | | | | | | | | .. so that consistent compilation algorithms are used for both architectures as in practice the binaries are expected to be interchangeable (for time being). Previously i386 used default setting which were equivalent to -march=i486 -mtune=generic. The only difference is using smaller but slower "leave" instructions. Discussed with: jhb, dim MFC after: 29 days
* Build a 32-bit EFI loader on amd64. This to match the rest of themarcel2012-04-201-0/+7
| | | | | | | | | code that is used to construct a loader (e.g. libstand, ficl, etc). There is such a thing as a 64-bit EFI application, but it's not as standard as 32-bit is. Let's make the 32-bit functional (as in we can load and actualy boot a kernel) before solving the 64-bit loader problem.
* 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-094-446/+268
| | | | | | | | | | | | | | | | | | | | | | | 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
* Enable GCC stack protection (aka Propolice) for userland:ru2008-06-251-0/+2
| | | | | | | | | | | | | | | | | | | | | - It is opt-out for now so as to give it maximum testing, but it may be turned opt-in for stable branches depending on the consensus. You can turn it off with WITHOUT_SSP. - WITHOUT_SSP was previously used to disable the build of GNU libssp. It is harmless to steal the knob as SSP symbols have been provided by libc for a long time, GNU libssp should not have been much used. - SSP is disabled in a few corners such as system bootstrap programs (sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves. - It should be safe to use -fstack-protector-all to build world, however libc will be automatically downgraded to -fstack-protector because it breaks rtld otherwise. - This option is unavailable on ia64. Enable GCC stack protection (aka Propolice) for kernel: - It is opt-out for now so as to give it maximum testing. - Do not compile your kernel with -fstack-protector-all, it won't work. Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
* Major rework of the ia64 loaders. The two primary objectives are:marcel2006-11-0514-1318/+530
| | | | | | | | | | | | | | 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.
* Sync the EFI headers with version 1.10.14.62 of the Intel sample EFImarcel2006-11-0220-647/+1255
| | | | | implementation. This re-introduces C99 style comments that previously were replaced by original C comments.
* 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.
* Don't try to use 'typedef struct foo' if just 'struct foo' makes more sensestefanf2005-03-072-25/+1
| | | | | | | 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
* Fix typos in a comment.stefanf2005-03-061-1/+1
|
* netchild's mega-patch to isolate compiler dependencies into a centraljoerg2005-03-021-3/+1
| | | | | | | | | | | | | | | | 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
* Start each of the license/copyright comments with /*-imp2005-01-053-2/+5
|
* 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-283-32/+21
| | | | | 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-236-1127/+0
|
* Unhook the loader subdirectory. The ia64 EFI loader is now buildmarcel2004-11-231-1/+1
| | | | under ../ia64/efi.
* Remove struct ia64_itir and use a plain old uint64_t instead.marcel2004-11-211-3/+4
|
* 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-232-33/+21
| | | | | bit-fields. Unify the PTE defines accordingly and update all uses.
* Catch up with change to <machine/pte.h>.marcel2004-08-101-9/+8
|
* 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-202-3/+3
| | | | | | | | | 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.
* Don't create a mapfile during link. It's not needed for the build.marcel2004-02-131-2/+2
|
* 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-123-83/+27
| | | | Tested by: marcel
OpenPOWER on IntegriCloud