summaryrefslogtreecommitdiffstats
path: root/sys/boot/i386/loader
Commit message (Collapse)AuthorAgeFilesLines
* Catch the EFI loader up to the latest ZFS Boot Environment Menu featuresallanjude2016-02-101-29/+0
| | | | | | | | | | | | | | | MFC: r294072 Move init_zfs_bootenv to sys/boot/zfs/zfs.c instead of having a copy in each loader MFC: r294073 Connect the ZFS boot environment menu to the UEFI loader MFC: r295357 Do not set vfs.root.mountfrom unnecessarily when initializing ZFS BE menu Approved by: re (marius) Relnotes: yes Sponsored by: ScaleEngine Inc.
* MFC r277215, r277291, r277418, r280953 and r280954:royger2016-01-201-0/+4
| | | | | | | | | loader: implement multiboot support for Xen Dom0 Note that only the subset of the multiboot specification needed in order to boot a Xen Dom0 is implemented. Sponsored by: Citrix Systems R&D
* MFC: r293001allanjude2016-01-131-0/+68
| | | | | | | | | | | | | | | | Introduce the ZFS Boot Environments menu to the loader menu MFC: r293414 Add ZFS Boot Environments menu to userboot MFC: r293454 Only call init_zfs_bootenv when the system is booted with ZFS MFC: r293612 Fix calling init_zfs_bootenv to early, resulting in empty ZFS BE menu Relnotes: yes Sponsored by: ScaleEngine Inc.
* MFC r286368: Remove guards around overwriting loader.rc and menu.rcdteske2016-01-071-6/+1
| | | | | | | | | | | | | There have been .local version of each for user modifications for some time This allows users to receive future updates to these files PR: 183765 Differential Revision: https://reviews.freebsd.org/D3176 Submitted by: Bertram Scharpf, Nikolai Lifanov (patch) Reviewed by: dteske, loos, eadler Approved by: bapt (mentor) Relnotes: yes Sponsored by: ScaleEngine Inc.
* MFC: r277949:allanjude2015-07-201-2/+3
| | | | | | | | | | | | | | | | | | | New function smbios_match to detect BIOS versions during boot MFC: r277957: Fix order of functions in smbios.c (corrects r277949) MFC: r281138: SMBIOS support for EFI r281138 makes changes to the new unified EFI loader (r280950), which has not been merged to stable/10 (and likely won't be). These changes were manually applied to the amd64 EFI loader (sys/boot/amd64/efi). The changes to sys/boot/amd64/efi are a direct commit. Reviewed by: stas Approved by: re (gjb), marcel Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D3129
* MFC revisions 277693,278335,280382-280385,280923-280926,280931,dteske2015-04-221-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 280933-280939,280974-280976,281002,281009,281081,281176-281180, 281271,281275,281616 (described in-breif below): r277693: Font fix (des) r278335: Revert that r280382: Whitespace, comments, and copyright update r280383: Prevent inadvertent bootlock condition r280384: Increase max passowrd length from 16 to 255 chars r280385: Add missing variable hints to loader.conf(5) defaults r280923: Whitespace r280924: Comments r280925: Optimize bootmsg to use fg/bg/me from screen.4th r280926: Whitespace and cleanup r280931: Comments r280933: Move beastie to logo-*.4th; brands to brand-*.4th r280934: Add remainder of supported ANSI escape sequences r280935: Securely overwrite (zero) user input after password checks r280936: Use equals for ASCII double frames r280937: Solve dreaded "dictionary full" issue r280938: Add "GELI Passphrase:" prompt to boot loader r280939: Revert that (premature commit) r280974: Use fg/b/me from screen.4th instead of literals r280975: Eliminate literal escape sequences from *.4th r280976: Use ^[[m mode-ending versus ^[[37m r281002: Install newly added brand-*.4th and logo-*.4th files (jkim) r281009: Revert .PATH changes to fix mips build (jkim) r281081: Make sure forth manpages are only installed once (bapt) r281176: Back to previous mode-endings based on feedback r281177: Back to previous mode-endings based on feedback r281178: Back to previous mode-endings based on feedback r281179: Back to previous mode-endings based on feedback r281180: Eliminate literal escape sequences from *.rc r281271: Fix a bootlock condition if loader_version is set NB: Commit message of r281271 has a typo, s/_logo/_version/ r281275: Re-do proper mode-endings r281616: Add "GELI Passphrase:" prompt to boot loader Relnotes: Added "GELI Passphrase:" prompt to boot loader
* MFC 274398,274537:jhb2015-01-301-7/+7
| | | | | Move NFS and TFTP filesystems before the synthetic filesystems (bzip, gzip, and split).
* MFC UEFI loaderemaste2014-09-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* r261567: Build a 32-bit libstand under sys/boot/emaste2014-09-041-0/+2
| | | | | | | | | | | | | | | | | | 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 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
* Hook in new files menusets.4th and manual.dteske2012-11-071-1/+1
| | | | Approved by: adrian (co-mentor) (implicit)
* zfs boot: export boot/primary pool and vdev guid all the way to kenvavg2012-10-061-1/+9
| | | | | | | This is work in progress to for znextboot and it also provides some convenient infrastructure. MFC after: 20 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.
* 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
* 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.
* 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".
* Remove unneeded flag.ae2012-08-051-3/+0
|
* Import work done under project/nand (@235533) into head.gber2012-05-172-0/+6
| | | | | | | | | | | | | | The NAND Flash environment consists of several distinct components: - NAND framework (drivers harness for NAND controllers and NAND chips) - NAND simulator (NANDsim) - NAND file system (NAND FS) - Companion tools and utilities - Documentation (manual pages) This work is still experimental. Please use with caution. Obtained from: Semihalf Supported by: FreeBSD Foundation, Juniper Networks
* zfsboot/zfsloader: support accessing filesystems within a poolavg2012-05-122-34/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In zfs loader zfs device name format now is "zfs:pool/fs", fully qualified file path is "zfs:pool/fs:/path/to/file" loader allows accessing files from various pools and filesystems as well as changing currdev to a different pool/filesystem. zfsboot accepts kernel/loader name in a format pool:fs:path/to/file or, as before, pool:path/to/file; in the latter case a default filesystem is used (pool root or bootfs). zfsboot passes guids of the selected pool and dataset to zfsloader to be used as its defaults. zfs support should be architecture independent and is provided in a separate library, but architectures wishing to use this zfs support still have to provide some glue code and their devdesc should be compatible with zfs_devdesc. arch_zfs_probe method is used to discover all disk devices that may be part of ZFS pool(s). libi386 unconditionally includes zfs support, but some zfs-specific functions are stubbed out as weak symbols. The strong definitions are provided in libzfsboot. This change mean that the size of i386_devspec becomes larger to match zfs_devspec. Backward-compatibility shims are provided for recently added sparc64 zfs boot support. Currently that architecture still works the old way and does not support the new features. TODO: - clear up pool root filesystem vs pool bootfs filesystem distinction - update sparc64 support - set vfs.root.mountfrom based on currdev (for zfs) Mid-future TODO: - loader sub-menu for selecting alternative boot environment Distant future TODO: - support accessing snapshots, using a snapshot as readonly root Reviewed by: marius (sparc64), Gavin Mu <gavin.mu@gmail.com> (sparc64) Tested by: Florian Wagner <florian@wagner-flo.net> (x86), marius (sparc64) No objections: fs@, hackers@ MFC after: 1 month
* r235154 followup: add stddef.h for offsetofavg2012-05-091-0/+1
| | | | MFC after: 1 month
* i386 zfsloader: rename LIBZFS to LIBZFSBOOTavg2012-05-091-5/+3
| | | | | | ... to avoid name clash with the other libzfs MFC after: 1 month
* btxldr: future-proof argument passing from boot1/2-ish to loaderavg2012-05-091-17/+6
| | | | | | | | | | | | | | | Place the arguments at a fixed offset of 0x800 withing the argument area (of size 0x1000). Allow variable size extended arguments first of which should be a size of the extended arguments (including the size parameter). Consolidate all related definitions in a new i386/common/bootargs.h header. Many thanks to jhb and bde for their guidance and reviews. Reviewed by: jhb, bde Approved by: jhb MFC after: 1 month
* - Whitespaces fixed onlymiwi2011-11-191-3/+3
| | | | Approved by: rwatson (mentor)
* New boot loader menus from Devin Teske.julian2011-05-281-0/+5
| | | | | | | | Discussed on hackers and recommended for inclusion into 9.0 at the devsummit. All support email to devin dteske at vicor dot ignoreme dot com . Submitted by: dteske at vicor dot ignoreme dot com Reviewed by: me and many others
* Remove support for autoloading ACPI from the loader. Leave in the code tojhb2010-11-081-18/+0
| | | | | detect ACPI and export info such as the location of the RSDP via hints as that is still useful.
* For consistency, change all 'i386' and MACHINE_ARCH to x86.delphij2010-08-311-1/+1
| | | | | Reviewed by: jhb MFC after: 1 week
* MF tbemd: Minor tweaks, prefer MACHINE_CPUARCH generally to MACHINE_ARCHimp2010-08-231-1/+1
|
* Correctly setup LDADD with regards to libstand. The submitter pointsrpaulo2010-07-221-1/+1
| | | | | | | | | | | | out that "on amd64, libstand.a is compiled for i386, but is still installed under ${WORLDTMP}/usr/lib instead of ${WORLDTMP}/usr/lib32. Even if it would be installed there, ld on amd64 is set up incorrectly with a ${TOOLS_PREFIX}/usr/lib/i386 default path, so it wouldn't link. The reason it does link under gcc is that gcc passes -L${WORLDTMP}/usr/lib twice, even for -m32 builds, which is also incorrect, but accidentally works in this case." Submitted by: Dimitry Andric <dimitry at andric.com>
* Improve the algorithm the loader uses to choose a memory range for itsjhb2009-12-071-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | heap when using a range above 1MB. Previously the loader would always use the last 3MB in the first memory range above 1MB for the heap. However, this memory range is also where the kernel and any modules are loaded. If this memory range is "small", then using the high 3MB for the heap may not leave enough room for the kernel and modules. Now the loader will use any range below 4GB for the heap, and the logic to choose the "high" heap region has moved into biosmem.c. It sets two variables that the loader can use for a high heap if it desires. When a high heap is enabled (BZIP2, FireWire, GPT, or ZFS), then the following memory ranges are preferred for the heap in order from best to worst: - The largest memory region in the SMAP with a start address greater than 1MB. The memory region must be at least 3MB in length. This leaves the region starting at 1MB purely for use by the kernel and modules. - The last 3MB of the memory region starting at 1MB if it is at least 3MB in size. This matches the current behavior except that the current loader would break horribly if the first region was not at least 3MB in size. - The memory range from the end of the loader up to the 640k window. This is the range the loader uses when none of the high-heap-requesting options are enabled. Tested by: hrs MFC after: 1 week
* Various small whitespace and style fixes.jhb2009-12-071-1/+2
|
* Add new loader console type: "spinconsole". This console selects thesobomax2009-11-271-0/+2
| | | | | | | | video console which doesn't take any input from keyboard and hides all output replacing it with ``spinning'' character (useful for embedded products and custom installations). Sponsored by: Sippy Software, Inc.
* Create a seperate ZFS enabled loader.rnoland2009-11-231-12/+18
| | | | | | | | | | | | | | | | | | | This adds zfsloader which will be called by zfsboot/gptzfsboot code rather than the tradional loader. This eliminates the need to set the LOADER_ZFS_SUPPORT variable in order to get a ZFS enabled loader. Note however, that you must reinstall your bootcode (zfsboot/gptzfsboot) in order for the boot process to use the new loader. New installations will no longer be required to build a ZFS enabled loader for a working ZFS boot system. Installing zfsboot/gptzfsboot is sufficient for acknowledging the use of CDDL code and therefore the ZFS enabled loader. Based on a previous patch from jhb@ Reviewed by: jhb@ MFC after: 2 weeks
* - Make it possible to disable GPT support by setting LOADER_NO_GPT_SUPPORTjhb2009-03-092-1/+4
| | | | | | | | | | | | in make.conf or src.conf. - When GPT is enabled (which it is by default), use memory above 1 MB and leave the memory from the end of the bss to the end of the 640k window purely for the stack. The loader has grown and now it is much more common for the heap and stack to grow into each other when both are located in the 640k window. PR: kern/129526 MFC after: 1 week
* Fix build when WITH_SSP is set explicitly.ru2009-02-211-2/+1
| | | | Submitted by: Jeremie Le Hen
* Fix building without ZFS (can't find library)ache2008-11-181-0/+2
|
* Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes.pjd2008-11-173-13/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bring huge amount of changes, I'll enumerate only user-visible changes: - Delegated Administration Allows regular users to perform ZFS operations, like file system creation, snapshot creation, etc. - L2ARC Level 2 cache for ZFS - allows to use additional disks for cache. Huge performance improvements mostly for random read of mostly static content. - slog Allow to use additional disks for ZFS Intent Log to speed up operations like fsync(2). - vfs.zfs.super_owner Allows regular users to perform privileged operations on files stored on ZFS file systems owned by him. Very careful with this one. - chflags(2) Not all the flags are supported. This still needs work. - ZFSBoot Support to boot off of ZFS pool. Not finished, AFAIK. Submitted by: dfr - Snapshot properties - New failure modes Before if write requested failed, system paniced. Now one can select from one of three failure modes: - panic - panic on write error - wait - wait for disk to reappear - continue - serve read requests if possible, block write requests - Refquota, refreservation properties Just quota and reservation properties, but don't count space consumed by children file systems, clones and snapshots. - Sparse volumes ZVOLs that don't reserve space in the pool. - External attributes Compatible with extattr(2). - NFSv4-ACLs Not sure about the status, might not be complete yet. Submitted by: trasz - Creation-time properties - Regression tests for zpool(8) command. Obtained from: OpenSolaris
* - Initialize the vm86 structure to a known-good state. Specifically, alwaysjhb2008-08-081-0/+5
| | | | | | | | | set the %eflags used during a BIOS call via BTX to 0x202. Previously the flags field was uninitialized garbage, and thus it was "random" if interrupts were enabled or not during BIOS calls. - Use constants from <machine/psl.h> for fields in %eflags. MFC after: 3 days
* 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>
* Slightly cleanup the 'bootdev' concept on x86 by changing the variousjhb2007-10-241-2/+1
| | | | | | | | macros to treat the 'slice' field as a real part of the bootdev instead of as hack that spans two other fields (adaptor (sic) and controller) that are not used in any modern FreeBSD boot code. MFC after: 1 week
* MFp4: add FireWire/dcons support in loader for i386/amd64.simokawa2007-05-293-3/+22
| | | | | | | | | | It is disabled by default. You need to put LOADER_FIREWIRE_SUPPORT=yes in /etc/make.conf and rebuild loader to enable it. (cd /sys/boot/i386 && make clean && make && make install) You can find a short introduction of dcons at http://wiki.freebsd.org/DebugWithDcons
* Remove an unused variable.ru2006-11-161-2/+1
|
* Extend struct devdesc with a unit field, called d_unit. Promote themarcel2006-11-021-4/+4
| | | | | | | | | 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.
* Don't unconditionally compile-in the bcache code. It's only used onmarcel2006-11-021-0/+3
| | | | | i386/amd64 and pc98. Remove useless calls to bcache_init() from the ia64 and sparc64 loaders, as well as from the OFW common code.
* Add an 'smap' command that dumps out the BIOS SMAP.jhb2006-09-281-0/+7
| | | | MFC after: 1 week
* Commit the results of the typo hunt by Darren Pilgrim.yar2006-08-041-1/+1
| | | | | | | | | | This change affects documentation and comments only, no real code involved. PR: misc/101245 Submitted by: Darren Pilgrim <darren pilgrim bitfreak org> Tested by: md5(1) MFC after: 1 week
* Reimplementation of world/kernel build options. For details, see:ru2006-03-171-1/+3
| | | | | | | | http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html The src.conf(5) manpage is to follow in a few days. Brought to you by: imp, jhb, kris, phk, ru (all bugs are mine)
OpenPOWER on IntegriCloud