MFC r272105: Remove duplicated header content

2014-09-30T13:56:32Z

Approved by: re (gjb, kib)

MFC r271762: Switch to text mode in UEFI boot

2014-09-22T19:56:21Z

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:

2014-09-19T21:30:45Z

Add support for serial and null console to UEFI boot loader. Approved by: re

MFC boot1.efi stub loader

2014-09-04T21:05:04Z

r264391 (nwhitehorn): Add a simple EFI stub loader. This is a quick and dirty of boot1.chrp from the PowerPC port with all the Open Firmware bits removed and replaced by their EFI counterparts. On the whole, I think I prefer Open Firmware. This code is supposed to be an immutable shim that sits on the EFI system partition, loads /boot/loader.efi from UFS and tells the real loader what disk/partition to look at. It finds the UFS root partition by the somewhat braindead approach of picking the first UFS partition it can find. Better approaches are called for, but this works for now. This shim loader will also be useful for secure boot in the future, which will require some rearchitecture. r264403 (nwhitehorn): Fix buildworld. I had some local bits in my build tree that caused this to work by accident. r264404 (nwhitehorn): Add my copyright here. Most of this is unmodified from the original sparc64 version, but at least some indication of changes that postdate the actual invention of EFI is probably a good idea. r264414 (nwhitehorn): Apparently some of the i386 boot blocks are so close to full that adding single lines to ufsread.c spills them over. Duplicate a whole bunch of code to get file sizes into boot1.efi/boot1.c rather than modifying ufsread.c. r264975 (nwhitehorn): Add generation of an EFI filesystem to hold boot1.efi. This is a near- exact copy of the code from boot1.chrp again. The resulting image is installed to /boot/boot1.efifat. If dd'ed to an 800K "efi" partition, it should result in a bootable system. r268975 (sbruno): Remove boot1.efi during clean target. Relnotes: Yes Sponsored by: The FreeBSD Foundation

MFC UEFI loader

2014-09-04T21:01:10Z

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

MFC r263005 by royger: howto_names: unify declaration

2014-09-04T20:47:14Z

MFC libstand32 clean target fixes

2014-09-04T20:44:41Z

r269029 (sbruno): Update so that clean target in sys/boot will delete the symlink created for machine r269036 (sbruno): Delete the entire cleandepend/cleanmachine target thing now that its been cleared out in r269029

r261567: Build a 32-bit libstand under sys/boot/

2014-09-04T20:35:53Z

A 32-bit libstand is needed on 64-bit platforms for use by various bootloaders. Previously only the 32-bit version was built, installed as /usr/lib/libstand.a. A new 64-bit libstand consumer will arrive in the near future, so move the bootloader-specific 32-bit version to sys/boot/libstand32/. Explicitly link against this version in the 32-bit loaders. r261614: Build a 32-bit libstand under sys/boot/ for ppc64 This change is equivalent to r261567 for i386/amd64. Relnotes: Yes Sponsored by: The FreeBSD Foundation

MFC r270445:

2014-09-01T07:34:16Z

The size of the GPT table can not be less than one sector. MFC r270521: Since the size of GPT entry may differ from the sizeof(struct gpt_ent), use the size from GPT header to iterate entries.

MFC r267021:

2014-08-20T19:37:05Z

FreeBSD, historically, has always used 8-bit addresses for i2c devices (7-bit device address << 1), always leaving the room for the read/write bit. This commit convert ti_i2c and revert r259127 on bcm2835_bsc to make them compatible with 8-bit addresses. Previous to this commit an i2c device would have different addresses depending on the controller it was attached to (by example, when compared to any iicbb(4) based i2c controller), which was a pretty annoying behavior. Also, update the PMIC i2c address on beaglebone* DTS files to match the new address scheme. Now the userland utilities need to do the correct slave address shifting (but it is going to work with any i2c controller on the system). Discussed with: ian MFC r267834: Clarify the expected usage of I2C 7-bit slave addresses on ioctl(2) interface. While here add the cross reference to iic(4) on iicbus(4). CR: D210 Suggested by: jmg

src/sys/boot, branch release/10.1.0