CD Actual 13

home *** CD-ROM | disk | FTP | other *** search

/ CD Actual 13 / CDA13.ISO / DOC / HOWTO / OTHER_FO / SGML / BOOTPROM.GZ / BootPrompt-HOWTO.sgml

Wrap

SGML Document | 1996-07-14 | 71.8 KB | 2,009 lines

<!doctype linuxdoc system> <article> <title>The Linux BootPrompt-HowTo <author>Paul Gortmaker, Editor. <date>v1.11, 1 July 1996 <abstract> This is the BootPrompt-Howto, which is a compilation of all the possible boot time arguments that can be passed to the Linux kernel at boot time. This includes all kernel and device parameters. A discussion of how the kernel sorts boot time arguments, along with an overview of some of the popular software used to boot Linux kernels is also included. </abstract> <toc> <sect>Introduction<label id="main-intro"> The kernel has a limited capability to accept information at boot in the form of a `command line', similar to an argument list you would give to a program. In general this is used to supply the kernel with information about hardware parameters that the kernel would not be able to determine on its own, or to avoid/override the values that the kernel would otherwise detect. However, if you just copy a kernel image directly to a floppy, (e.g. <tt> cp zImage /dev/fd0</tt>) then you are not given a chance to specify any arguments to that kernel. So most Linux users will use software like <em/LILO/ or <em/loadlin/ that takes care of handing these arguments to the kernel, and then booting it. This present revision covers kernels up to and including v2.0. The BootPrompt-Howto is edited and maintained by: <quote> Paul Gortmaker, <tt/gpg109@rsphy1.anu.edu.au/ </quote> [Please note that boot prompt arguments that are specific to the non-i386 ports and devices (esp. Atari/Amiga) are not currently documented.] <sect1>Disclaimer and Copyright<label id="copyright"> This document is <em/not/ gospel. However, it is probably the most up to date info that you will be able to find. Nobody is responsible for what happens to your hardware but yourself. If your hardware goes up in smoke (...nearly impossible!) I take no responsibility. ie. THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN THIS DOCUMENT. This document is Copyright (C) 1995,1996 by Paul Gortmaker. This document may be copied according to the conditions of the GNU General Public License, version 2, included herein by reference. See the file <tt>linux/COPYING</tt> that comes with the Linux kernel for full details. If you are intending to incorporate this document into a published work, please contact me, and I will make an effort to ensure that you have the most up to date information available. In the past, out of date versions of the Linux howto documents have been published, which caused the developers undue grief from being plagued with questions that were already answered in the up to date versions. <sect1>Related Documentation<label id="other_docs"> The most up-to-date documentation will always be the kernel source itself. Hold on! Don't get scared. You don't need to know any programming to read the comments in the source files. For example, if you were looking for what arguments could be passed to the AHA1542 SCSI driver, then you would go to the <tt>linux/drivers/scsi</tt> directory, and look at the file <tt/aha1542.c/ -- and within the first 100 lines, you would find a plain english description of the boot time arguments that the 1542 driver accepts. The next best thing will be any documentation files that are distributed with the kernel itself. There are now quite a few of these, and most of them can be found in the directory <tt>linux/Documentation</tt> and subdirectories from there. The <tt/linux/ directory is usually found in <tt>/usr/src/</tt>. Sometimes there will be <tt/README.foo/ files that can be found in the related driver directory (e.g. <tt>linux/drivers/XXX/</tt>, where <tt/XXX/ will be <tt/scsi/, <tt/char/, or <tt/net/). If you have figured out what boot-args you intend to use, and now want to know how to get that information to the kernel, then look at the documentation that comes with the software that you use to boot the kernel (e.g. LILO or loadlin). A brief overview is given below, but it is no substitute for the documentation that comes with the booting software. <sect1>The Linux Newsgroups<label id="news"> If you have questions about passing boot arguments to the kernel, please READ this document first. If this and the related documentation mentioned above does not answer your question(s) then you can try the Linux newsgroups. Of course you should try reading the group before blindly posting your question, as somebody else may have already asked it, or it may even be a Frequently Asked Question (a FAQ). A quick browse of the linux FAQ before posting is a <em/good/ idea. You should be able to find the FAQ somewhere close to where you found this document. General questions on how to configure your system should be directed to the comp.os.linux.setup newsgroup. We ask that you <em/please/ respect this general guideline for content, and don't cross-post your request to other groups. <sect1>New Versions of this Document<label id="new-doc"> New versions of this document can be retrieved via anonymous FTP from the site sunsite.unc.edu, in the directory <tt>/pub/Linux/docs/HOWTO/</tt>. Note that <em/SunSITE/ is usually heavily loaded, and you are better advised to get the document from one of the Linux ftp mirror sites. Updates will be made as new information and/or drivers becomes available. If this copy that you are presently reading is more than a few months old, then you should probably check to see if a newer copy exists. This document was produced by using a modified SGML system that was specifically set up for the Linux Howto project, and there are various output formats available, including, postscript, dvi, ascii, html, and soon TeXinfo. I would recommend viewing it in the html (via a WWW browser) or the Postscript/dvi format. Both of these contain cross-references that are lost in the ascii translation. If you want to get the official copy off sunsite, here is URL. <url url="http://sunsite.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html" name="BootPrompt-HOWTO"> <sect>Overview of Boot Prompt Arguments<label id="oview"> This section gives some examples of software that can be used to pass kernel boot-time arguments to the kernel itself. It also gives you an idea of how the arguments are processed, what limitations there are on the boot args, and how they filter down to each appropriate device that they are intended for. It is <em/important/ to note that spaces should <em/not/ be used in a boot argument, but only between separate arguments. A list of values that are for a single argument are to be separated with a comma between the values, and again without any spaces. See the following examples below. <code> ether=9,0x300,0xd0000,0xd4000,eth0 vga=ask *RIGHT* ether = 9, 0x300, 0xd0000, 0xd4000, eth0 vga = ask *WRONG* </code> <sect1>LILO (LInux LOader)<label id="lilo"> The LILO program (LInux LOader) written by Werner Almesberger is the most commonly used. It has the ability to boot various kernels, and stores the configuration information in a plain text file. Most distributions ship with LILO as the default boot-loader. LILO can boot DOS, OS/2 Linux, FreeBSD, etc. without any difficulties, and is quite flexible. A typical configuration will have LILO stop and print <tt/LILO:/ shortly after you turn on your computer. It will then wait for a few seconds for any optional input from the user, and failing that it will then boot the default system. Typical system labels that people use in the LILO configuration files are <tt/linux/ and <tt/backup/ and <tt/msdos/. If you want to type in a boot argument, you type it in here, after typing in the system label that you want LILO to boot from, as shown in the example below. <code> LILO: linux vga=ask </code> LILO comes with excellent documentation, and for the purposes of boot args discussed here, the LILO <tt/append=/ command is of significant importance when one wants to add a boot time argument as a permanent addition to the LILO config file. You simply add something like <tt/append = "vga=ask"/ to the <tt>/etc/lilo.conf</tt> file. It can either be added at the top of the config file, making it apply to all sections, or to a single system section by adding it inside an <tt/image=/ section. Please see the LILO documentation for a more complete description. <sect1>LoadLin<label id="loadlin"> The other commonly used Linux loader is `LoadLin' which is a DOS program that has the capability to launch a Linux kernel from the DOS prompt (with boot-args) assuming that certain resources are available. This is good for people that use DOS and want to launch into Linux from DOS. It is also very useful if you have certain hardware which relies on the supplied DOS driver to put the hardware into a known state. A common example is `SoundBlaster Compatible' sound cards that require the DOS driver to twiddle a few mystical registers to put the card into a SB compatible mode. Booting DOS with the supplied driver, and then loading Linux from the DOS prompt with loadlin avoids the reset of the card that happens if one rebooted instead. Thus the card is left in a Sb compatible mode and hence is useable under Linux. There are also other programs that can be used to boot Linux. For a complete list, please look at the programs available on your local Linux ftp mirror, under <tt>system/Linux-boot/</tt>. <sect1>The ``rdev'' utility<label id="rdev"> There are a few of the kernel boot parameters that have their default values stored in various bytes in the kernel image itself. There is a utility called <tt/rdev/ that is installed on most systems that knows where these values are, and how to change them. It can also change things that have no kernel boot argument equivalent, such as the default video mode used. The rdev utility is usually also aliased to swapdev, ramsize, vidmode and rootflags. These are the five things that rdev can change, those being the root device, the swap device, the RAM disk size, the default video mode, and the readonly/readwrite setting of root device. More information on <tt/rdev/ can be found by typing <tt/rdev -h/ or by reading the supplied man page (<tt/man rdev/). <sect1>How the Kernel Sorts the Arguments Most of the boot args take the form of: <code> name[=value_1]&lsqb,value_2]...&lsqb,value_11&rsqb </code> where `name' is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Multiple boot args are just a space separated list of the above format. Note the limit of 11 is real, as the present code only handles 11 comma separated parameters per keyword. (However, you can re-use the same keyword with up to an additional 11 parameters in unusually complicated situations, assuming the setup function supports it.) Also note that the kernel splits the list into a maximum of ten integer arguments, and a following string, so you can't really supply 11 integers unless you convert the 11th arg from a string to an int in the driver itself. Most of the sorting goes on in <tt>linux/init/main.c</tt>. First, the kernel checks to see if the argument is any of the special arguments `root=', `ro', `rw', or `debug'. The meaning of these special arguments is described further on in the document. Then it walks a list of setup functions (contained in the <tt/bootsetups/ array) to see if the specified argument string (such as `foo') has been associated with a setup function (<tt/foo_setup()/) for a particular device or part of the kernel. If you passed the kernel the line <tt>foo=3,4,5,6,bar</tt> then the kernel would search the <tt/bootsetups/ array to see if `foo' was registered. If it was, then it would call the setup function associated with `foo' (<tt/foo_setup()/) and hand it the integer arguments 3, 4, 5 and 6 as given on the kernel command line, and also hand it the string argument <tt/bar/. <sect1>Setting Environment Variables. Anything of the form `foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. A (useless?) example would be to use `TERM=vt100' as a boot argument. <sect1>Passing Arguments to the `init' program Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto process one, which is usually the <tt/init/ program. The most common argument that is passed to the <tt/init/ process is the word <em/single/ which instructs <tt/init/ to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of <tt/init/ installed on your system to see what arguments it accepts. <sect>General Non-Device Specific Boot Args<label id="general"> These are the boot arguments that are not related to any specific device or peripheral. They are instead related to certain internal kernel parameters, such as memory handling, ramdisk handling, root file system handling and others. <sect1> Root Filesystem options The following options all pertain to how the kernel selects and handles the root filesystem. <sect2>The `root=' Argument This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is the value of the root device of the system that the kernel was built on. For example, if the kernel in question was built on a system that used `/dev/hda1' as the root partition, then the default root device would be `/dev/hda1'. To override this default value, and select the second floppy drive as the root device, one would use `root=/dev/fd1'. Valid root devices are any of the following devices: (1) /dev/hdaN to /dev/hddN, which is partition N on ST-506 compatible disk `a to d'. (2) /dev/sdaN to /dev/sdeN, which is partition N on SCSI compatible disk `a to e'. (3) /dev/xdaN to /dev/xdbN, which is partition N on XT compatible disk `a to b'. (4) /dev/fdN, which is floppy disk drive number N. Having N=0 would be the DOS `A:' drive, and N=1 would be `B:'. (5) /dev/nfs, which is not really a device, but rather a flag to tell the kernel to get the root fs via the network. The more awkward and less portable numeric specification of the above possible disk devices in major/minor format is also accepted. (e.g. /dev/sda3 is major 8, minor 3, so you could use <tt/root=0x803/ as an alternative.) This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the <tt/rdev/ utility. <sect2>The `ro' Argument When the kernel boots, it needs a root filesystem to read basic things off of. This is the root filesystem that is mounted at boot. However, if the root filesystem is mounted with write access, you can not reliably check the filesystem integrity with half-written files in progress. The `ro' option tells the kernel to mount the root filesystem as `readonly' so that any filesystem consistency check programs (fsck) can safely assume that there are no half-written files in progress while performing the check. No programs or processes can write to files on the filesystem in question until it is `remounted' as read/write capable. This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the <tt/rdev/ utility. <sect2>The `rw' Argument This is the exact opposite of the above, in that it tells the kernel to mount the root filesystem as read/write. The default is to mount the root filesystem as read/write anyway. Do not run any `fsck' type programs on a filesystem that is mounted read/write. The same value stored in the image file mentioned above is also used for this parameter, accessible via <tt/rdev/. <sect1>Options Relating to RAM Disk Management The following options all relate to how the kernel handles the RAM disk device, which is usually used for bootstrapping machines during the install phase, or for machines with modular drivers that need to be installed to access the root filesystem. <sect2>The `ramdisk_start=' Argument To allow a kernel image to reside on a floppy disk along with a compressed ramdisk image, the `ramdisk_start=<offset>' command was added. The kernel can't be included into the compressed ramdisk filesystem image, because it needs to be stored starting at block zero so that the BIOS can load the bootsector and then the kernel can bootstrap itself to get going. Note: If you are using an uncompressed ramdisk image, then the kernel can be a part of the filesystem image that is being loaded into the ramdisk, and the floppy can be booted with LILO, or the two can be separate as is done for the compressed images. If you are using a two-disk boot/root setup (kernel on disk 1, ramdisk image on disk 2) then the ramdisk would start at block zero, and an offset of zero would be used. Since this is the default value, you would not need to actually use the command at all. <sect2>The `load_ramdisk=' Argument This parameter tells the kernel whether it is to try to load a ramdisk image or not. Specifying `load_ramdisk=1' will tell the kernel to load a floppy into the ramdisk. The default value is zero, meaning that the kernel should not try to load a ramdisk. Please see the file <tt>linux/Documentation/ramdisk.txt</tt> for a complete description of the new boot time arguments, and how to use them. A description of how this parameter can be set and stored in the kernel image via `rdev' is also described. <sect2>The `prompt_ramdisk=' Argument This parameter tells the kernel whether or not to give you a prompt asking you to insert the floppy containing the ramdisk image. In a single floppy configuration the ramdisk image is on the same floppy as the kernel that just finished loading/booting and so a prompt is not needed. In this case one can use `prompt_ramdisk=0'. In a two floppy configuration, you will need the chance to switch disks, and thus `prompt_ramdisk=1' can be used. Since this is the default value, it doesn't really need to be specified. ( (Historical note: Sneaky people used to use the `vga=ask' boot arg. to temporarily pause the boot process and allow a chance to switch from boot to root floppy.) Please see the file <tt>linux/Documentation/ramdisk.txt</tt> for a complete description of the new boot time arguments, and how to use them. A description of how this parameter can be set and stored in the kernel image via `rdev' is also described. <sect2>The `ramdisk_size=' Argument While it is true that the ramdisk grows dynamically as required, there is an upper bound on its size so that it doesn't consume all available RAM and leave you in a mess. The default is 4096 (i.e. 4MB) which should be large enough for most needs. You can override the default to a bigger or smaller size with this boot argument. Please see the file <tt>linux/Documentation/ramdisk.txt</tt> for a complete description of the new boot time arguments, and how to use them. A description of how this parameter can be set and stored in the kernel image via `rdev' is also described. <sect2>The `ramdisk=' Argument (obsolete) (NOTE: This argument is obsolete, and should not be used except on kernels v1.3.47 and older. The commands that should be used for the ramdisk device are documented above.) This specifies the size in kB of the RAM disk device. For example, if one wished to have a root filesystem on a 1.44MB floppy loaded into the RAM disk device, they would use: <code> ramdisk=1440 </code> This is one of the few kernel boot arguments that has its default stored in the kernel image, and which can thus be altered with the <tt/rdev/ utility. <sect2>The `noinitrd' (initial RAM disk) Argument The v2.x and newer kernels have a feature where the root filesystem is initially a RAM disk, and the kernel executes <tt>/linuxrc</tt> on that RAM image. This feature is typically used to allow loading of modules needed to mount the real root filesystem (e.g. load the SCSI driver modules stored in the RAM disk image, and then mount the real root filesystem on a SCSI disk.) The actual `noinitrd' argument determines what happens to the initrd data after the kernel has booted. When specified, instead of converting it to a RAM disk, it is accessible via <tt>/dev/initrd</tt>, which can be read once before the RAM is released back to the system. For full details on using the initial RAM disk, please consult <tt>linux/Documentation/initrd.txt</tt>. In addition, the most recent versions of <tt/LILO/ and <tt/LOADLIN/ should have additional useful information. <sect1>Boot Arguments Related to Memory Handling The following arguments alter how linux detects or handles the physical and virtual memory of your system. <sect2>The `mem=' Argument This argument has two purposes: The original purpose was to specify the amount of installed memory (or a value less than that if you wanted to limit the amount of memory available to linux). The second (and hardly used) purpose is to specify <tt/mem=nopentium/ which tells the linux kernel to not use the 4MB page table performance feature. The original BIOS call defined in the PC specification that returns the amount of installed memory was only designed to be able to report up to 64MB. (Yes, another lack of foresight, just like the 1024 cylinder disks... sigh.) Linux uses this BIOS call at boot to determine how much memory is installed. If you have more than 64MB of RAM installed, you can use this boot arg to tell Linux how much memory you have. Here is a quote from Linus on usage of the `mem=' parameter. ``The kernel will accept any `mem=xx' parameter you give it, and if it turns out that you lied to it, it will crash horribly sooner or later. The parameter indicates the highest addressable RAM address, so `mem=0x1000000' means you have 16MB of memory, for example. For a 96MB machine this would be `mem=0x6000000'. NOTE NOTE NOTE: some machines might use the top of memory for BIOS cacheing or whatever, so you might not actually have up to the full 96MB addressable. The reverse is also true: some chipsets will map the physical memory that is covered by the BIOS area into the area just past the top of memory, so the top-of-mem might actually be 96MB + 384kB for example. If you tell linux that it has more memory than it actually does have, bad things will happen: maybe not at once, but surely eventually.'' Note that the argument does not have to be in hex, and the suffixes `k' and `M' (case insensitive) can be used to specify kilobytes and Megabytes, respectively. (A `k' will cause a 10 bit shift on your value, and a `M' will cause a 20 bit shift.) The above warning still holds, in that a 96MB machine may work with <tt/mem=97920k/ but fail with either <tt/mem=98304k/ or <tt/mem=96M/. <sect2>The `swap=' Argument This allows the user to tune some of the virtual memory (VM) parameters that are related to swapping to disk. It accepts the following eight parameters: <code> MAX_PAGE_AGE PAGE_ADVANCE PAGE_DECLINE PAGE_INITIAL_AGE AGE_CLUSTER_FRACT AGE_CLUSTER_MIN PAGEOUT_WEIGHT BUFFEROUT_WEIGHT </code> Interested hackers are advised to have a read of <tt>linux/mm/swap.c</tt> and also make note of the goodies in <tt>/proc/sys/vm</tt>. <sect2>The `buff=' Argument Similar to the `swap=' argument, this allows the user to tune some of the parameters related to buffer memory management. It accepts the following six parameters: <code> MAX_BUFF_AGE BUFF_ADVANCE BUFF_DECLINE BUFF_INITIAL_AGE BUFFEROUT_WEIGHT BUFFERMEM_GRACE </code> Interested hackers are advised to have a read of <tt>linux/mm/swap.c</tt> and also make note of the goodies in <tt>/proc/sys/vm</tt>. <sect1>Boot Arguments for NFS Root Filesystem Linux supports systems such as diskless workstations via having their root filesystem as NFS (Network FileSystem). These arguments are used to tell the diskless workstation which machine it is to get its system from. Also note that the argument <tt>root=/dev/nfs</tt> is required. Detailed information on using an NFS root fs is in the file <tt>linux/Documentation/nfsroot.txt</tt>. You should read that file, as the following is only a quick summary taken directly from that file. <sect2>The `nfsroot=' Argument This argument tells the kernel which machine, what directory and what NFS options to use for the root filesystem. The form of the argument is as follows: <code> nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] </code> If the nfsroot parameter is not given on the command line, the default `/tftpboot/%s' will be used. The other options are as follows: <server-ip> -- Specifies the IP address of the NFS server. If this field is not given, the default address as determined by the nfsaddrs variable (see below) is used. One use of this parameter is for example to allow using different servers for RARP and NFS. Usually you can leave this blank. <root-dir> -- Name of the directory on the server to mount as root. If there is a `%s' token in the string, the token will be replaced by the ASCII-representation of the client's IP address. <nfs-options> -- Standard NFS options. All options are separated by commas. If the options field is not given, the following defaults will be used: <verb> port = as given by server portmap daemon rsize = 1024 wsize = 1024 timeo = 7 retrans = 3 acregmin = 3 acregmax = 60 acdirmin = 30 acdirmax = 60 flags = hard, nointr, noposix, cto, ac </verb> <sect2>The `nfsaddrs=' Argument This boot argument sets up the various network interface addresses that are required to communicate over the network. If this argument is not given, then the kernel tries to use RARP and/or BOOTP to figure out these parameters. The form is as follows: <code> nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto> </code> <my-ip> -- IP address of the client. If empty, the address will either be determined by RARP or BOOTP. What protocol is used de- pends on what has been enabled during kernel configuration and on the <auto> parameter. If this parameter is not empty, neither RARP nor BOOTP will be used. <serv-ip> -- IP address of the NFS server. If RARP is used to determine the client address and this parameter is NOT empty only replies from the specified server are accepted. To use different RARP and NFS server, specify your RARP server here (or leave it blank), and specify your NFS server in the nfsroot parameter (see above). If this entry is blank the address of the server is used which answered the RARP or BOOTP request. <gw-ip> -- IP address of a gateway if the server in on a different subnet. If this entry is empty no gateway is used and the server is assumed to be on the local network, unless a value has been received by BOOTP. <netmask> -- Netmask for local network interface. If this is empty, the netmask is derived from the client IP address, unless a value has been received by BOOTP. <name> -- Name of the client. If empty, the client IP address is used in ASCII-notation, or the value received by BOOTP. <dev> -- Name of network device to use. If this is empty, all devices are used for RARP requests, and the first one found for BOOTP. For NFS the device is used on which either RARP or BOOTP replies have been received. If you only have one device you can safely leave this blank. <auto> -- Method to use for autoconfiguration. If this is either `rarp' or `bootp' the specified protocol is being used. If the value is `both' or empty, both protocols are used so far as they have been enabled during kernel configuration Using 'none' means no autoconfiguration. In this case you have to specify all necessary values in the fields before. The <auto> parameter can appear alone as the value to the nfsaddrs parameter (without all the `:' characters before) in which case autoconfiguration is used. However, the `none' value is not available in that case. <sect1>Other Misc. Kernel Boot Arguments These various boot arguments let the user tune certain internal kernel parameters. <sect2>The `debug' Argument The kernel communicates important (and not-so important) messages to the operator via the <tt/printk()/ function. If the message is considered important, the <tt/printk()/ function will put a copy on the present console as well as handing it off to the <tt/klogd()/ facility so that it gets logged to disk. The reason for printing important messages to the console as well as logging them to disk is because under unfortunate circumstances (e.g. a disk failure) the message won't make it to disk and will be lost. The threshold for what is and what isn't considered important is set by the <tt/console_loglevel/ variable. The default is to log anything more important than <tt/DEBUG/ (level 7) to the console. (These levels are defined in the include file <tt/kernel.h/) Specifying <tt/debug/ as a boot argument will set the console loglevel to 10, so that <em/all/ kernel messages appear on the console. The console loglevel can usually also be set at run time via an option to the <tt/klogd()/ program. Check the man page for the version installed on your system to see how to do this. <sect2>The `init=' Argument The kernel defaults to starting the `init' program at boot, which then takes care of setting up the computer for users via launching getty programs, running `rc' scripts and the like. The kernel first looks for <tt>/sbin/init</tt>, then <tt>/etc/init</tt> (depreciated), and as a last resort, it will try to use <tt>/bin/sh</tt> (possibly on <tt>/etc/rc</tt>). If for example, your init program got corrupted and thus stopped you from being able to boot, you could simply use the boot prompt <tt>init=/bin/sh</tt> which would drop you directly into a shell at boot, allowing you to replace the corrupted program. <sect2>The `no387' Argument Some i387 coprocessor chips have bugs that show up when used in 32 bit protected mode. For example, some of the early ULSI-387 chips would cause solid lockups while performing floating point calculations, apparently due to a bug in the FRSAV/FRRESTOR instructions. Using the `no387' boot arg causes Linux to ignore the math coprocessor even if you have one. Of course you must then have your kernel compiled with math emulation support! This may also be useful if you have one of those <em/really/ old 386 machines that could use an 80287 FPU, as linux can't use an 80287. <sect2>The `no-hlt' Argument The i386 (and successors thereof) family of CPUs have a `hlt' instruction which tells the CPU that nothing is going to happen until an external device (keyboard, modem, disk, etc.) calls upon the CPU to do a task. This allows the CPU to enter a `low-power' mode where it sits like a zombie until an external device wakes it up (usually via an interrupt). Some of the early i486DX-100 chips had a problem with the `hlt' instruction, in that they couldn't reliably return to operating mode after this instruction was used. Using the `no-hlt' instruction tells Linux to just run an infinite loop when there is nothing else to do, and to <em/not/ halt your CPU when there is no activity. This allows people with these broken chips to use Linux, although they would be well advised to seek a replacement through a warranty where possible. <sect2>The `no-scroll' Argument Using this argument at boot disables scrolling features that make it difficult to use Braille terminals. <sect2>The `panic=' Argument In the unlikely event of a kernel panic (i.e. an internal error that has been detected by the kernel, and which the kernel decides is serious enough to moan loudly and then halt everything), the default behaviour is to just sit there until someone comes along and notices the panic message on the screen and reboots the machine. However if a machine is running unattended in an isolated location it may be desirable for it to automatically reset itself so that the machine comes back on line. For example, using `panic=30' at boot would cause the kernel to try and reboot itself 30 seconds after the kernel panic happened. A value of zero gives the default behaviour, which is to wait forever. Note that this timeout value can also be read and set via the <tt>/proc/sys/kernel/panic</tt> sysctl interface. <sect2>The `profile=' Argument Kernel developers can enable an option that allows them to profile how and where the kernel is spending its CPU cycles in an effort to maximize efficiency and performance. This option lets you set the profile shift count at boot. Typically it is set to two. Of course you have to compile your kernel with profiling enabled, and get a tool such as <tt/readprofile.c/ that can make use of <tt>/proc/profile</tt>. <sect2>The `reserve=' Argument This is used to <em/protect/ I/O port regions from probes. The form of the command is: <tscreen> reserve=iobase,extent[,iobase,extent]... </tscreen> In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of poorly designed hardware that causes the boot to <em/freeze/ (such as some ethercards), hardware that is mistakenly identified, hardware whose state is changed by an earlier probe, or merely hardware you don't want the kernel to initialize. The <tt/reserve/ boot-time argument addresses this problem by specifying an I/O port region that shouldn't be probed. That region is reserved in the kernel's port registration table as if a device has already been found in that region. Note that this mechanism shouldn't be necessary on most machines. Only when there is a problem or special case would it be necessary to use this. The I/O ports in the specified region are protected against device probes. This was put in to be used when some driver was hanging on a NE2000, or misidentifying some other device as its own. A correct device driver shouldn't probe a reserved region, unless another boot argument explicitly specifies that it do so. This implies that <tt/reserve/ will most often be used with some other boot argument. Hence if you specify a <tt/reserve/ region to protect a specific device, you must generally specify an explicit probe for that device. Most drivers ignore the port registration table if they are given an explicit address. For example, the boot line <code> reserve=0x300,32 blah=0x300 </code> keeps all device drivers except the driver for `blah' from probing 0x300-0x31f. As usual with boot-time specifiers there is an 11 parameter limit, thus you can only specify 5 reserved regions per <tt/reserve/ keyword. Multiple <tt/reserve/ specifiers will work if you have an unusually complicated request. <sect2> The `vga=' Argument This allows the setup code to use the video BIOS to change the default display mode before actually booting the Linux kernel. Typical modes are 80x50, 132x44 and so on. The best way to use this option is to start with <tt/vga=ask/ which will prompt you with a list of various modes that you can use with your video adapter before booting the kernel. Once you have the number from the above list that you want to use, you can later put it in place of the `ask'. For more information, please see the file <tt>linux/Documentation/svga.txt</tt> that comes with all recent kernel versions. <sect>Boot Arguments for SCSI Peripherals. This section contains the descriptions of the boot args that are used for passing information about the installed SCSI host adapters, and SCSI devices. <sect1>Arguments for Mid-level Drivers The mid level drivers handle things like disks, CD-ROMs and tapes without getting into host adapter specifics. <sect2>Maximum Probed LUNs (`max_scsi_luns=') Each SCSI device can have a number of `sub-devices' contained within itself. The most common example is one of the new SCSI CD-ROMs that handle more than one disk at a time. Each CD is addressed as a `Logical Unit Number' (LUN) of that particular device. But most devices, such as hard disks, tape drives and such are only one device, and will be assigned to LUN zero. The problem arises with single LUN devices with bad firmware. Some poorly designed SCSI devices (old and unfortunately new) can not handle being probed for LUNs not equal to zero. They will respond by locking up, and possibly taking the whole SCSI bus down with them. Newer kernels have the configuration option that allows you to set the maximum number of probed LUNs. The default is to only probe LUN zero, to avoid the problem described above. To specify the number of probed LUNs at boot, one enters `max_scsi_luns=n' as a boot arg, where n is a number between one and eight. To avoid problems as described above, one would use n=1 to avoid upsetting such broken devices <sect2>Parameters for the SCSI Tape Driver (`st=') Some boot time configuration of the SCSI tape driver can be achieved by using the following: <code> st=buf_size[,write_threshold[,max_bufs]] </code> The first two numbers are specified in units of kB. The default <tt/buf_size/ is 32kB, and the maximum size that can be specified is a ridiculous 16384kB. The <tt/write_threshold/ is the value at which the buffer is committed to tape, with a default value of 30kB. The maximum number of buffers varies with the number of drives detected, and has a default of two. An example usage would be: <code> st=32,30,2 </code> Full details can be found in the <tt/README.st/ file that is in the <tt/scsi/ directory of the kernel source tree. <sect1>Arguments for SCSI Host Adapters General notation for this section: <tt/iobase/ -- the first I/O port that the SCSI host occupies. These are specified in hexidecimal notation, and usually lie in the range from <tt/0x200/ to <tt/0x3ff/. <tt/irq/ -- the hardware interrupt that the card is configured to use. Valid values will be dependent on the card in question, but will usually be 5, 7, 9, 10, 11, 12, and 15. The other values are usually used for common peripherals like IDE hard disks, floppies, serial ports, etc. <tt/scsi-id/ -- the ID that the host adapter uses to identify itself on the SCSI bus. Only some host adapters allow you to change this value, as most have it permanently specified internally. The usual default value is seven, but the Seagate and Future Domain TMC-950 boards use six. <tt/parity/ -- whether the SCSI host adapter expects the attached devices to supply a parity value with all information exchanges. Specifying a one indicates parity checking is enabled, and a zero disables parity checking. Again, not all adapters will support selection of parity behaviour as a boot argument. <sect2>Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (`aha152x=') The aha numbers refer to cards and the aic numbers refer to the actual SCSI chip on these type of cards, including the Soundblaster-16 SCSI. The probe code for these SCSI hosts looks for an installed BIOS, and if none is present, the probe will not find your card. Then you will have to use a boot arg of the form: <code> aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]] </code> Note that if the driver was compiled with debugging enabled, a sixth value can be specified to set the debug level. All the parameters are as described at the top of this section, and the <tt/reconnect/ value will allow device disconnect/reconnect if a non-zero value is used. An example usage is as follows: <code> aha152x=0x340,11,7,1 </code> Note that the parameters must be specified in order, meaning that if you want to specify a parity setting, then you will have to specify an iobase, irq, scsi-id and reconnect value as well. <sect2>Adaptec aha154x (`aha1542=') These are the aha154x series cards. The aha1542 series cards have an i82077 floppy controller onboard, while the aha1540 series cards do not. These are busmastering cards, and have parameters to set the ``fairness'' that is used to share the bus with other devices. The boot arg looks like the following. <code> aha1542=iobase[,buson,busoff[,dmaspeed]] </code> Valid <tt/iobase/ values are usually one of: <tt/0x130, 0x134, 0x230, 0x234, 0x330, 0x334/. Clone cards may permit other values. The <tt/buson, busoff/ values refer to the number of microseconds that the card dominates the ISA bus. The defaults are 11us on, and 4us off, so that other cards (such as an ISA LANCE Ethernet card) have a chance to get access to the ISA bus. The <tt/dmaspeed/ value refers to the rate (in MB/s) at which the DMA (Direct Memory Access) transfers proceed at. The default is 5MB/s. Newer revision cards allow you to select this value as part of the soft-configuration, older cards use jumpers. You can use values up to 10MB/s assuming that your motherboard is capable of handling it. Experiment with caution if using values over 5MB/s. <sect2>Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=') These boards can accept an argument of the form: <code> aic7xxx=extended,no_reset </code> The <tt/extended/ value, if non-zero, indicates that extended translation for large disks is enabled. The <tt/no_reset/ value, if non-zero, tells the driver not to reset the SCSI bus when setting up the host adaptor at boot. <sect2>AdvanSys SCSI Host Adaptors (`advansys=') The AdvanSys driver can accept up to four i/o addresses that will be probed for an AdvanSys SCSI card. Note that these values (if used) do not effect EISA or PCI probing in any way. They are only used for probing ISA and VLB cards. In addition, if the driver has been compiled with debugging enabled, the level of debugging output can be set by adding an <tt/0xdeb[0-f]/ parameter. The <tt/0-f/ allows setting the level of the debugging messages to any of 16 levels of verbosity. <sect2>Always IN2000 Host Adaptor (`in2000=') Unlike other SCSI host boot arguments, the IN2000 driver uses ASCII string prefixes for most of its integer arguments. Here is a list of the supported arguments: ioport:addr -- Where addr is IO address of a (usually ROM-less) card. noreset -- No optional args. Prevents SCSI bus reset at boot time. nosync:x -- x is a bitmask where the 1st 7 bits correspond with the 7 possible SCSI devices (bit 0 for device #0, etc). Set a bit to PREVENT sync negotiation on that device. The driver default is sync DISABLED on all devices. period:ns -- ns is the minimum # of nanoseconds in a SCSI data transfer period. Default is 500; acceptable values are 250 to 1000. disconnect:x -- x = 0 to never allow disconnects, 2 to always allow them. x = 1 does 'adaptive' disconnects, which is the default and generally the best choice. debug:x If `DEBUGGING_ON' is defined, x is a bitmask that causes various types of debug output to printed - see the DB_xxx defines in in2000.h proc:x -- If `PROC_INTERFACE' is defined, x is a bitmask that determines how the /proc interface works and what it does - see the PR_xxx defines in in2000.h Some example usages are listed below: <code> in2000=ioport:0x220,noreset in2000=period:250,disconnect:2,nosync:0x03 in2000=debug:0x1e in2000=proc:3 </code> <sect2>AMD AM53C974 based hardware (`AM53C974=') Unlike other drivers, this one does not use boot parameters to communicate i/o, IRQ or DMA channels. (Since the AM53C974 is a PCI device, there shouldn't be a need to do so.) Instead, the parameters are used to communicate the transfer modes and rates that are to be used between the host and the target device. This is best described with an example: <code> AM53C974=7,2,8,15 </code> This would be interpreted as follows: `For communication between the controller with SCSI-ID 7 and the device with SCSI-ID 2, a transfer rate of 8MHz in synchronous mode with max. 15 bytes offset should be negotiated.' More details can be found in the file <tt>linux/drivers/scsi/README.AM53C974</tt> <sect2>BusLogic SCSI Hosts with v1.2 kernels (`buslogic=') In older kernels, the buslogic driver accepts only one parameter, that being the I/O base. It expects that to be one of the following valid values: <tt/0x130, 0x134, 0x230, 0x234, 0x330, 0x334/. <sect2>BusLogic SCSI Hosts with v2.x kernels (`BusLogic=') With v2.x kernels, the BusLogic driver accepts many parameters. (Note the case in the above; upper case B and L!!!). The following detailed description is taken directly from Leonard N. Zubkoff's driver as included in the v2.0 kernel. For the BusLogic driver, a Kernel command line entry comprises the driver identifier "BusLogic=" optionally followed by a comma-separated sequence of integers and then optionally followed by a comma-separated sequence of strings. Each command line entry applies to one BusLogic Host Adapter. Multiple command line entries may be used in systems which contain multiple BusLogic Host Adapters. The first integer specified is the I/O Address at which the Host Adapter is located. If unspecified, it defaults to 0 which means to apply this entry to the first BusLogic Host Adapter found during the default probe sequence. If any I/O Address parameters are provided on the command line, then the default probe sequence is omitted. The second integer specified is the Tagged Queue Depth to use for Target Devices that support Tagged Queuing. The Queue Depth is the number of SCSI commands that are allowed to be concurrently presented for execution. If unspecified, it defaults to 0 which means to use a value determined automatically based on the Host Adapter's Total Queue Depth and the number, type, speed, and capabilities of the detected Target Devices. For Host Adapters that require ISA Bounce Buffers, the Tagged Queue Depth is automatically set to BusLogic_TaggedQueueDepth_BB to avoid excessive preallocation of DMA Bounce Buffer memory. Target Devices that do not support Tagged Queuing use a Queue Depth of BusLogic_UntaggedQueueDepth. The third integer specified is the Bus Settle Time in seconds. This is the amount of time to wait between a Host Adapter Hard Reset which initiates a SCSI Bus Reset and issuing any SCSI Commands. If unspecified, it defaults to 0 which means to use the value of BusLogic_DefaultBusSettleTime. The fourth integer specified is the Local Options. If unspecified, it defaults to 0. Note that Local Options are only applied to a specific Host Adapter. The fifth integer specified is the Global Options. If unspecified, it defaults to 0. Note that Global Options are applied across all Host Adapters. The string options are used to provide control over Tagged Queuing, Error Recovery, and Host Adapter Probing. The Tagged Queuing specification begins with "TQ:" and allows for explicitly specifying whether Tagged Queuing is permitted on Target Devices that support it. The following specification options are available: TQ:Default -- Tagged Queuing will be permitted based on the firmware version of the BusLogic Host Adapter and based on whether the Tagged Queue Depth value allows queuing multiple commands. TQ:Enable -- Tagged Queuing will be enabled for all Target Devices on this Host Adapter overriding any limitation that would otherwise be imposed based on the Host Adapter firmware version. TQ:Disable -- Tagged Queuing will be disabled for all Target Devices on this Host Adapter. TQ:<Per-Target-Spec> -- Tagged Queuing will be controlled individually for each Target Device. <Per-Target-Spec> is a sequence of "Y", "N", and "X" characters. "Y" enabled Tagged Queuing, "N" disables Tagged Queuing, and "X" accepts the default based on the firmware version. The first character refers to Target Device 0, the second to Target Device 1, and so on; if the sequence of "Y", "N", and "X" characters does not cover all the Target Devices, unspecified characters are assumed to be "X". Note that explicitly requesting Tagged Queuing may lead to problems; this facility is provided primarily to allow disabling Tagged Queuing on Target Devices that do not implement it correctly. The Error Recovery Strategy specification begins with "ER:" and allows for explicitly specifying the Error Recovery action to be performed when ResetCommand is called due to a SCSI Command failing to complete successfully. The following specification options are available: ER:Default -- Error Recovery will select between the Hard Reset and Bus Device Reset options based on the recommendation of the SCSI Subsystem. ER:HardReset -- Error Recovery will initiate a Host Adapter Hard Reset which also causes a SCSI Bus Reset. ER:BusDeviceReset -- Error Recovery will send a Bus Device Reset message to the individual Target Device causing the error. If Error Recovery is again initiated for this Target Device and no SCSI Command to this Target Device has completed successfully since the Bus Device Reset message was sent, then a Hard Reset will be attempted. ER:None -- Error Recovery will be suppressed. This option should only be selected if a SCSI Bus Reset or Bus Device Reset will cause the Target Device to fail completely and unrecoverably. ER:<Per-Target-Spec> -- Error Recovery will be controlled individually for each Target Device. <Per-Target-Spec> is a sequence of "D", "H", "B", and "N" characters. "D" selects Default, "H" selects Hard Reset, "B" selects Bus Device Reset, and "N" selects None. The first character refers to Target Device 0, the second to Target Device 1, and so on; if the sequence of "D", "H", "B", and "N" characters does not cover all the possible Target Devices, unspecified characters are assumed to be "D". The Host Adapter Probing specification comprises the following strings: NoProbe -- No probing of any kind is to be performed, and hence no BusLogic Host Adapters will be detected. NoProbeISA -- No probing of the standard ISA I/O Addresses will be done, and hence only PCI Host Adapters will be detected. NoSortPCI -- PCI Host Adapters will be enumerated in the order provided by the PCI BIOS, ignoring any setting of the AutoSCSI "Use Bus And Device # For PCI Scanning Seq." option. <sect2>Future Domain TMC-8xx, TMC-950 (`tmc8xx=') The probe code for these SCSI hosts looks for an installed BIOS, and if none is present, the probe will not find your card. Or, if the signature string of your BIOS is not recognized then it will also not be found. In either case, you will then have to use a boot arg of the form: <code> tmc8xx=mem_base,irq </code> The <tt/mem_base/ value is the value of the memory mapped I/O region that the card uses. This will usually be one of the following values: <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/. <sect2>IOMEGA Parallel Port / ZIP drive (`ppa=') This driver is for the IOMEGA Parallel Port SCSI adapter which is embedded into the IOMEGA ZIP drives. It may also work with the original IOMEGA PPA3 device. The boot argument for this driver is of the form: <code> ppa=iobase,speed_high,speed_low,nybble </code> with all but iobase being optionally specified values. If you wish to alter any of the three optional parameters, you are advised to read <tt>linux/drivers/scsi/README.ppa</tt> for details of what they control. <sect2>NCR5380 based controllers (`ncr5380=') Depending on your board, the 5380 can be either i/o mapped or memory mapped. (An address below 0x400 usually implies i/o mapping, but PCI and EISA hardware use i/o addresses above 0x3ff.) In either case, you specify the address, the IRQ value and the DMA channel value. An example for an i/o mapped card would be: <tt/ncr5380=0x350,5,3/. If the card doesn't use interrupts, then an IRQ value of 255 (<tt/0xff/) will disable interrupts. An IRQ value of 254 means to autoprobe. More details can be found in the file <tt>linux/drivers/scsi/README.g_NCR5380</tt> <sect2>NCR53c400 based controllers (`ncr53c400=') The generic 53c400 support is done with the same driver as the generic 5380 support mentioned above. The boot argument is identical to the above with the exception that no DMA channel is used by the 53c400. <sect2>NCR53c406a based controllers (`ncr53c406a=') This driver uses a boot argument of the form: <code> ncr53c406a=PORTBASE,IRQ,FASTPIO </code> where the IRQ and FASTPIO parameters are optional. An interrupt value of zero disables the use of interrupts. Using a value of one for the FASTPIO parameter enables the use of <tt/insl/ and <tt/outsl/ instructions instead of the single-byte <tt/inb/ and <tt/outb/ instructions. The driver can also use DMA as a compile-time option. <sect2>Pro Audio Spectrum (`pas16=') The PAS16 uses a NCR5380 SCSI chip, and newer models support jumper-less configuration. The boot arg is of the form: <code> pas16=iobase,irq </code> The only difference is that you can specify an IRQ value of 255, which will tell the driver to work without using interrupts, albeit at a performance loss. The <tt/iobase/ is usually <tt/0x388/. <sect2>Seagate ST-0x (`st0x=') The probe code for these SCSI hosts looks for an installed BIOS, and if none is present, the probe will not find your card. Or, if the signature string of your BIOS is not recognized then it will also not be found. In either case, you will then have to use a boot arg of the form: <code> st0x=mem_base,irq </code> The <tt/mem_base/ value is the value of the memory mapped I/O region that the card uses. This will usually be one of the following values: <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/. <sect2>Trantor T128 (`t128=') These cards are also based on the NCR5380 chip, and accept the following options: <code> t128=mem_base,irq </code> The valid values for <tt/mem_base/ are as follows: <tt/0xcc000, 0xc8000, 0xdc000, 0xd8000/. <sect1>SCSI Host Adapters that don't Accept Boot Args At present, the following SCSI cards do not make use of any boot-time parameters. In some cases, you can <em/hard-wire/ values by directly editing the driver itself, if required. <verb> Adaptec aha1740, EATA-DMA, EATA-PIO, Future Domain 16xx, NCR53c7xx to NCR53c8xx, Qlogic, Ultrastor (incl. u?4f), Western Digital wd7000, </verb> <sect>Hard Disks This section lists all the boot args associated with standard MFM/RLL, ST-506, XT, and IDE disk drive devices. Note that both the IDE and the generic ST-506 HD driver both accept the `hd=' option. <sect1>IDE Disk/CD-ROM Driver Parameters The IDE driver accepts a number of parameters, which range from disk geometry specifications, to support for advanced or broken controller chips. The following is a summary of all the possible boot arguments. For full details, you <em/really/ should consult the file <tt/ide.txt/ in the <tt>linux/Documentation</tt> directory. <code> "hdx=" is recognized for all "x" from "a" to "h", such as "hdc". "idex=" is recognized for all "x" from "0" to "3", such as "ide1". "hdx=noprobe" : drive may be present, but do not probe for it "hdx=none" : drive is NOT present, ignore cmos and do not probe "hdx=nowerr" : ignore the WRERR_STAT bit on this drive "hdx=cdrom" : drive is present, and is a cdrom drive "hdx=cyl,head,sect" : disk drive is present, with specified geometry "hdx=autotune" : driver will attempt to tune interface speed to the fastest PIO mode supported, if possible for this drive only. Not fully supported by all chipset types, and quite likely to cause trouble with older/odd IDE drives. "idex=noprobe" : do not attempt to access/use this interface "idex=base" : probe for an interface at the addr specified, where "base" is usually 0x1f0 or 0x170 and "ctl" is assumed to be "base"+0x206 "idex=base,ctl" : specify both base and ctl "idex=base,ctl,irq" : specify base, ctl, and irq number "idex=autotune" : driver will attempt to tune interface speed to the fastest PIO mode supported, for all drives on this interface. Not fully supported by all chipset types, and quite likely to cause trouble with older/odd IDE drives. "idex=noautotune" : driver will NOT attempt to tune interface speed This is the default for most chipsets, except the cmd640. "idex=serialize" : do not overlap operations on idex and ide(x^1) </code> The following are valid ONLY on ide0, and the defaults for the base,ctl ports must not be altered. <code> "ide0=dtc2278" : probe/support DTC2278 interface "ide0=ht6560b" : probe/support HT6560B interface "ide0=cmd640_vlb" : *REQUIRED* for VLB cards with the CMD640 chip (not for PCI -- automatically detected) "ide0=qd6580" : probe/support qd6580 interface "ide0=ali14xx" : probe/support ali14xx chipsets (ALI M1439/M1445) "ide0=umc8672" : probe/support umc8672 chipsets </code> Everything else is rejected with a "BAD OPTION" message. <sect1>Standard ST-506 Disk Driver Options (`hd=') The standard disk driver can accept geometry arguments for the disks similar to the IDE driver. Note however that it only expects three values (C/H/S) -- any more or any less and it will silently ignore you. Also, it only accepts `hd=' as an argument, i.e. `hda=', `hdb=' and so on are not valid here. The format is as follows: <code> hd=cyls,heads,sects </code> If there are two disks installed, the above is repeated with the geometry parameters of the second disk. <sect1>XT Disk Driver Options (`xd=') If you are unfortunate enough to be using one of these old 8 bit cards that move data at a whopping 125kB/s then here is the scoop. The probe code for these cards looks for an installed BIOS, and if none is present, the probe will not find your card. Or, if the signature string of your BIOS is not recognized then it will also not be found. In either case, you will then have to use a boot arg of the form: <code> xd=type,irq,iobase,dma_chan </code> The <tt/type/ value specifies the particular manufacturer of the card, and are as follows: 0=generic; 1=DTC; 2,3,4=Western Digital, 5,6,7=Seagate; 8=OMTI. The only difference between multiple types from the same manufacturer is the BIOS string used for detection, which is not used if the type is specified. The <tt/xd_setup()/ function does no checking on the values, and assumes that you entered all four values. Don't disappoint it. Here is an example usage for a WD1002 controller with the BIOS disabled/removed, using the `default' XT controller parameters: <code> xd=2,5,0x320,3 </code> <sect>CD-ROMs (Non-SCSI/ATAPI/IDE) This section lists all the possible boot args pertaining to CD-ROM devices. Note that this does not include SCSI or IDE/ATAPI CD-ROMs. See the appropriate section(s) for those types of CD-ROMs. Note that most of these CD-ROMs have documentation files that you <em/should/ read, and they are all in one handy place: <tt>linux/Documentation/cdrom</tt>. <sect1>The Aztech Interface (`aztcd=') The syntax for this type of card is: <code> aztcd=iobase[,magic_number] </code> If you set the <tt/magic_number/ to <tt/0x79/ then the driver will try and run anyway in the event of an unknown firmware version. All other values are ignored. <sect1>The CDU-31A and CDU-33A Sony Interface (`cdu31a=') This CD-ROM interface is found on some of the Pro Audio Spectrum sound cards, and other Sony supplied interface cards. The syntax is as follows: <code> cdu31a=iobase,[irq[,is_pas_card]] </code> Specifying an IRQ value of zero tells the driver that hardware interrupts aren't supported (as on some PAS cards). If your card supports interrupts, you should use them as it cuts down on the CPU usage of the driver. The `is_pas_card' should be entered as `PAS' if using a Pro Audio Spectrum card, and otherwise it should not be specified at all. <sect1>The CDU-535 Sony Interface (`sonycd535=') The syntax for this CD-ROM interface is: <code> sonycd535=iobase[,irq] </code> A zero can be used for the I/O base as a `placeholder' if one wishes to specify an IRQ value. <sect1>The GoldStar Interface (`gscd=') The syntax for this CD-ROM interface is: <code> gscd=iobase </code> <sect1>The ISP16 Interface (`isp16=') The syntax for this CD-ROM interface is: <code> isp16=[port[,irq[,dma]]][[,]drive_type] </code> Using a zero for <tt/irq/ or <tt/dma/ means that they are not used. The allowable values for <tt/drive_type/ are <tt/noisp16, Sanyo, Panasonic, Sony,/ and <tt/Mitsumi/. Using <tt/noisp16/ disables the driver altogether. <sect1>The Mitsumi Standard Interface (`mcd=') The syntax for this CD-ROM interface is: <code> mcd=iobase,[irq[,wait_value]] </code> The <tt/wait_value/ is used as an internal timeout value for people who are having problems with their drive, and may or may not be implemented depending on a compile time <tt/DEFINE/. <sect1>The Mitsumi XA/MultiSession Interface (`mcdx=') At present this `experimental' driver has a setup function, but no parameters are implemented yet (as of 1.3.15). This is for the same hardware as above, but the driver has extended features. <sect1>The Optics Storage Interface (`optcd=') The syntax for this type of card is: <code> optcd=iobase </code> <sect1>The Phillips CM206 Interface (`cm206=') The syntax for this type of card is: <code> cm206=[iobase][,irq] </code> The driver assumes numbers between 3 and 11 are IRQ values, and numbers between <tt/0x300/ and <tt/0x370/ are I/O ports, so you can specify one, or both numbers, in any order. It also accepts `cm206=auto' to enable autoprobing. <sect1>The Sanyo Interface (`sjcd=') The syntax for this type of card is: <code> sjcd=iobase[,irq[,dma_channel]] </code> <sect1>The SoundBlaster Pro Interface (`sbpcd=') The syntax for this type of card is: <code> sbpcd=iobase,type </code> where <tt/type/ is one of the following (case sensitive) strings: `SoundBlaster', `LaserMate', or `SPEA'. The I/O base is that of the CD-ROM interface, and <em/not/ that of the sound portion of the card. <sect>Other Hardware Devices Any other devices that didn't fit into any of the above categories got lumped together here. <sect1>Ethernet Devices (`ether=') Different drivers make use of different parameters, but they all at least share having an IRQ, an I/O port base value, and a name. In its most generic form, it looks something like this: <code> ether=irq,iobase[,param_1[,param_2,...param_8]]],name </code> The first non-numeric argument is taken as the name. The <tt/param_n/ values (if applicable) usually have different meanings for each different card/driver. Typical <tt/param_n/ values are used to specify things like shared memory address, interface selection, DMA channel and the like. The most common use of this parameter is to force probing for a second ethercard, as the default is to only probe for one. This can be accomplished with a simple: <code> ether=0,0,eth1 </code> Note that the values of zero for the IRQ and I/O base in the above example tell the driver(s) to autoprobe. Note that the Ethernet-HowTo has complete and extensive documentation on using multiple cards and on the card/driver specific implementation of the <tt/param_n/ values where used. Interested readers should refer to the section in that document on their particular card for more complete information. <sect1>The Floppy Disk Driver (`floppy=') There are many floppy driver options, and they are all listed in <tt/README.fd/ in <tt>linux/drivers/block</tt>. This information is taken directly from that file. floppy=mask,allowed_drive_mask Sets the bitmask of allowed drives to <tt/mask/. By default, only units 0 and 1 of each floppy controller are allowed. This is done because certain non-standard hardware (ASUS PCI motherboards) mess up the keyboard when accessing units 2 or 3. This option is somewhat obsoleted by the cmos option. floppy=all_drives Sets the bitmask of allowed drives to all drives. Use this if you have more than two drives connected to a floppy controller. floppy=asus_pci Sets the bitmask to allow only units 0 and 1. (The default) floppy=daring Tells the floppy driver that you have a well behaved floppy controller. This allows more efficient and smoother operation, but may fail on certain controllers. This may speed up certain operations. floppy=0,daring Tells the floppy driver that your floppy controller should be used with caution. floppy=one_fdc Tells the floppy driver that you have only floppy controller (default) floppy=two_fdc <em/or/ floppy=address,two_fdc Tells the floppy driver that you have two floppy controllers. The second floppy controller is assumed to be at address. If address is not given, 0x370 is assumed. floppy=thinkpad Tells the floppy driver that you have a Thinkpad. Thinkpads use an inverted convention for the disk change line. floppy=0,thinkpad Tells the floppy driver that you don't have a Thinkpad. floppy=drive,type,cmos Sets the cmos type of <tt/drive/ to <tt/type/. Additionally, this drive is allowed in the bitmask. This is useful if you have more than two floppy drives (only two can be described in the physical cmos), or if your BIOS uses non-standard CMOS types. Setting the CMOS to 0 for the first two drives (default) makes the floppy driver read the physical cmos for those drives. floppy=unexpected_interrupts Print a warning message when an unexpected interrupt is received (default behaviour) floppy=no_unexpected_interrupts <em/or/ floppy=L40SX Don't print a message when an unexpected interrupt is received. This is needed on IBM L40SX laptops in certain video modes. (There seems to be an interaction between video and floppy. The unexpected interrupts only affect performance, and can safely be ignored.) <sect1>The Sound Driver (`sound=') The sound driver can also accept boot args to override the compiled in values. This is not recommended, as it is rather complex. It is described in the <tt/Readme.Linux/ file, in <tt>linux/drivers/sound</tt>. It accepts a boot arg of the form: <code> sound=device1[,device2[,device3...[,device11]]] </code> where each <tt/deviceN/ value is of the following format <tt/0xTaaaId/ and the bytes are used as follows: T - device type: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401 aaa - I/O address in hex. I - interrupt line in hex (i.e 10=a, 11=b, ...) d - DMA channel. As you can see it gets pretty messy, and you are better off to compile in your own personal values as recommended. Using a boot arg of `sound=0' will disable the sound driver entirely. <sect1>The Bus Mouse Driver (`bmouse=') The busmouse driver only accepts one parameter, that being the hardware IRQ value to be used. <sect1>The MS Bus Mouse Driver (`msmouse=') The MS mouse driver only accepts one parameter, that being the hardware IRQ value to be used. <sect1>The Printer Driver (`lp=') As of kernels newer than 1.3.75, you can tell the printer driver what ports to use and what ports <em/not/ to use. The latter comes in handy if you don't want the printer driver to claim all available parallel ports, so that other drivers (e.g. PLIP, PPA) can use them instead. The format of the argument is multiple i/o, IRQ pairs. For example, <tt/lp=0x3bc,0,0x378,7/ would use the port at 0x3bc in IRQ-less (polling) mode, and use IRQ 7 for the port at 0x378. The port at 0x278 (if any) would not be probed, since autoprobing only takes place in the absence of a `lp=' argument. To disable the printer driver entirely, one can use <tt/lp=0/. <sect1>The ICN ISDN driver (`icn=') This ISDN driver expects a boot argument of the form: <code> icn=iobase,membase,icn_id1,icn_id2 </code> where <tt/iobase/ is the i/o port address of the card, <tt/membase/ is the shared memory base address of the card, and the two <tt/icn_id/ are unique ASCII string identifiers. <sect1>The PCBIT ISDN driver (`pcbit=') This boot argument takes integer pair arguments of the form: <code> pcbit=membase1,irq1[,membase2,irq2] </code> where <tt/membaseN/ is the shared memory base of the N'th card, and <tt/irqN/ is the interrupt setting of the N'th card. The default is IRQ 5 and membase <tt/0xD0000/. <sect1>The Teles ISDN driver (`teles=') This ISDN driver expects a boot argument of the form: <code> teles=iobase,irq,membase,protocol,teles_id </code> where <tt/iobase/ is the i/o port address of the card, <tt/membase/ is the shared memory base address of the card, <tt/irq/ is the interrupt channel the card uses, and <tt/teles_id/ is the unique ASCII string identifier. <sect1>The DigiBoard Driver (`digi=') The DigiBoard driver accepts a string of six comma separated identifiers or integers. The 6 values in order are: <verb> Enable/Disable this card Type of card: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3) Enable/Disable alternate pin arrangement Number of ports on this card I/O Port where card is configured (in HEX if using string identifiers) Base of memory window (in HEX if using string identifiers) </verb> An example of a correct boot prompt argument (in both identifier and integer form) is: <code> digi=E,PC/Xi,D,16,200,D0000 digi=1,0,0,16,512,851968 </code> Note that the driver defaults to an i/o of <tt/0x200/ and a shared memory base of <tt/0xD0000/ in the absence of a <tt/digi=/ boot argument. There is no autoprobing performed. More details can be found in the file <tt>linux/Documentation/digiboard.txt</tt>. <sect1>The RISCom/8 Multiport Serial Driver (`riscom8=') Up to four boards can be supported by supplying four unique i/o port values for each individual board installed. Other details can be found in the file <tt>linux/Documentation/riscom8.txt</tt>. <sect1>The Baycom Serial/Parallel Radio Modem (`baycom=') The format of the boot argument for these devices is: <code> baycom=modem,io,irq,options[,modem,io,irq,options] </code> Using modem=1 means you have the ser12 device, modem=2 means you have the par96 device. Using options=0 means use hardware DCD, and options=1 means use software DCD. The <tt/io/ and <tt/irq/ are the i/o port base and interrupt settings as usual. There is more details in the file <tt/README.baycom/ which is currently in the <tt>/linux/drivers/char/</tt> directory. <sect>Closing If you have found any glaring typos, or outdated info in this document, please let me know. It is easy to overlook stuff. Thanks, Paul Gortmaker, <tt/gpg109@rsphy1.anu.edu.au/ </article>