d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
4914ee11ae
freebsd-dev/stand/i386/loader/conf.c

171 lines
4.3 KiB
C
Raw Normal View History

This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
/*-
* Copyright (c) 1998 Michael Smith <msmith@freebsd.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
Use __FBSDID(). Also some minor copyright style cleanups.
2003-08-25 23:28:32 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
#include <stand.h>
#include <bootstrap.h>
#include "libi386/libi386.h"
zfsboot/zfsloader: support accessing filesystems within a pool 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
2012-05-12 09:03:30 +00:00
#if defined(LOADER_ZFS_SUPPORT)
Stop using ../zfs/libzfs.h but instead use libzfs.h. While ../zfs/libzfs.h mostly works, there are a few situations where it does not. Eliminate the problem by using plain libzfs.h, like we do for ufs support. This fixes the weird cases, and is easier to understand. It also follows the general style convetion of avoiding ../ in #includes.
2018-07-08 07:42:58 +00:00
#include "libzfs.h"
zfsboot/zfsloader: support accessing filesystems within a pool 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
2012-05-12 09:03:30 +00:00
#endif
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
/*
* We could use linker sets for some or all of these, but
* then we would have to control what ended up linked into
* the bootstrap. So it's easier to conditionalise things
* here.
*
* XXX rename these arrays to be consistent and less namespace-hostile
*
* XXX as libi386 and biosboot merge, some of these can become linker sets.
*/
MFp4: add FireWire/dcons support in loader for i386/amd64. 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
2007-05-29 14:35:57 +00:00
#if defined(LOADER_FIREWIRE_SUPPORT)
extern struct devsw fwohci;
#endif
loader: implement map-vdisk and unmap-vdisk commands illumos update: https://www.illumos.org/issues/10598 Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. This will allow to use disk image from file system to load and start the kernel. By mapping file, we create vdiskX device, the device will be listed by lsdev [-v] and can be accessed directly as ls vdisk0p1:/path or can be used as value for currdev variable. vdisk strategy function does not use bcache as we have bcache used with backing file. vdisk can be unmapped when all consumers have closed the open files. In first iteration we do not support the zfs images because zfs pools do keep the device open (there is no "zpool export" mechanism). Adding zfs support is relatively simple, we just need to run zfs disk probe after mapping is done. Differential Revision: https://reviews.freebsd.org/D19733
2019-04-26 17:58:44 +00:00
extern struct devsw vdisk_dev;
MFp4: add FireWire/dcons support in loader for i386/amd64. 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
2007-05-29 14:35:57 +00:00
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
/* Exported for libstand */
struct devsw *devsw[] = {
loader: create separate lists for fd, cd and hd, merge bioscd with biosdisk Create unified block IO implementation in BIOS version, like it is done in UEFI side. Implement fd, disk and cd device lists, this will split floppy devices from disks and will allow us to have consistent, predictable device naming (modulo BIOS issues). Differential Revision: https://reviews.freebsd.org/D17888
2018-11-30 08:01:11 +00:00
&biosfd,
Hook up the bioscd driver and the cd9660 filesystem.
2001-11-05 18:59:13 +00:00
&bioscd,
loader: create separate lists for fd, cd and hd, merge bioscd with biosdisk Create unified block IO implementation in BIOS version, like it is done in UEFI side. Implement fd, disk and cd device lists, this will split floppy devices from disks and will allow us to have consistent, predictable device naming (modulo BIOS issues). Differential Revision: https://reviews.freebsd.org/D17888
2018-11-30 08:01:11 +00:00
&bioshd,
Make PXE use the UDP API. This allows for both TFTP and NFS support. You may specify TFTP or NFS via compile time options in the loader, but not both at this time. Also, remove a warning about not knowing how to boot from network devices. We can obviously do that now.
2000-04-08 01:22:14 +00:00
#if defined(LOADER_NFS_SUPPORT) || defined(LOADER_TFTP_SUPPORT)
Mega i386 loader commit. - Don't hard code 0x10000 as the entry point for the loader. Instead add src/sys/boot/i386/Makefile.inc which defines a make variable with the entry point for the loader. Move the loader's entry point up to 0x20000, which makes PXE happy. - Don't try to use cpp to parse btxldr for the optional BTXLDR_VERBOSE, instead use m4 to achieve this. Also, add a BTXLDR_VERBOSE knob in the btxldr Makefile to turn this option on. - Redo parts of cdldr's Makefile so that it now builds and installs cdboot instead of having i386/loader/Makefile do that. Also, add in some more variables to make the pxeldr Makefile almost identical and thus to ease maintainability. - Teach cdldr about the a.out format. Cdldr now parsers the a.out header of the loader binary and relocates it based on that. The entry point of the loader no longer has to be hardcoded into cdldr. Also, the boot info table from mkisofs is no longer required to get a useful cdboot. - Update the lsdev function for BIOS disks to parse other file systems (such as DOS FAT) that we currently support. This is still buggy as it assumes that a floppy with a DOS boot sector actually has a MBR and parses it as such. I'll be fixing this in the future. - The biggie: Add in support for booting off of PXE-enabled network adapters. Currently, we use the TFTP API provided by the PXE BIOS. Eventually we will switch to using the low-level NIC driver thus allowing both TFTP and NFS to be used, but for now it's just TFTP. Submitted by: ps, alfred Testing by: Benno Rice <benno@netizen.com.au>
2000-03-28 01:19:53 +00:00
&pxedisk,
MFp4: add FireWire/dcons support in loader for i386/amd64. 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
2007-05-29 14:35:57 +00:00
#endif
#if defined(LOADER_FIREWIRE_SUPPORT)
&fwohci,
Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. 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
2008-11-17 20:49:29 +00:00
#endif
loader: implement map-vdisk and unmap-vdisk commands illumos update: https://www.illumos.org/issues/10598 Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. This will allow to use disk image from file system to load and start the kernel. By mapping file, we create vdiskX device, the device will be listed by lsdev [-v] and can be accessed directly as ls vdisk0p1:/path or can be used as value for currdev variable. vdisk strategy function does not use bcache as we have bcache used with backing file. vdisk can be unmapped when all consumers have closed the open files. In first iteration we do not support the zfs images because zfs pools do keep the device open (there is no "zpool export" mechanism). Adding zfs support is relatively simple, we just need to run zfs disk probe after mapping is done. Differential Revision: https://reviews.freebsd.org/D19733
2019-04-26 17:58:44 +00:00
&vdisk_dev,
Update ZFS from version 6 to 13 and bring some FreeBSD-specific changes. 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
2008-11-17 20:49:29 +00:00
#if defined(LOADER_ZFS_SUPPORT)
&zfs_dev,
Make PXE use the UDP API. This allows for both TFTP and NFS support. You may specify TFTP or NFS via compile time options in the loader, but not both at this time. Also, remove a warning about not knowing how to boot from network devices. We can obviously do that now.
2000-04-08 01:22:14 +00:00
#endif
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
NULL
};
struct fs_ops *file_system[] = {
Slightly reduce an overhead for the open() call in the zfsloader. 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.
2012-09-11 04:54:44 +00:00
#if defined(LOADER_ZFS_SUPPORT)
&zfs_fsops,
#endif
Honor settings for including / excluding cd9660, ufs, ext2fs and msdos. The Makefile gives the impression that ext2fs and msdos were excluded (they weren't) and that you could exclude cd9660 and ufs support (you couldn't). Allow those to be excluded. We need to look, in the future, at trimming the number of supported filesystems, and this will make that easier.
2018-02-21 15:58:00 +00:00
#if defined(LOADER_UFS_SUPPORT)
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
&ufs_fsops,
Honor settings for including / excluding cd9660, ufs, ext2fs and msdos. The Makefile gives the impression that ext2fs and msdos were excluded (they weren't) and that you could exclude cd9660 and ufs support (you couldn't). Allow those to be excluded. We need to look, in the future, at trimming the number of supported filesystems, and this will make that easier.
2018-02-21 15:58:00 +00:00
#endif
#if defined(LOADER_EXT2FS_SUPPORT)
Teach the loader about the ext2fs filesystem, extended partitions, and the new readdir function.
2000-04-29 20:49:33 +00:00
&ext2fs_fsops,
Honor settings for including / excluding cd9660, ufs, ext2fs and msdos. The Makefile gives the impression that ext2fs and msdos were excluded (they weren't) and that you could exclude cd9660 and ufs support (you couldn't). Allow those to be excluded. We need to look, in the future, at trimming the number of supported filesystems, and this will make that easier.
2018-02-21 15:58:00 +00:00
#endif
#if defined(LOADER_MSDOS_SUPPORT)
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
&dosfs_fsops,
Honor settings for including / excluding cd9660, ufs, ext2fs and msdos. The Makefile gives the impression that ext2fs and msdos were excluded (they weren't) and that you could exclude cd9660 and ufs support (you couldn't). Allow those to be excluded. We need to look, in the future, at trimming the number of supported filesystems, and this will make that easier.
2018-02-21 15:58:00 +00:00
#endif
#if defined(LOADER_CD9660_SUPPORT)
Hook up the bioscd driver and the cd9660 filesystem.
2001-11-05 18:59:13 +00:00
&cd9660_fsops,
Honor settings for including / excluding cd9660, ufs, ext2fs and msdos. The Makefile gives the impression that ext2fs and msdos were excluded (they weren't) and that you could exclude cd9660 and ufs support (you couldn't). Allow those to be excluded. We need to look, in the future, at trimming the number of supported filesystems, and this will make that easier.
2018-02-21 15:58:00 +00:00
#endif
Import work done under project/nand (@235533) into head. 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
2012-05-17 10:11:18 +00:00
#if defined(LOADER_NANDFS_SUPPORT)
&nandfs_fsops,
#endif
Move NFS and TFTP filesystems before the synthetic filesystems (bzip, gzip, and split). "Real" filesystems should always be listed first so that the "bare" filename is tried before alternate filenames. For PXE booting in particular this can remove a lot of spurious pathname lookups. While here, move splitfs to the bottom after the bzip and gzip filesystems as it is the least often used. Tested by: Prokash Sinha <psinha@panasas.com> MFC after: 1 week
2014-11-11 19:44:59 +00:00
#ifdef LOADER_NFS_SUPPORT
&nfs_fsops,
#endif
#ifdef LOADER_TFTP_SUPPORT
&tftp_fsops,
Disable splitfs support, since we aren't support floppies for a long time. This slightly reduces an overhead, when loader tries to open file that doesn't exist.
2012-09-29 15:08:55 +00:00
#endif
Add support for loading bzip2-compressed kernels and modules. This support is turned off by default and could be enabled by defining LOADER_BZIP2_SUPPORT make variable. Also make gzip support optional (turned on by default) - it could be turned off via LOADER_NO_GZIP_SUPPORT make variable. Please note, that due to limit on the amount of memory available to the loader(8), it is possible to load modules/kernels compressed with the smallest block size supported by the bzip2 - 100k (`-1' bzip2(1) option), however even in this mode bzip2(1) usually provides better compression ratio than gzip(1) in its best compression mode. MFC after: 1 month
2001-09-18 14:52:36 +00:00
#ifdef LOADER_GZIP_SUPPORT
Renamed the loader's zipfs to gzipfs. zipfs.c was repo-copied to gzipfs.c.
2002-12-19 19:34:59 +00:00
&gzipfs_fsops,
Add support for loading bzip2-compressed kernels and modules. This support is turned off by default and could be enabled by defining LOADER_BZIP2_SUPPORT make variable. Also make gzip support optional (turned on by default) - it could be turned off via LOADER_NO_GZIP_SUPPORT make variable. Please note, that due to limit on the amount of memory available to the loader(8), it is possible to load modules/kernels compressed with the smallest block size supported by the bzip2 - 100k (`-1' bzip2(1) option), however even in this mode bzip2(1) usually provides better compression ratio than gzip(1) in its best compression mode. MFC after: 1 month
2001-09-18 14:52:36 +00:00
#endif
#ifdef LOADER_BZIP2_SUPPORT
&bzipfs_fsops,
#endif
Move NFS and TFTP filesystems before the synthetic filesystems (bzip, gzip, and split). "Real" filesystems should always be listed first so that the "bare" filename is tried before alternate filenames. For PXE booting in particular this can remove a lot of spurious pathname lookups. While here, move splitfs to the bottom after the bzip and gzip filesystems as it is the least often used. Tested by: Prokash Sinha <psinha@panasas.com> MFC after: 1 week
2014-11-11 19:44:59 +00:00
#ifdef LOADER_SPLIT_SUPPORT
&splitfs_fsops,
Make PXE use the UDP API. This allows for both TFTP and NFS support. You may specify TFTP or NFS via compile time options in the loader, but not both at this time. Also, remove a warning about not knowing how to boot from network devices. We can obviously do that now.
2000-04-08 01:22:14 +00:00
#endif
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
NULL
};
/* Exported for i386 only */
/*
* Sort formats so that those that can detect based on arguments
* rather than reading the file go first.
*/
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
extern struct file_format i386_elf;
Add the loader side of support for preloading ELF relocatable object format modules, which are currently only used on the amd64 platform. This initial implementation just parses enough of the module to allow it to extract dependencies and load all the bits into the right place in memory, so the kernel must still do the full relocation and linking. The details of the loaded sections are passed to the kernel by supplying a copy of the ELF section header table as module metadata with the MODINFOMD_SHDR tag.
2004-08-29 00:48:42 +00:00
extern struct file_format i386_elf_obj;
Enable the i386 loader to load and run an amd64 kernel. If this puts 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.
2003-05-01 03:56:30 +00:00
extern struct file_format amd64_elf;
Add the loader side of support for preloading ELF relocatable object format modules, which are currently only used on the amd64 platform. This initial implementation just parses enough of the module to allow it to extract dependencies and load all the bits into the right place in memory, so the kernel must still do the full relocation and linking. The details of the loaded sections are passed to the kernel by supplying a copy of the ELF section header table as module metadata with the MODINFOMD_SHDR tag.
2004-08-29 00:48:42 +00:00
extern struct file_format amd64_elf_obj;
loader: implement multiboot support for Xen Dom0 Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
extern struct file_format multiboot;
extern struct file_format multiboot_obj;
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
Update loader logic to distinguish modules vs. files. Add support for module metadata. The old way of dependancy handling will be supported for a while. Reviewed by: peter
2000-05-01 17:41:25 +00:00
struct file_format *file_formats[] = {
loader: implement multiboot support for Xen Dom0 Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
&multiboot,
&multiboot_obj,
Reduce the number of attempts to detect proper kld format for the amd64 loader.
2012-09-30 12:24:15 +00:00
#ifdef LOADER_PREFER_AMD64
&amd64_elf,
&amd64_elf_obj,
#endif
Turn on i386-elf
1998-09-30 19:48:42 +00:00
&i386_elf,
Add the loader side of support for preloading ELF relocatable object format modules, which are currently only used on the amd64 platform. This initial implementation just parses enough of the module to allow it to extract dependencies and load all the bits into the right place in memory, so the kernel must still do the full relocation and linking. The details of the loaded sections are passed to the kernel by supplying a copy of the ELF section header table as module metadata with the MODINFOMD_SHDR tag.
2004-08-29 00:48:42 +00:00
&i386_elf_obj,
Reduce the number of attempts to detect proper kld format for the amd64 loader.
2012-09-30 12:24:15 +00:00
#ifndef LOADER_PREFER_AMD64
Enable the i386 loader to load and run an amd64 kernel. If this puts 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.
2003-05-01 03:56:30 +00:00
&amd64_elf,
Add the loader side of support for preloading ELF relocatable object format modules, which are currently only used on the amd64 platform. This initial implementation just parses enough of the module to allow it to extract dependencies and load all the bits into the right place in memory, so the kernel must still do the full relocation and linking. The details of the loaded sections are passed to the kernel by supplying a copy of the ELF section header table as module metadata with the MODINFOMD_SHDR tag.
2004-08-29 00:48:42 +00:00
&amd64_elf_obj,
Reduce the number of attempts to detect proper kld format for the amd64 loader.
2012-09-30 12:24:15 +00:00
#endif
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
NULL
};
/*
* Consoles
*
* We don't prototype these in libi386.h because they require
* data structures from bootstrap.h as well.
*/
extern struct console vidconsole;
extern struct console comconsole;
MFp4: add FireWire/dcons support in loader for i386/amd64. 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
2007-05-29 14:35:57 +00:00
#if defined(LOADER_FIREWIRE_SUPPORT)
extern struct console dconsole;
#endif
Add support for the "nullconsole" console type, for systems with neither a video console nor a serial port. Use it if the RB_MUTE flag is set. Submitted by: Doug Ambrisko <ambrisko@whistle.com> Reviewed by: jhb
2000-09-20 18:13:36 +00:00
extern struct console nullconsole;
Add new loader console type: "spinconsole". This console selects the 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.
2009-11-27 03:55:42 +00:00
extern struct console spinconsole;
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
struct console *consoles[] = {
&vidconsole,
&comconsole,
MFp4: add FireWire/dcons support in loader for i386/amd64. 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
2007-05-29 14:35:57 +00:00
#if defined(LOADER_FIREWIRE_SUPPORT)
&dconsole,
#endif
Add support for the "nullconsole" console type, for systems with neither a video console nor a serial port. Use it if the RB_MUTE flag is set. Submitted by: Doug Ambrisko <ambrisko@whistle.com> Reviewed by: jhb
2000-09-20 18:13:36 +00:00
&nullconsole,
Add new loader console type: "spinconsole". This console selects the 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.
2009-11-27 03:55:42 +00:00
&spinconsole,
This is the new unified bootstrap, sometimes known previously as the 'three-stage' bootstrap. There are a number of caveats with the code in its current state: - The i386 bootstrap only supports booting from a floppy. - The kernel and kld do not yet know how to deal with the extended information and module summary passed in. - PnP-based autodetection and demand loading of modules is not implemented. - i386 ELF kernel loading is not ready yet. - The i386 bootstrap is loaded via an ugly blockmap. On the alpha, both net- and disk-booting (SRM console machines only) is supported. No blockmaps are used by this code. Obtained from: Parts from the NetBSD/i386 standalone bootstrap.
1998-08-21 03:17:42 +00:00
NULL
};
Resynch with working sources before BTX integration. - Use format-independant module allocator. - Conditionalise ISA PnP support. - Simplify PnP enumerator interface. - Improve module/object searching. - Add missing depend/install targets in BTX makefiles. - Pass the kernel environment and module data in extended bootinfo fields. - Add a pointer to the end of the kernel + modules in bootinfo. - Fix parsing of old-style kernel arguments.
1998-09-14 18:27:06 +00:00
extern struct pnphandler isapnphandler;
Add a dependancy on the BTX crt0 object Add the biospnp handler to the pnp handler array Drop some old debugging code
1998-10-22 20:23:58 +00:00
extern struct pnphandler biospnphandler;
Enable the PCI BIOS PnP enumerator.
1998-10-23 22:29:19 +00:00
extern struct pnphandler biospcihandler;
Resynch with working sources before BTX integration. - Use format-independant module allocator. - Conditionalise ISA PnP support. - Simplify PnP enumerator interface. - Improve module/object searching. - Add missing depend/install targets in BTX makefiles. - Pass the kernel environment and module data in extended bootinfo fields. - Add a pointer to the end of the kernel + modules in bootinfo. - Fix parsing of old-style kernel arguments.
1998-09-14 18:27:06 +00:00
struct pnphandler *pnphandlers[] = {
Add a dependancy on the BTX crt0 object Add the biospnp handler to the pnp handler array Drop some old debugging code
1998-10-22 20:23:58 +00:00
&biospnphandler, /* should go first, as it may set isapnp_readport */
- Enable PnP and ISA PnP code. - Use the ISA PnP enumerator. - Use the new linker set code, throw out the gensetdefs stuff. - Produce an intermediate loader image that has symbols stripped, to aid - in debugging. - Supply ISA port access functions required for ISA PnP
1998-10-21 20:10:33 +00:00
&isapnphandler,
Enable the PCI BIOS PnP enumerator.
1998-10-23 22:29:19 +00:00
&biospcihandler,
Resynch with working sources before BTX integration. - Use format-independant module allocator. - Conditionalise ISA PnP support. - Simplify PnP enumerator interface. - Improve module/object searching. - Add missing depend/install targets in BTX makefiles. - Pass the kernel environment and module data in extended bootinfo fields. - Add a pointer to the end of the kernel + modules in bootinfo. - Fix parsing of old-style kernel arguments.
1998-09-14 18:27:06 +00:00
NULL
};
Reference in New Issue Copy Permalink