summaryrefslogtreecommitdiffstats
path: root/sys/boot/i386
Commit message (Collapse)AuthorAgeFilesLines
* MFC r264400,r265836:ngie2014-12-319-9/+9
| | | | | | | | | | | | | | r264400: NO_MAN= has been deprecated in favor of MAN= for some time, go ahead and finish the job. ncurses is now the only Makefile in the tree that uses it since it wasn't a simple mechanical change, and will be addressed in a future commit. r265836: Remove last two NO_MAN= in the tree. In both of these cases, MAN= is what is needed.
* MFC: r268475 (by imp)nyan2014-11-031-7/+26
| | | | | | Make SERIAL support optional again. Enable it for i386 because a huge percentage of machines has a 16550. Disable it for pc98 since only a tiny fraction of them have one.
* MFC r271609: add gptzfsboot.8, zfsboot.8 and zfsloader.8 manual pagesavg2014-10-074-0/+328
|
* MFC r271475 by ambrisko:emaste2014-09-191-0/+8
| | | | | | Add support for serial and null console to UEFI boot loader. Approved by: re
* MFC UEFI loaderemaste2014-09-049-811/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 declarationemaste2014-09-042-46/+2
|
* r261567: Build a 32-bit libstand under sys/boot/emaste2014-09-045-0/+9
| | | | | | | | | | | | | | | | | | 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: r264482brueffer2014-04-231-1/+1
| | | | Re-indent break statement.
* MFC r258270:dteske2014-03-031-0/+1
| | | | | | | | | Add a try-include word (which acts the same as "include") and use it to conditionally include (but ignore failures) /boot/loader.rc.local and /boot/menu.rc.local -- to make customizing the menu easier. Reviewed by: alfred Discussed on: -hackers
* MFC r257650:dteske2014-03-031-1/+1
| | | | | | | | | | | Defer loading of kernel and modules if the beastie menu is enabled. Add a kernel selection menu to the beastie menu. List of kernels is taken from `kernels' in loader.conf(5) as a space (or comma) separated list of names to display (up to 9). If not set, default value is "kernel kernel.old". Does not validate that kernels exist because the next enhancement will be to allow selection of the root device. Discussed on: -current
* MFC 261517,261520:jhb2014-02-182-11/+19
| | | | | Convert the license on files where I am the sole copyright holder to 2 clause BSD licenses.
* MFC r261522:wblock2014-02-101-4/+11
| | | | | | | | Describe the use of a freebsd-boot GPT partition, brought up by Scot Hetzel <swhetzel@gmail.com> on the -doc mailing list. Also modify the Author section to be clear that I wrote the man page, not gptboot.
* MFC r260949:mav2014-02-071-4/+4
| | | | Make comconsole options set before its activation to be remembered.
* MFC r258779,r258780,r258787,r258822:eadler2014-02-042-4/+4
| | | | | | | | | | | | | Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this shifts into the sign bit. Instead use (1U << 31) which gets the expected result. Similar to the (1 << 31) case it is not defined to do (2 << 30). This fix is not ideal as it assumes a 32 bit int, but does fix the issue for most cases. A similar change was made in OpenBSD.
* MFC r260334:dim2014-01-094-4/+11
| | | | | | | | | | | | Split the last gcc-specific flags off into CFLAGS.gcc. This also removes the need to use -Qunused-arguments for clang throughout the tree. MFC r260369: Apply band-aid for 32-bit compat libs failures after r260334: put back -Qunused-arguments for clang for now, until I can figure out a way to make it unneeded in all scenarios. Sorry about the breakage.
* MFC r260095:dim2014-01-045-13/+14
| | | | | | | | | | For sys/boot/i386 and sys/boot/pc98, separate flags to be passed directly to the linker (LD_FLAGS) from flags passed indirectly, via the compiler driver (LDFLAGS). This is because several Makefiles under sys/boot/i386 and sys/boot/pc98 use ${LD} directly to link, and the normal LDFLAGS value should not be used in these cases.
* MFC r257532 (by adrian):dim2013-12-302-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this build for clang. MFC r259730: To avoid having to explicitly test COMPILER_TYPE for setting clang-specific or gcc-specific flags, introduce the following new variables for use in Makefiles: CFLAGS.clang CFLAGS.gcc CXXFLAGS.clang CXXFLAGS.gcc In bsd.sys.mk, these get appended to the regular CFLAGS or CXXFLAGS for the right compiler. MFC r259913: For libstand and sys/boot, split off gcc-only flags into CFLAGS.gcc. MFC r259927: Fix pc98 build, by also forcing COMPILER_TYPE in sys/boot/pc98/boot2's Makefile. Pointy hat to: dim
* MFC 256293:jhb2013-10-151-2/+5
| | | | | | | | | Sanitize the %eflags returned by BIOS routines. Some BIOS routines enter protected mode and may leave protected-mode-specific flags like PSL_NT set when they return to real mode. This can cause a fault when BTX re-enters protected mode after the BIOS mode returns. Approved by: re (gjb)
* Use MK_SSP=no after including bsd.own.mk to disable SSP instead of user-knobbdrewery2013-09-291-1/+1
| | | | | | | | | | | | | | | WITH[OUT]_SSP to avoid hitting an error if user has WITH_SSP in their make.conf. Ports now use this knob. make[7]: "/usr/src/share/mk/bsd.own.mk" line 466: WITH_SSP and WITHOUT_SSP can't both be set. This is similar to previous cleanup done in r188895 Approved by: bapt Reviewed by: jlh (earlier version) Approved by: re (marius) MFC after: 1 week
* Set the hint for physical address of RSDP in hexadecimal as before r223262.jkim2013-08-231-1/+1
|
* Add descriptions to the FILES list, fix some mdoc complaints, move thewblock2013-07-031-5/+7
| | | | | | | | "neither" entry out of the table in BOOTING. Submitted by: joeld Reviewed by: joeld MFC after: 1 week
* Add a new gptboot(8) man page. Factor out the redundant informationwblock2013-07-012-0/+237
| | | | | | | in gpart(8) and boot(8), adding references to gptboot(8) in both. Reviewed by: jhb, ae, pjd, Paul Schenkeveld <bsdcan@psconsult.nl>, david_a_bright@dell.com (portions), gjb MFC after: 1 week
* When rebooting (exiting) from the BTX loader, make sure to restore thedim2013-04-241-1/+1
| | | | | | | | | | | GDT from the correct segment, otherwise a triple fault would be caused. In some virtual environments (VMware, VirtualBox, etc) this could lead to a unhandled error or hang in the guest emulation software. Thanks to avg and jhb for a few hints in the right direction. Noticed by: Jeremy Chadwick <jdc@koitsu.org> (and many others) MFC after: 1 week
* Always update the hw.uart.console hint anytime a change is made to thejhb2013-01-231-18/+7
| | | | | | | | | | | comconsole setup. Previously the hint would be set when if you set a custom port, but it would not be updated if you later set a custom speed. Also, leave the hw.uart.console hint mutable so it can be overridden or unset by the user if needed. Reviewed by: kib (earlier version) MFC after: 1 week
* Fix linking of loader.efi.benno2013-01-221-1/+1
| | | | | | | | | gcc handles -symbolic by passing -Bsymbolic through to ld. clang ignores -symbolic and thus invokes ld without -Bsymbolic which leads to some symbols not being properly linked in loader.efi. Fix this by using -Wl,-Bsymbolic which passes -Bsymbolic to ld in both the gcc and clang cases. Approved by: rpaulo
* Quiesce some clang warnings while we're here doing stuff.sbruno2013-01-143-2/+9
| | | | | Submitted by: Hiren Panchasara <hiren.panchasara@gmail.com> Obtained from: Yahoo! Inc
* amd64 only has rela sections.rpaulo2012-12-171-12/+12
|
* Make this work for 64 bit binaries.rpaulo2012-12-071-9/+22
|
* Remove dead code that clang refuses to compile.rpaulo2012-12-051-10/+0
|
* boot: use packed attribute for edd_params* structures and their substructuresavg2012-11-141-5/+5
| | | | | | | | | | | | | | | | | | | | The sole purpose of this change is to make sure that sizeof produces "canonical" sizes for these structures. This is to avoid triggering bugs in the BIOSes that properly handle only the canonical values of input length provided to INT 13h AH=48h. The canonical sizes are: 30 for v2, 66 for v3, etc. Buggy BIOS code probably looks like: if (input_length > 30) { /* > v2 */ assume that input length is 66 /* assume v3 or later */ } This should fix boot problems at least on Supermicro X8DT6 and possibly on P410i Smart Array Controller (as found in e.g. HP DL360 G7). Reported by: gnn, np, rstone Debugged by: rstone Discussed with: ae, np, rstone MFC after: 4 days
* Shrink boot2 by 8 bytes, by eliminating some unneeded instructions indim2012-11-081-4/+2
| | | | | | | | sio.S. This is not particularly needed for head right now, but it is intended to merge to stable/9, to fix boot2 build with clang there. Reviewed by: avg MFC after: 3 days
* Hook in new files menusets.4th and manual.dteske2012-11-071-1/+1
| | | | Approved by: adrian (co-mentor) (implicit)
* Add the flags parameter to the disk_open() function and DISK_F_NOCACHEae2012-10-211-3/+7
| | | | | flag, that disables the caching of partition tables metadata. Use this flag for floppies in the libi386/biosdisk driver.
* boot: use -march=i386 for both i386 and amd64 buildsavg2012-10-201-2/+2
| | | | | | | | | | | | .. 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
* add detection of serial console presence to btx and boot2-like blocksavg2012-10-066-20/+35
| | | | | | | | Note that this commit slightly increases size of boot blocks. Reviewed by: jhb Tested by: Olivier Cochard-Labbe <olivier@cochard.me> MFC after: 26 days
* i386 comconsole: don't loop forever if hardware doesn't respondavg2012-10-061-14/+22
| | | | | | | | | | | - clear capability flags when hw timeouts - retire comc_started status variable and directly use c_flags to see if comconsole is selected for use Reviewed by: jhb Tested by: Uffe Jakobsen <uffe@uffe.org>, Olivier Cochard-Labbe <olivier@cochard.me> MFC after: 26 days
* zfsboot: simplify probe_drive() a little bitavg2012-10-061-27/+13
| | | | | | | | | | | The first discovered pool, whether it covers the whole boot disk or not, is going to be first in zfs_pools list. So there is no need at all for spapp parameter. This commit also fixes a bug where NULL would be assigned to NULL pointer when probe_drive was called with the spapp parameter of NULL. MFC after: 21 days
* zfs boot: export boot/primary pool and vdev guid all the way to kenvavg2012-10-062-2/+20
| | | | | | | This is work in progress to for znextboot and it also provides some convenient infrastructure. MFC after: 20 days
* zfsboot: use the same zfs dataset naming format as loaderavg2012-10-061-32/+53
| | | | | | | Also, pool name alone now names a root dataset of the pool regardless of bootfs property value. MFC after: 15 days
* zfs boot: add lszfs command to i386 loaderavg2012-10-061-0/+23
| | | | | | | ... to list child datasets of a specified dataset. Dataset name should be provided in poolname/dsname format. MFC after: 17 days
* Reduce the number of attempts to detect proper kld format for the amd64ae2012-09-302-0/+7
| | | | loader.
* Almost each time when loader opens a file, this leads to callingae2012-09-291-1/+9
| | | | | | | | | | | | | | | | | | disk_open(). Very often this is called several times for one file. This leads to reading partition table metadata for each call. To reduce the number of disk I/O we have a simple block cache, but it is very dumb and more than half of I/O operations related to reading metadata, misses this cache. Introduce new cache layer to resolve this problem. It is independent and doesn't need initialization like bcache, and will work by default for all loaders which use the new DISK API. A successful disk_open() call to each new disk or partition produces new entry in the cache. Even more, when disk was already open, now opening of any nested partitions does not require reading top level partition table. So, if without this cache, partition table metadata was read around 20-50 times during boot, now it reads only once. This affects the booting from GPT and MBR from the UFS.
* Disable splitfs support, since we aren't support floppies for a longae2012-09-291-0/+2
| | | | | time. This slightly reduces an overhead, when loader tries to open file that doesn't exist.
* loader/i386: replace ugly inb/outb re-implementations with cpufunc.havg2012-09-181-18/+4
| | | | | | | | Use of __builtin_constant_p in a function that is only called via a pointer is a good example of how out-of-date it was. Suggested by: bde MFC after: 1 week
* Make pxe device in lsdev really include device name, looking like this:mav2012-09-122-20/+4
| | | | | | pxe0: 192.168.3.1:/storage/nfsroot/amd64 , instead of confusing and less useful: 192.168.3.1:pxeboot
* a bit of trailing whitespace cleanupavg2012-09-111-7/+7
| | | | MFC after: 1 week
* Slightly reduce an overhead for the open() call in the zfsloader.ae2012-09-111-3/+3
| | | | | | libstand(3) tries to detect file system in the predefined order, but zfsloader usually is used for the booting from ZFS, and there is no need to try detect several file system types for each open() call.
* After r239066, reinitialize v86.ctl and v86.addr for int 13 EDD probingdim2012-08-131-0/+2
| | | | | | in sys/boot/i386/libi386/biosdisk.c. Otherwise, when DISK_DEBUG is enabled, the DEBUG() macros will clobber those fields, and cause the probing to always fail mysteriously when debugging is enabled.
* Add another debug message.ae2012-08-121-0/+2
|
* Teach the ZFS use new partitions API when probing.ae2012-08-051-13/+5
| | | | | Note: now ZFS does probe only for partitions with type "freebsd-zfs" and "freebsd".
OpenPOWER on IntegriCloud