home *** CD-ROM | disk | FTP | other *** search
/ Freelog Special Edition 1: Linux / CD1.iso / doc / HOWTO / BootPrompt-HOWTO < prev    next >
Text File  |  1998-10-14  |  83KB  |  1,830 lines

  1.   The Linux BootPrompt-HowTo
  2.   by Paul Gortmaker.
  3.   v1.14, 1 February 1998
  4.  
  5.   This is the BootPrompt-Howto, which is a compilation of all the possi¡
  6.   ble boot time arguments that can be passed to the Linux kernel at boot
  7.   time. This includes all kernel and device parameters.  A discussion of
  8.   how the kernel sorts boot time arguments, along with an overview of
  9.   some of the popular software used to boot Linux kernels is also
  10.   included.
  11.  
  12.   1.  Introduction
  13.  
  14.   The kernel has a limited capability to accept information at boot in
  15.   the form of a `command line', similar to an argument list you would
  16.   give to a program. In general this is used to supply the kernel with
  17.   information about hardware parameters that the kernel would not be
  18.   able to determine on its own, or to avoid/override the values that the
  19.   kernel would otherwise detect.
  20.  
  21.   However, if you just copy a kernel image directly to a floppy, (e.g.
  22.   cp zImage /dev/fd0) then you are not given a chance to specify any
  23.   arguments to that kernel. So most Linux users will use software like
  24.   LILO or loadlin that takes care of handing these arguments to the
  25.   kernel, and then booting it.
  26.  
  27.   IMPORTANT NOTE TO MODULE USERS: Boot Prompt arguments typically only
  28.   apply to hardware drivers that are compiled directly into the kernel.
  29.   They have no effect on drivers that are loaded as modules. Most
  30.   distributions use modules. If you are unsure, then look at man depmod
  31.   and man modprobe along with the contents of /etc/conf.modules.
  32.  
  33.   This present revision covers kernels up to and including v2.0.33.
  34.   Some features that are unique to development/testing kernels up to
  35.   v2.1.84 are also documented.
  36.  
  37.   The BootPrompt-Howto is by:
  38.  
  39.        Paul Gortmaker, gpg109@rsphy1.anu.edu.au
  40.  
  41.   [Please note that boot prompt arguments that are specific to the non-
  42.   i386 ports and devices (esp. Atari/Amiga) are not currently
  43.   documented.]
  44.  
  45.   1.1.  Disclaimer and Copyright
  46.  
  47.   This document is not gospel. However, it is probably the most up to
  48.   date info that you will be able to find. Nobody is responsible for
  49.   what happens to your hardware but yourself. If your hardware goes up
  50.   in smoke (...nearly impossible!)  I take no responsibility. ie. THE
  51.   AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS
  52.   TAKEN BASED ON THE INFORMATION INCLUDED IN THIS DOCUMENT.
  53.  
  54.   This document is Copyright (C) 1995-1998 by Paul Gortmaker.
  55.  
  56.   This document may be copied according to the conditions of the GNU
  57.   General Public License, version 2, included herein by reference. See
  58.   the file linux/COPYING that comes with the Linux kernel for full
  59.   details.
  60.  
  61.   If you are intending to incorporate this document into a published
  62.   work, please contact me, and I will make an effort to ensure that you
  63.   have the most up to date information available. In the past, out of
  64.   date versions of the Linux howto documents have been published, which
  65.   caused the developers undue grief from being plagued with questions
  66.   that were already answered in the up to date versions.
  67.  
  68.   1.2.  Related Documentation
  69.  
  70.   The most up-to-date documentation will always be the kernel source
  71.   itself. Hold on! Don't get scared. You don't need to know any
  72.   programming to read the comments in the source files.  For example, if
  73.   you were looking for what arguments could be passed to the AHA1542
  74.   SCSI driver, then you would go to the linux/drivers/scsi directory,
  75.   and look at the file aha1542.c -- and within the first 100 lines, you
  76.   would find a plain english description of the boot time arguments that
  77.   the 1542 driver accepts.
  78.  
  79.   The next best thing will be any documentation files that are
  80.   distributed with the kernel itself. There are now quite a few of
  81.   these, and most of them can be found in the directory
  82.   linux/Documentation and subdirectories from there.  The linux
  83.   directory is usually found in /usr/src/.  Sometimes there will be
  84.   README.foo files that can be found in the related driver directory
  85.   (e.g. linux/drivers/XXX/, where XXX will be scsi, char, or net).
  86.  
  87.   If you have figured out what boot-args you intend to use, and now want
  88.   to know how to get that information to the kernel, then look at the
  89.   documentation that comes with the software that you use to boot the
  90.   kernel (e.g. LILO or loadlin). A brief overview is given below, but it
  91.   is no substitute for the documentation that comes with the booting
  92.   software.
  93.  
  94.   1.3.  The Linux Newsgroups
  95.  
  96.   If you have questions about passing boot arguments to the kernel,
  97.   please READ this document first. If this and the related documentation
  98.   mentioned above does not answer your question(s) then you can try the
  99.   Linux newsgroups.  Of course you should try reading the group before
  100.   blindly posting your question, as somebody else may have already asked
  101.   it, or it may even be a Frequently Asked Question (a FAQ).  A quick
  102.   browse of the linux FAQ before posting is a good idea. You should be
  103.   able to find the FAQ somewhere close to where you found this document.
  104.  
  105.   General questions on how to configure your system should be directed
  106.   to the comp.os.linux.setup newsgroup.  We ask that you please respect
  107.   this general guideline for content, and don't cross-post your request
  108.   to other groups.
  109.  
  110.   1.4.  New Versions of this Document
  111.  
  112.   New versions of this document can be retrieved via anonymous FTP from
  113.   the site sunsite.unc.edu, in the directory /pub/Linux/docs/HOWTO/.
  114.   Note that SunSITE is usually heavily loaded, and you are better
  115.   advised to get the document from one of the Linux ftp mirror sites.
  116.   Updates will be made as new information and/or drivers becomes
  117.   available. If this copy that you are presently reading is more than a
  118.   few months old, then you should probably check to see if a newer copy
  119.   exists.
  120.  
  121.   This document was produced by using a modified SGML system that was
  122.   specifically set up for the Linux Howto project, and there are various
  123.   output formats available, including, postscript, dvi, ascii, html, and
  124.   soon TeXinfo.  I would recommend viewing it in the html (via a WWW
  125.   browser) or the Postscript/dvi format. Both of these contain cross-
  126.   references that are lost in the ascii translation.
  127.  
  128.   If you want to get the official copy off sunsite, here is URL.
  129.  
  130.   BootPrompt-HOWTO <http://sunsite.unc.edu/mdw/HOWTO/BootPrompt-
  131.   HOWTO.html>
  132.  
  133.   2.  Overview of Boot Prompt Arguments
  134.  
  135.   This section gives some examples of software that can be used to pass
  136.   kernel boot-time arguments to the kernel itself.  It also gives you an
  137.   idea of how the arguments are processed, what limitations there are on
  138.   the boot args, and how they filter down to each appropriate device
  139.   that they are intended for.
  140.  
  141.   It is important to note that spaces should not be used in a boot
  142.   argument, but only between separate arguments.  A list of values that
  143.   are for a single argument are to be separated with a comma between the
  144.   values, and again without any spaces. See the following examples
  145.   below.
  146.  
  147.   ______________________________________________________________________
  148.           ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1            *RIGHT*
  149.           ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1    *WRONG*
  150.   ______________________________________________________________________
  151.  
  152.   2.1.  LILO (LInux LOader)
  153.  
  154.   The LILO program (LInux LOader) written by Werner Almesberger is the
  155.   most commonly used. It has the ability to boot various kernels, and
  156.   stores the configuration information in a plain text file. Most
  157.   distributions ship with LILO as the default boot-loader. LILO can boot
  158.   DOS, OS/2, Linux, FreeBSD, etc. without any difficulties, and is quite
  159.   flexible.
  160.  
  161.   A typical configuration will have LILO stop and print LILO: shortly
  162.   after you turn on your computer. It will then wait for a few seconds
  163.   for any optional input from the user, and failing that it will then
  164.   boot the default system. Typical system labels that people use in the
  165.   LILO configuration files are linux and backup and msdos. If you want
  166.   to type in a boot argument, you type it in here, after typing in the
  167.   system label that you want LILO to boot from, as shown in the example
  168.   below.
  169.  
  170.   ______________________________________________________________________
  171.           LILO: linux root=/dev/hda1
  172.   ______________________________________________________________________
  173.  
  174.   LILO comes with excellent documentation, and for the purposes of boot
  175.   args discussed here, the LILO append= command is of significant
  176.   importance when one wants to add a boot time argument as a permanent
  177.   addition to the LILO config file.  You simply add something like
  178.   append = "foo=bar" to the /etc/lilo.conf file. It can either be added
  179.   at the top of the config file, making it apply to all sections, or to
  180.   a single system section by adding it inside an image= section.  Please
  181.   see the LILO documentation for a more complete description.
  182.  
  183.   2.2.  LoadLin
  184.  
  185.   The other commonly used Linux loader is `LoadLin' which is a DOS
  186.   program that has the capability to launch a Linux kernel from the DOS
  187.   prompt (with boot-args) assuming that certain resources are available.
  188.   This is good for people that use DOS and want to launch into Linux
  189.   from DOS.
  190.  
  191.   It is also very useful if you have certain hardware which relies on
  192.   the supplied DOS driver to put the hardware into a known state. A
  193.   common example is `SoundBlaster Compatible' sound cards that require
  194.   the DOS driver to set a few proprietary registers to put the card into
  195.   a SB compatible mode. Booting DOS with the supplied driver, and then
  196.   loading Linux from the DOS prompt with LOADLIN.EXE avoids the reset of
  197.   the card that happens if one rebooted instead. Thus the card is left
  198.   in a SB compatible mode and hence is useable under Linux.
  199.  
  200.   There are also other programs that can be used to boot Linux.  For a
  201.   complete list, please look at the programs available on your local
  202.   Linux ftp mirror, under system/Linux-boot/.
  203.  
  204.   2.3.  The ``rdev'' utility
  205.  
  206.   There are a few of the kernel boot parameters that have their default
  207.   values stored in various bytes in the kernel image itself.  There is a
  208.   utility called rdev that is installed on most systems that knows where
  209.   these values are, and how to change them.  It can also change things
  210.   that have no kernel boot argument equivalent, such as the default
  211.   video mode used.
  212.  
  213.   The rdev utility is usually also aliased to swapdev, ramsize, vidmode
  214.   and rootflags. These are the five things that rdev can change, those
  215.   being the root device, the swap device, the RAM disk parameters, the
  216.   default video mode, and the readonly/readwrite setting of root device.
  217.  
  218.   More information on rdev can be found by typing rdev -h or by reading
  219.   the supplied man page (man rdev).
  220.  
  221.   2.4.  How the Kernel Sorts the Arguments
  222.  
  223.   Most of the boot args take the form of:
  224.  
  225.   ______________________________________________________________________
  226.           name[=value_1][,value_2]...[,value_11]
  227.   ______________________________________________________________________
  228.  
  229.   where `name' is a unique keyword that is used to identify what part of
  230.   the kernel the associated values (if any) are to be given to. Multiple
  231.   boot args are just a space separated list of the above format. Note
  232.   the limit of 11 is real, as the present code only handles 11 comma
  233.   separated parameters per keyword. (However, you can re-use the same
  234.   keyword with up to an additional 11 parameters in unusually
  235.   complicated situations, assuming the setup function supports it.)
  236.   Also note that the kernel splits the list into a maximum of ten
  237.   integer arguments, and a following string, so you can't really supply
  238.   11 integers unless you convert the 11th arg from a string to an int in
  239.   the driver itself.
  240.  
  241.   Most of the sorting goes on in linux/init/main.c.  First, the kernel
  242.   checks to see if the argument is any of the special arguments `root=',
  243.   `ro', `rw', or `debug'.  The meaning of these special arguments is
  244.   described further on in the document.
  245.  
  246.   Then it walks a list of setup functions (contained in the bootsetups
  247.   array) to see if the specified argument string (such as `foo') has
  248.   been associated with a setup function (foo_setup()) for a particular
  249.   device or part of the kernel. If you passed the kernel the line
  250.   foo=3,4,5,6,bar then the kernel would search the bootsetups array to
  251.   see if `foo' was registered. If it was, then it would call the setup
  252.   function associated with `foo' (foo_setup()) and hand it the integer
  253.   arguments 3, 4, 5 and 6 as given on the kernel command line, and also
  254.   hand it the string argument bar.
  255.  
  256.   2.5.  Setting Environment Variables.
  257.  
  258.   Anything of the form `foo=bar' that is not accepted as a setup
  259.   function as described above is then interpreted as an environment
  260.   variable to be set. A (useless?) example would be to use `TERM=vt100'
  261.   as a boot argument.
  262.  
  263.   2.6.  Passing Arguments to the `init' program
  264.  
  265.   Any remaining arguments that were not picked up by the kernel and were
  266.   not interpreted as environment variables are then passed onto process
  267.   one, which is usually the init program. The most common argument that
  268.   is passed to the init process is the word single which instructs init
  269.   to boot the computer in single user mode, and not launch all the usual
  270.   daemons. Check the manual page for the version of init installed on
  271.   your system to see what arguments it accepts.
  272.  
  273.   3.  General Non-Device Specific Boot Args
  274.  
  275.   These are the boot arguments that are not related to any specific
  276.   device or peripheral. They are instead related to certain internal
  277.   kernel parameters, such as memory handling, ramdisk handling, root
  278.   file system handling and others.
  279.  
  280.   3.1.  Root Filesystem options
  281.  
  282.   The following options all pertain to how the kernel selects and
  283.   handles the root filesystem.
  284.  
  285.   3.1.1.  The `root=' Argument
  286.  
  287.   This argument tells the kernel what device is to be used as the root
  288.   filesystem while booting. The default of this setting is the value of
  289.   the root device of the system that the kernel was built on.  For
  290.   example, if the kernel in question was built on a system that used
  291.   `/dev/hda1' as the root partition, then the default root device would
  292.   be `/dev/hda1'.  To override this default value, and select the second
  293.   floppy drive as the root device, one would use `root=/dev/fd1'.
  294.  
  295.   Valid root devices are any of the following devices:
  296.  
  297.   (1) /dev/hdaN to /dev/hddN, which is partition N on ST-506 compatible
  298.   disk `a to d'.
  299.  
  300.   (2) /dev/sdaN to /dev/sdeN, which is partition N on SCSI compatible
  301.   disk `a to e'.
  302.  
  303.   (3) /dev/xdaN to /dev/xdbN, which is partition N on XT compatible disk
  304.   `a to b'.
  305.  
  306.   (4) /dev/fdN, which is floppy disk drive number N. Having N=0 would be
  307.   the DOS `A:' drive, and N=1 would be `B:'.
  308.  
  309.   (5) /dev/nfs, which is not really a device, but rather a flag to tell
  310.   the kernel to get the root fs via the network.
  311.  
  312.   The more awkward and less portable numeric specification of the above
  313.   possible disk devices in major/minor format is also accepted. (e.g.
  314.   /dev/sda3 is major 8, minor 3, so you could use root=0x803 as an
  315.   alternative.)
  316.  
  317.   This is one of the few kernel boot arguments that has its default
  318.   stored in the kernel image, and which can thus be altered with the
  319.   rdev utility.
  320.  
  321.   3.1.2.  The `ro' Argument
  322.  
  323.   When the kernel boots, it needs a root filesystem to read basic things
  324.   off of. This is the root filesystem that is mounted at boot. However,
  325.   if the root filesystem is mounted with write access, you can not
  326.   reliably check the filesystem integrity with half-written files in
  327.   progress. The `ro' option tells the kernel to mount the root
  328.   filesystem as `readonly' so that any filesystem consistency check
  329.   programs (fsck) can safely assume that there are no half-written files
  330.   in progress while performing the check. No programs or processes can
  331.   write to files on the filesystem in question until it is `remounted'
  332.   as read/write capable.
  333.  
  334.   This is one of the few kernel boot arguments that has its default
  335.   stored in the kernel image, and which can thus be altered with the
  336.   rdev utility.
  337.  
  338.   3.1.3.  The `rw' Argument
  339.  
  340.   This is the exact opposite of the above, in that it tells the kernel
  341.   to mount the root filesystem as read/write. The default is to mount
  342.   the root filesystem as read/write anyway. Do not run any `fsck' type
  343.   programs on a filesystem that is mounted read/write.
  344.  
  345.   The same value stored in the image file mentioned above is also used
  346.   for this parameter, accessible via rdev.
  347.  
  348.   3.2.  Options Relating to RAM Disk Management
  349.  
  350.   The following options all relate to how the kernel handles the RAM
  351.   disk device, which is usually used for bootstrapping machines during
  352.   the install phase, or for machines with modular drivers that need to
  353.   be installed to access the root filesystem.
  354.  
  355.   3.2.1.  The `ramdisk_start=' Argument
  356.  
  357.   To allow a kernel image to reside on a floppy disk along with a
  358.   compressed ramdisk image, the `ramdisk_start=<offset>' command was
  359.   added. The kernel can't be included into the compressed ramdisk
  360.   filesystem image, because it needs to be stored starting at block zero
  361.   so that the BIOS can load the bootsector and then the kernel can
  362.   bootstrap itself to get going.
  363.  
  364.   Note: If you are using an uncompressed ramdisk image, then the kernel
  365.   can be a part of the filesystem image that is being loaded into the
  366.   ramdisk, and the floppy can be booted with LILO, or the two can be
  367.   separate as is done for the compressed images.
  368.  
  369.   If you are using a two-disk boot/root setup (kernel on disk 1, ramdisk
  370.   image on disk 2) then the ramdisk would start at block zero, and an
  371.   offset of zero would be used. Since this is the default value, you
  372.   would not need to actually use the command at all.
  373.  
  374.   3.2.2.  The `load_ramdisk=' Argument
  375.  
  376.   This parameter tells the kernel whether it is to try to load a ramdisk
  377.   image or not. Specifying `load_ramdisk=1' will tell the kernel to load
  378.   a floppy into the ramdisk. The default value is zero, meaning that the
  379.   kernel should not try to load a ramdisk.
  380.  
  381.   Please see the file linux/Documentation/ramdisk.txt for a complete
  382.   description of the new boot time arguments, and how to use them. A
  383.   description of how this parameter can be set and stored in the kernel
  384.   image via `rdev' is also described.
  385.  
  386.   3.2.3.  The `prompt_ramdisk=' Argument
  387.  
  388.   This parameter tells the kernel whether or not to give you a prompt
  389.   asking you to insert the floppy containing the ramdisk image. In a
  390.   single floppy configuration the ramdisk image is on the same floppy as
  391.   the kernel that just finished loading/booting and so a prompt is not
  392.   needed. In this case one can use `prompt_ramdisk=0'. In a two floppy
  393.   configuration, you will need the chance to switch disks, and thus
  394.   `prompt_ramdisk=1' can be used. Since this is the default value, it
  395.   doesn't really need to be specified. ( (Historical note: Sneaky people
  396.   used to use the `vga=ask' LILO option to temporarily pause the boot
  397.   process and allow a chance to switch from boot to root floppy.)
  398.  
  399.   Please see the file linux/Documentation/ramdisk.txt for a complete
  400.   description of the new boot time arguments, and how to use them. A
  401.   description of how this parameter can be set and stored in the kernel
  402.   image via `rdev' is also described.
  403.  
  404.   3.2.4.  The `ramdisk_size=' Argument
  405.  
  406.   While it is true that the ramdisk grows dynamically as required, there
  407.   is an upper bound on its size so that it doesn't consume all available
  408.   RAM and leave you in a mess. The default is 4096 (i.e. 4MB) which
  409.   should be large enough for most needs. You can override the default to
  410.   a bigger or smaller size with this boot argument.
  411.  
  412.   Please see the file linux/Documentation/ramdisk.txt for a complete
  413.   description of the new boot time arguments, and how to use them. A
  414.   description of how this parameter can be set and stored in the kernel
  415.   image via `rdev' is also described.
  416.  
  417.   3.2.5.  The `ramdisk=' Argument (obsolete)
  418.  
  419.   (NOTE: This argument is obsolete, and should not be used except on
  420.   kernels v1.3.47 and older. The commands that should be used for the
  421.   ramdisk device are documented above.)
  422.  
  423.   This specifies the size in kB of the RAM disk device.  For example, if
  424.   one wished to have a root filesystem on a 1.44MB floppy loaded into
  425.   the RAM disk device, they would use:
  426.  
  427.   ______________________________________________________________________
  428.           ramdisk=1440
  429.   ______________________________________________________________________
  430.  
  431.   This is one of the few kernel boot arguments that has its default
  432.   stored in the kernel image, and which can thus be altered with the
  433.   rdev utility.
  434.  
  435.   3.2.6.  The `noinitrd' (initial RAM disk) Argument
  436.  
  437.   The v2.x and newer kernels have a feature where the root filesystem is
  438.   initially a RAM disk, and the kernel executes /linuxrc on that RAM
  439.   image. This feature is typically used to allow loading of modules
  440.   needed to mount the real root filesystem (e.g. load the SCSI driver
  441.   modules stored in the RAM disk image, and then mount the real root
  442.   filesystem on a SCSI disk.)
  443.  
  444.   The actual `noinitrd' argument determines what happens to the initrd
  445.   data after the kernel has booted.  When specified, instead of
  446.   converting it to a RAM disk, it is accessible via /dev/initrd, which
  447.   can be read once before the RAM is released back to the system. For
  448.   full details on using the initial RAM disk, please consult
  449.   linux/Documentation/initrd.txt. In addition, the most recent versions
  450.   of LILO and LOADLIN should have additional useful information.
  451.  
  452.   3.3.  Boot Arguments Related to Memory Handling
  453.  
  454.   The following arguments alter how linux detects or handles the
  455.   physical and virtual memory of your system.
  456.  
  457.   3.3.1.  The `mem=' Argument
  458.  
  459.   This argument has two purposes: The original purpose was to specify
  460.   the amount of installed memory (or a value less than that if you
  461.   wanted to limit the amount of memory available to linux). The second
  462.   (and hardly used) purpose is to specify mem=nopentium which tells the
  463.   linux kernel to not use the 4MB page table performance feature.
  464.  
  465.   The original BIOS call defined in the PC specification  that returns
  466.   the amount of installed memory was only designed to be able to report
  467.   up to 64MB. (Yes, another lack of foresight, just like the 1024
  468.   cylinder disks... sigh.) Linux uses this BIOS call at boot to
  469.   determine how much memory is installed.  If you have more than 64MB of
  470.   RAM installed, you can use this boot argument to tell Linux how much
  471.   memory you have.  Here is a quote from Linus on usage of the mem=
  472.   parameter.
  473.  
  474.   ``The kernel will accept any `mem=xx' parameter you give it, and if it
  475.   turns out that you lied to it, it will crash horribly sooner or later.
  476.   The parameter indicates the highest addressable RAM address, so
  477.   `mem=0x1000000' means you have 16MB of memory, for example.  For a
  478.   96MB machine this would be `mem=0x6000000'.
  479.  
  480.   NOTE NOTE NOTE: some machines might use the top of memory for BIOS
  481.   cacheing or whatever, so you might not actually have up to the full
  482.   96MB addressable.  The reverse is also true: some chipsets will map
  483.   the physical memory that is covered by the BIOS area into the area
  484.   just past the top of memory, so the top-of-mem might actually be 96MB
  485.   + 384kB for example.  If you tell linux that it has more memory than
  486.   it actually does have, bad things will happen: maybe not at once, but
  487.   surely eventually.''
  488.  
  489.   Note that the argument does not have to be in hex, and the suffixes
  490.   `k' and `M' (case insensitive) can be used to specify kilobytes and
  491.   Megabytes, respectively. (A `k' will cause a 10 bit shift on your
  492.   value, and a `M' will cause a 20 bit shift.)  The above warning still
  493.   holds, in that a 96MB machine may work with mem=97920k but fail with
  494.   either mem=98304k or mem=96M.
  495.  
  496.   3.3.2.  The `swap=' Argument
  497.  
  498.   This allows the user to tune some of the virtual memory (VM)
  499.   parameters that are related to swapping to disk. It accepts the
  500.   following eight parameters:
  501.  
  502.   ______________________________________________________________________
  503.           MAX_PAGE_AGE
  504.           PAGE_ADVANCE
  505.           PAGE_DECLINE
  506.           PAGE_INITIAL_AGE
  507.           AGE_CLUSTER_FRACT
  508.           AGE_CLUSTER_MIN
  509.           PAGEOUT_WEIGHT
  510.           BUFFEROUT_WEIGHT
  511.   ______________________________________________________________________
  512.  
  513.   Interested hackers are advised to have a read of linux/mm/swap.c and
  514.   also make note of the goodies in /proc/sys/vm.
  515.  
  516.   3.3.3.  The `buff=' Argument
  517.  
  518.   Similar to the `swap=' argument, this allows the user to tune some of
  519.   the parameters related to buffer memory management.  It accepts the
  520.   following six parameters:
  521.  
  522.   ______________________________________________________________________
  523.           MAX_BUFF_AGE
  524.           BUFF_ADVANCE
  525.           BUFF_DECLINE
  526.           BUFF_INITIAL_AGE
  527.           BUFFEROUT_WEIGHT
  528.           BUFFERMEM_GRACE
  529.   ______________________________________________________________________
  530.  
  531.   Interested hackers are advised to have a read of linux/mm/swap.c and
  532.   also make note of the goodies in /proc/sys/vm.
  533.  
  534.   3.4.  Boot Arguments for NFS Root Filesystem
  535.  
  536.   Linux supports systems such as diskless workstations via having their
  537.   root filesystem as NFS (Network FileSystem).  These arguments are used
  538.   to tell the diskless workstation which machine it is to get its system
  539.   from. Also note that the argument root=/dev/nfs is required. Detailed
  540.   information on using an NFS root fs is in the file
  541.   linux/Documentation/nfsroot.txt. You should read that file, as the
  542.   following is only a quick summary taken directly from that file.
  543.  
  544.   3.4.1.  The `nfsroot=' Argument
  545.  
  546.   This argument tells the kernel which machine, what directory and what
  547.   NFS options to use for the root filesystem. The form of the argument
  548.   is as follows:
  549.  
  550.   ______________________________________________________________________
  551.           nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
  552.   ______________________________________________________________________
  553.  
  554.   If the nfsroot parameter is not given on the command line, the default
  555.   `/tftpboot/%s' will be used. The other options are as follows:
  556.  
  557.   <server-ip> -- Specifies the IP address of the NFS server. If this
  558.   field is not given, the default address as determined by the nfsaddrs
  559.   variable (see below) is used. One use of this parameter is for example
  560.   to allow using different servers for RARP and NFS. Usually you can
  561.   leave this blank.
  562.  
  563.   <root-dir> -- Name of the directory on the server to mount as root. If
  564.   there is a `%s' token in the string, the token will be replaced by the
  565.   ASCII-representation of the client's IP address.
  566.  
  567.   <nfs-options> -- Standard NFS options. All options are separated by
  568.   commas.  If the options field is not given, the following defaults
  569.   will be used:
  570.  
  571.           port            = as given by server portmap daemon
  572.           rsize           = 1024
  573.           wsize           = 1024
  574.           timeo           = 7
  575.           retrans         = 3
  576.           acregmin        = 3
  577.           acregmax        = 60
  578.           acdirmin        = 30
  579.           acdirmax        = 60
  580.           flags           = hard, nointr, noposix, cto, ac
  581.  
  582.   3.4.2.  The `nfsaddrs=' Argument
  583.  
  584.   This boot argument sets up the various network interface addresses
  585.   that are required to communicate over the network. If this argument is
  586.   not given, then the kernel tries to use RARP and/or BOOTP to figure
  587.   out these parameters. The form is as follows:
  588.  
  589.   ______________________________________________________________________
  590.           nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>
  591.   ______________________________________________________________________
  592.  
  593.   <my-ip> -- IP address of the client. If empty, the address will either
  594.   be determined by RARP or BOOTP. What protocol is used de- pends on
  595.   what has been enabled during kernel configuration and on the <auto>
  596.   parameter. If this parameter is not empty, neither RARP nor BOOTP will
  597.   be used.
  598.  
  599.   <serv-ip> -- IP address of the NFS server. If RARP is used to
  600.   determine the client address and this parameter is NOT empty only
  601.   replies from the specified server are accepted. To use different RARP
  602.   and NFS server, specify your RARP server here (or leave it blank), and
  603.   specify your NFS server in the nfsroot parameter (see above). If this
  604.   entry is blank the address of the server is used which answered the
  605.   RARP or BOOTP request.
  606.  
  607.   <gw-ip> -- IP address of a gateway if the server in on a different
  608.   subnet. If this entry is empty no gateway is used and the server is
  609.   assumed to be on the local network, unless a value has been received
  610.   by BOOTP.
  611.  
  612.   <netmask> -- Netmask for local network interface. If this is empty,
  613.   the netmask is derived from the client IP address, unless a value has
  614.   been received by BOOTP.
  615.  
  616.   <name> -- Name of the client. If empty, the client IP address is used
  617.   in ASCII-notation, or the value received by BOOTP.
  618.  
  619.   <dev> -- Name of network device to use. If this is empty, all devices
  620.   are used for RARP requests, and the first one found for BOOTP. For NFS
  621.   the device is used on which either RARP or BOOTP replies have been
  622.   received. If you only have one device you can safely leave this blank.
  623.  
  624.   <auto> -- Method to use for autoconfiguration. If this is either
  625.   `rarp' or `bootp' the specified protocol is being used.  If the value
  626.   is `both' or empty, both protocols are used so far as they have been
  627.   enabled during kernel configuration Using 'none' means no
  628.   autoconfiguration. In this case you have to specify all necessary
  629.   values in the fields before.
  630.   The <auto> parameter can appear alone as the value to the nfsaddrs
  631.   parameter (without all the `:' characters before) in which case
  632.   autoconfiguration is used. However, the `none' value is not available
  633.   in that case.
  634.  
  635.   3.5.  Other Misc. Kernel Boot Arguments
  636.  
  637.   These various boot arguments let the user tune certain internal kernel
  638.   parameters.
  639.  
  640.   3.5.1.  The `debug' Argument
  641.  
  642.   The kernel communicates important (and not-so important) messages to
  643.   the operator via the printk() function.  If the message is considered
  644.   important, the printk() function will put a copy on the present
  645.   console as well as handing it off to the klogd() facility so that it
  646.   gets logged to disk. The reason for printing important messages to the
  647.   console as well as logging them to disk is because under unfortunate
  648.   circumstances (e.g. a disk failure) the message won't make it to disk
  649.   and will be lost.
  650.  
  651.   The threshold for what is and what isn't considered important is set
  652.   by the console_loglevel variable. The default is to log anything more
  653.   important than DEBUG (level 7) to the console. (These levels are
  654.   defined in the include file kernel.h) Specifying debug as a boot
  655.   argument will set the console loglevel to 10, so that all kernel
  656.   messages appear on the console.
  657.  
  658.   The console loglevel can usually also be set at run time via an option
  659.   to the klogd() program. Check the man page for the version installed
  660.   on your system to see how to do this.
  661.  
  662.   3.5.2.  The `init=' Argument
  663.  
  664.   The kernel defaults to starting the `init' program at boot, which then
  665.   takes care of setting up the computer for users via launching getty
  666.   programs, running `rc' scripts and the like.  The kernel first looks
  667.   for /sbin/init, then /etc/init (depreciated), and as a last resort, it
  668.   will try to use /bin/sh (possibly on /etc/rc).  If for example, your
  669.   init program got corrupted and thus stopped you from being able to
  670.   boot, you could simply use the boot prompt init=/bin/sh which would
  671.   drop you directly into a shell at boot, allowing you to replace the
  672.   corrupted program.
  673.  
  674.   3.5.3.  The `no387' Argument
  675.  
  676.   Some i387 coprocessor chips have bugs that show up when used in 32 bit
  677.   protected mode. For example, some of the early ULSI-387 chips would
  678.   cause solid lockups while performing floating point calculations,
  679.   apparently due to a bug in the FRSAV/FRRESTOR instructions.  Using the
  680.   `no387' boot argument causes Linux to ignore the math coprocessor even
  681.   if you have one. Of course you must then have your kernel compiled
  682.   with math emulation support! This may also be useful if you have one
  683.   of those really old 386 machines that could use an 80287 FPU, as linux
  684.   can't use an 80287.
  685.  
  686.   3.5.4.  The `no-hlt' Argument
  687.  
  688.   The i386 (and successors thereof) family of CPUs have a `hlt'
  689.   instruction which tells the CPU that nothing is going to happen until
  690.   an external device (keyboard, modem, disk, etc.) calls upon the CPU to
  691.   do a task. This allows the CPU to enter a `low-power' mode where it
  692.   sits like a zombie until an external device wakes it up (usually via
  693.   an interrupt).  Some of the early i486DX-100 chips had a problem  with
  694.   the `hlt' instruction, in that they couldn't reliably return to
  695.   operating mode after this instruction was used. Using the `no-hlt'
  696.   instruction tells Linux to just run an infinite loop when there is
  697.   nothing else to do, and to not halt your CPU when there is no
  698.   activity. This allows people with these broken chips to use Linux,
  699.   although they would be well advised to seek a replacement through a
  700.   warranty where possible.
  701.  
  702.   3.5.5.  The `no-scroll' Argument
  703.  
  704.   Using this argument at boot disables scrolling features that make it
  705.   difficult to use Braille terminals.
  706.  
  707.   3.5.6.  The `panic=' Argument
  708.  
  709.   In the unlikely event of a kernel panic (i.e. an internal error that
  710.   has been detected by the kernel, and which the kernel decides is
  711.   serious enough to moan loudly and then halt everything), the default
  712.   behaviour is to just sit there until someone comes along and notices
  713.   the panic message on the screen and reboots the machine.  However if a
  714.   machine is running unattended in an isolated location it may be
  715.   desirable for it to automatically reset itself so that the machine
  716.   comes back on line. For example, using panic=30 at boot would cause
  717.   the kernel to try and reboot itself 30 seconds after the kernel panic
  718.   happened. A value of zero gives the default behaviour, which is to
  719.   wait forever.
  720.  
  721.   Note that this timeout value can also be read and set via the
  722.   /proc/sys/kernel/panic sysctl interface.
  723.  
  724.   3.5.7.  The `profile=' Argument
  725.  
  726.   Kernel developers can enable an option that allows them to profile how
  727.   and where the kernel is spending its CPU cycles in an effort to
  728.   maximize efficiency and performance. This option lets you set the
  729.   profile shift count at boot. Typically it is set to two. You can also
  730.   compile your kernel with profiling enabled by default. In either case,
  731.   you need a tool such as readprofile.c that can make use of the
  732.   /proc/profile output.
  733.  
  734.   3.5.8.  The `reboot=' Argument
  735.  
  736.   This option controls the type of reboot that Linux will do when it
  737.   resets the computer (typically via /sbin/init handling a Control-Alt-
  738.   Delete). The default as of late v2.0 kernels is to do a `cold' reboot
  739.   (i.e. full reset, BIOS does memory check, etc.) instead of a `warm'
  740.   reboot (i.e. no full reset, no memory check). It was changed to be
  741.   cold by default since that tends to work on cheap/broken hardware that
  742.   fails to reboot when a warm reboot is requested. To get the old
  743.   behaviour (i.e. warm reboots) use reboot=w or in fact any word that
  744.   starts with w will work.
  745.  
  746.   Why would you bother? Some disk controllers with cache memory on board
  747.   can sense a warm reboot, and flush any cached data to disk. Upon a
  748.   cold boot, the card may be reset and the write-back data in your cache
  749.   card's memory is lost. Others have reported systems that take a long
  750.   time to go through the memory check, and/or SCSI BIOSes that take
  751.   longer to initialize on a cold boot as a good reason to use warm
  752.   reboots.
  753.  
  754.   3.5.9.  The `reserve=' Argument
  755.  
  756.   This is used to protect I/O port regions from probes.  The form of the
  757.   command is:
  758.  
  759.        reserve=iobase,extent[,iobase,extent]...
  760.  
  761.   In some machines it may be necessary to prevent device drivers from
  762.   checking for devices (auto-probing) in a specific region. This may be
  763.   because of poorly designed hardware that causes the boot to freeze
  764.   (such as some ethercards), hardware that is mistakenly identified,
  765.   hardware whose state is changed by an earlier probe, or merely
  766.   hardware you don't want the kernel to initialize.
  767.  
  768.   The reserve boot-time argument addresses this problem by specifying an
  769.   I/O port region that shouldn't be probed. That region is reserved in
  770.   the kernel's port registration table as if a device has already been
  771.   found in that region (with the name reserved).  Note that this
  772.   mechanism shouldn't be necessary on most machines.  Only when there is
  773.   a problem or special case would it be necessary to use this.
  774.  
  775.   The I/O ports in the specified region are protected against device
  776.   probes that do a check_region() prior to probing blindly into a region
  777.   of I/O space. This was put in to be used when some driver was hanging
  778.   on a NE2000, or misidentifying some other device as its own.  A
  779.   correct device driver shouldn't probe a reserved region, unless
  780.   another boot argument explicitly specifies that it do so.  This
  781.   implies that reserve will most often be used with some other boot
  782.   argument. Hence if you specify a reserve region to protect a specific
  783.   device, you must generally specify an explicit probe for that device.
  784.   Most drivers ignore the port registration table if they are given an
  785.   explicit address.
  786.  
  787.   For example, the boot line
  788.  
  789.   ______________________________________________________________________
  790.           reserve=0x300,32  blah=0x300
  791.   ______________________________________________________________________
  792.  
  793.   keeps all device drivers except the driver for `blah' from probing
  794.   0x300-0x31f.
  795.  
  796.   As usual with boot-time specifiers there is an 11 parameter limit,
  797.   thus you can only specify 5 reserved regions per reserve keyword.
  798.   Multiple reserve specifiers will work if you have an unusually
  799.   complicated request.
  800.  
  801.   3.5.10.  The `vga=' Argument
  802.  
  803.   Note that this is not really a boot argument. It is an option that is
  804.   interpreted by LILO and not by the kernel like all the other boot
  805.   arguments are. However its use has become so common that it deserves a
  806.   mention here. It can also be set via using rdev -v or equivalently
  807.   vidmode on the vmlinuz file.  This allows the setup code to use the
  808.   video BIOS to change the default display mode before actually booting
  809.   the Linux kernel. Typical modes are 80x50, 132x44 and so on. The best
  810.   way to use this option is to start with vga=ask which will prompt you
  811.   with a list of various modes that you can use with your video adapter
  812.   before booting the kernel. Once you have the number from the above
  813.   list that you want to use, you can later put it in place of the `ask'.
  814.   For more information, please see the file linux/Documentation/svga.txt
  815.   that comes with all recent kernel versions.
  816.  
  817.   Note that newer kernels (v2.1 and up) have the setup code that changes
  818.   the video mode as an option, listed as Video mode selection support so
  819.   you need to enable this option if you want to use this feature.
  820.  
  821.   4.  Boot Arguments for SCSI Peripherals.
  822.  
  823.   This section contains the descriptions of the boot args that are used
  824.   for passing information about the installed SCSI host adapters, and
  825.   SCSI devices.
  826.  
  827.   4.1.  Arguments for Mid-level Drivers
  828.  
  829.   The mid level drivers handle things like disks, CD-ROMs and tapes
  830.   without getting into host adapter specifics.
  831.  
  832.   4.1.1.  Maximum Probed LUNs (`max_scsi_luns=')
  833.  
  834.   Each SCSI device can have a number of `sub-devices' contained within
  835.   itself. The most common example is one of the new SCSI CD-ROMs that
  836.   handle more than one disk at a time.  Each CD is addressed as a
  837.   `Logical Unit Number' (LUN) of that particular device. But most
  838.   devices, such as hard disks, tape drives and such are only one device,
  839.   and will be assigned to LUN zero.
  840.  
  841.   The problem arises with single LUN devices with bad firmware.  Some
  842.   poorly designed SCSI devices (old and unfortunately new) can not
  843.   handle being probed for LUNs not equal to zero. They will respond by
  844.   locking up, and possibly taking the whole SCSI bus down with them.
  845.  
  846.   Newer kernels have the configuration option that allows you to set the
  847.   maximum number of probed LUNs. The default is to only probe LUN zero,
  848.   to avoid the problem described above.
  849.  
  850.   To specify the number of probed LUNs at boot, one enters
  851.   `max_scsi_luns=n' as a boot arg, where n is a number between one and
  852.   eight. To avoid problems as described above, one would use n=1 to
  853.   avoid upsetting such broken devices
  854.  
  855.   4.1.2.  Parameters for the SCSI Tape Driver (`st=')
  856.  
  857.   Some boot time configuration of the SCSI tape driver can be achieved
  858.   by using the following:
  859.   ______________________________________________________________________
  860.           st=buf_size[,write_threshold[,max_bufs]]
  861.   ______________________________________________________________________
  862.  
  863.   The first two numbers are specified in units of kB.  The default
  864.   buf_size is 32kB, and the maximum size that can be specified is a
  865.   ridiculous 16384kB.  The write_threshold is the value at which the
  866.   buffer is committed to tape, with a default value of 30kB.  The
  867.   maximum number of buffers varies with the number of drives detected,
  868.   and has a default of two. An example usage would be:
  869.  
  870.   ______________________________________________________________________
  871.           st=32,30,2
  872.   ______________________________________________________________________
  873.  
  874.   Full details can be found in the README.st file that is in the scsi
  875.   directory of the kernel source tree.
  876.  
  877.   4.2.  Arguments for SCSI Host Adapters
  878.  
  879.   General notation for this section:
  880.  
  881.   iobase -- the first I/O port that the SCSI host occupies.  These are
  882.   specified in hexidecimal notation, and usually lie in the range from
  883.   0x200 to 0x3ff.
  884.  
  885.   irq -- the hardware interrupt that the card is configured to use.
  886.   Valid values will be dependent on the card in question, but will
  887.   usually be 5, 7, 9, 10, 11, 12, and 15. The other values are usually
  888.   used for common peripherals like IDE hard disks, floppies, serial
  889.   ports, etc.
  890.  
  891.   dma -- the DMA (Direct Memory Access) channel that the card uses.
  892.   Typically only applies to bus-mastering cards.  PCI and VLB cards are
  893.   native bus-masters, and do not require and ISA DMA channel.
  894.  
  895.   scsi-id -- the ID that the host adapter uses to identify itself on the
  896.   SCSI bus. Only some host adapters allow you to change this value, as
  897.   most have it permanently specified internally. The usual default value
  898.   is seven, but the Seagate and Future Domain TMC-950 boards use six.
  899.  
  900.   parity -- whether the SCSI host adapter expects the attached devices
  901.   to supply a parity value with all information exchanges.  Specifying a
  902.   one indicates parity checking is enabled, and a zero disables parity
  903.   checking. Again, not all adapters will support selection of parity
  904.   behaviour as a boot argument.
  905.  
  906.   4.2.1.  Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI
  907.   (`aha152x=')
  908.  
  909.   The aha numbers refer to cards and the aic numbers refer to the actual
  910.   SCSI chip on these type of cards, including the Soundblaster-16 SCSI.
  911.  
  912.   The probe code for these SCSI hosts looks for an installed BIOS, and
  913.   if none is present, the probe will not find your card. Then you will
  914.   have to use a boot argument of the form:
  915.  
  916.   ______________________________________________________________________
  917.            aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]]
  918.   ______________________________________________________________________
  919.  
  920.   Note that if the driver was compiled with debugging enabled, a sixth
  921.   value can be specified to set the debug level.
  922.  
  923.   All the parameters are as described at the top of this section, and
  924.   the reconnect value will allow device disconnect/reconnect if a non-
  925.   zero value is used. An example usage is as follows:
  926.  
  927.   ______________________________________________________________________
  928.           aha152x=0x340,11,7,1
  929.   ______________________________________________________________________
  930.  
  931.   Note that the parameters must be specified in order, meaning that if
  932.   you want to specify a parity setting, then you will have to specify an
  933.   iobase, irq, scsi-id and reconnect value as well.
  934.  
  935.   4.2.2.  Adaptec aha154x (`aha1542=')
  936.  
  937.   These are the aha154x series cards. The aha1542 series cards have an
  938.   i82077 floppy controller onboard, while the aha1540 series cards do
  939.   not. These are busmastering cards, and have parameters to set the
  940.   ``fairness'' that is used to share the bus with other devices. The
  941.   boot argument looks like the following.
  942.  
  943.   ______________________________________________________________________
  944.           aha1542=iobase[,buson,busoff[,dmaspeed]]
  945.   ______________________________________________________________________
  946.  
  947.   Valid iobase values are usually one of: 0x130, 0x134, 0x230, 0x234,
  948.   0x330, 0x334.  Clone cards may permit other values.
  949.  
  950.   The buson, busoff values refer to the number of microseconds that the
  951.   card dominates the ISA bus. The defaults are 11us on, and 4us off, so
  952.   that other cards (such as an ISA LANCE Ethernet card) have a chance to
  953.   get access to the ISA bus.
  954.  
  955.   The dmaspeed value refers to the rate (in MB/s) at which the DMA
  956.   (Direct Memory Access) transfers proceed at. The default is 5MB/s.
  957.   Newer revision cards allow you to select this value as part of the
  958.   soft-configuration, older cards use jumpers. You can use values up to
  959.   10MB/s assuming that your motherboard is capable of handling it.
  960.   Experiment with caution if using values over 5MB/s.
  961.  
  962.   4.2.3.  Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=')
  963.  
  964.   These boards can accept an argument of the form:
  965.  
  966.   ______________________________________________________________________
  967.           aic7xxx=extended,no_reset
  968.   ______________________________________________________________________
  969.  
  970.   The extended value, if non-zero, indicates that extended translation
  971.   for large disks is enabled. The no_reset value, if non-zero, tells the
  972.   driver not to reset the SCSI bus when setting up the host adaptor at
  973.   boot.
  974.  
  975.   4.2.4.  AdvanSys SCSI Host Adaptors (`advansys=')
  976.  
  977.   The AdvanSys driver can accept up to four i/o addresses that will be
  978.   probed for an AdvanSys SCSI card. Note that these values (if used) do
  979.   not effect EISA or PCI probing in any way.  They are only used for
  980.   probing ISA and VLB cards.  In addition, if the driver has been
  981.   compiled with debugging enabled, the level of debugging output can be
  982.   set by adding an 0xdeb[0-f] parameter. The 0-f allows setting the
  983.   level of the debugging messages to any of 16 levels of verbosity.
  984.  
  985.   4.2.5.  Always IN2000 Host Adaptor (`in2000=')
  986.  
  987.   Unlike other SCSI host boot arguments, the IN2000 driver uses ASCII
  988.   string prefixes for most of its integer arguments. Here is a list of
  989.   the supported arguments:
  990.  
  991.   ioport:addr -- Where addr is IO address of a (usually ROM-less) card.
  992.  
  993.   noreset -- No optional args. Prevents SCSI bus reset at boot time.
  994.  
  995.   nosync:x -- x is a bitmask where the 1st 7 bits correspond with the 7
  996.   possible SCSI devices (bit 0 for device #0, etc).  Set a bit to
  997.   PREVENT sync negotiation on that device.  The driver default is sync
  998.   DISABLED on all devices.
  999.  
  1000.   period:ns -- ns is the minimum # of nanoseconds in a SCSI data
  1001.   transfer period. Default is 500; acceptable values are 250 to 1000.
  1002.  
  1003.   disconnect:x -- x = 0 to never allow disconnects, 2 to always allow
  1004.   them.  x = 1 does 'adaptive' disconnects, which is the default and
  1005.   generally the best choice.
  1006.  
  1007.   debug:x If `DEBUGGING_ON' is defined, x is a bitmask that causes
  1008.   various types of debug output to printed - see the DB_xxx defines in
  1009.   in2000.h
  1010.  
  1011.   proc:x -- If `PROC_INTERFACE' is defined, x is a bitmask that
  1012.   determines how the /proc interface works and what it does - see the
  1013.   PR_xxx defines in in2000.h
  1014.  
  1015.   Some example usages are listed below:
  1016.  
  1017.   ______________________________________________________________________
  1018.           in2000=ioport:0x220,noreset
  1019.           in2000=period:250,disconnect:2,nosync:0x03
  1020.           in2000=debug:0x1e
  1021.           in2000=proc:3
  1022.   ______________________________________________________________________
  1023.  
  1024.   4.2.6.  AMD AM53C974 based hardware (`AM53C974=')
  1025.  
  1026.   Unlike other drivers, this one does not use boot parameters to
  1027.   communicate i/o, IRQ or DMA channels. (Since the AM53C974 is a PCI
  1028.   device, there shouldn't be a need to do so.)  Instead, the parameters
  1029.   are used to communicate the transfer modes and rates that are to be
  1030.   used between the host and the target device. This is best described
  1031.   with an example:
  1032.  
  1033.   ______________________________________________________________________
  1034.           AM53C974=7,2,8,15
  1035.   ______________________________________________________________________
  1036.  
  1037.   This would be interpreted as follows: `For communication between the
  1038.   controller with SCSI-ID 7 and the device with SCSI-ID 2, a transfer
  1039.   rate of 8MHz in synchronous mode with max. 15 bytes offset should be
  1040.   negotiated.' More details can be found in the file
  1041.   linux/drivers/scsi/README.AM53C974
  1042.  
  1043.   4.2.7.  BusLogic SCSI Hosts with v1.2 kernels (`buslogic=')
  1044.  
  1045.   In older kernels, the buslogic driver accepts only one parameter, that
  1046.   being the I/O base. It expects that to be one of the following valid
  1047.   values: 0x130, 0x134, 0x230, 0x234, 0x330, 0x334.
  1048.  
  1049.   4.2.8.  BusLogic SCSI Hosts with v2.x kernels (`BusLogic=')
  1050.  
  1051.   With v2.x kernels, the BusLogic driver accepts many parameters.  (Note
  1052.   the case in the above; upper case B and L!!!).  The following detailed
  1053.   description is taken directly from Leonard N. Zubkoff's driver as
  1054.   included in the v2.0 kernel.
  1055.  
  1056.   For the BusLogic driver, a Kernel command line entry comprises the
  1057.   driver identifier "BusLogic=" optionally followed by a comma-separated
  1058.   sequence of integers and then optionally followed by a comma-separated
  1059.   sequence of strings.  Each command line entry applies to one BusLogic
  1060.   Host Adapter.  Multiple command line entries may be used in systems
  1061.   which contain multiple BusLogic Host Adapters.
  1062.  
  1063.   The first integer specified is the I/O Address at which the Host
  1064.   Adapter is located.  If unspecified, it defaults to 0 which means to
  1065.   apply this entry to the first BusLogic Host Adapter found during the
  1066.   default probe sequence.  If any I/O Address parameters are provided on
  1067.   the command line, then the default probe sequence is omitted.
  1068.  
  1069.   The second integer specified is the Tagged Queue Depth to use for
  1070.   Target Devices that support Tagged Queuing.  The Queue Depth is the
  1071.   number of SCSI commands that are allowed to be concurrently presented
  1072.   for execution.  If unspecified, it defaults to 0 which means to use a
  1073.   value determined automatically based on the Host Adapter's Total Queue
  1074.   Depth and the number, type, speed, and capabilities of the detected
  1075.   Target Devices.  For Host Adapters that require ISA Bounce Buffers,
  1076.   the Tagged Queue Depth is automatically set to
  1077.   BusLogic_TaggedQueueDepth_BB to avoid excessive preallocation of DMA
  1078.   Bounce Buffer memory.  Target Devices that do not support Tagged
  1079.   Queuing use a Queue Depth of BusLogic_UntaggedQueueDepth.
  1080.  
  1081.   The third integer specified is the Bus Settle Time in seconds.  This
  1082.   is the amount of time to wait between a Host Adapter Hard Reset which
  1083.   initiates a SCSI Bus Reset and issuing any SCSI Commands.  If
  1084.   unspecified, it defaults to 0 which means to use the value of
  1085.   BusLogic_DefaultBusSettleTime.
  1086.  
  1087.   The fourth integer specified is the Local Options.  If unspecified, it
  1088.   defaults to 0.  Note that Local Options are only applied to a specific
  1089.   Host Adapter.
  1090.  
  1091.   The fifth integer specified is the Global Options.  If unspecified, it
  1092.   defaults to 0.  Note that Global Options are applied across all Host
  1093.   Adapters.
  1094.  
  1095.   The string options are used to provide control over Tagged Queuing,
  1096.   Error Recovery, and Host Adapter Probing.
  1097.  
  1098.   The Tagged Queuing specification begins with "TQ:" and allows for
  1099.   explicitly specifying whether Tagged Queuing is permitted on Target
  1100.   Devices that support it.  The following specification options are
  1101.   available:
  1102.  
  1103.   TQ:Default -- Tagged Queuing will be permitted based on the firmware
  1104.   version of the BusLogic Host Adapter and based on whether the Tagged
  1105.   Queue Depth value allows queuing multiple commands.
  1106.  
  1107.   TQ:Enable -- Tagged Queuing will be enabled for all Target Devices on
  1108.   this Host Adapter overriding any limitation that would otherwise be
  1109.   imposed based on the Host Adapter firmware version.
  1110.  
  1111.   TQ:Disable -- Tagged Queuing will be disabled for all Target Devices
  1112.   on this Host Adapter.
  1113.  
  1114.   TQ:<Per-Target-Spec> -- Tagged Queuing will be controlled individually
  1115.   for each Target Device. <Per-Target-Spec> is a sequence of "Y", "N",
  1116.   and "X" characters.  "Y" enabled Tagged Queuing, "N" disables Tagged
  1117.   Queuing, and "X" accepts the default based on the firmware version.
  1118.   The first character refers to Target Device 0, the second to Target
  1119.   Device 1, and so on; if the sequence of "Y", "N", and "X" characters
  1120.   does not cover all the Target Devices, unspecified characters are
  1121.   assumed to be "X".
  1122.  
  1123.   Note that explicitly requesting Tagged Queuing may lead to problems;
  1124.   this facility is provided primarily to allow disabling Tagged Queuing
  1125.   on Target Devices that do not implement it correctly.
  1126.  
  1127.   The Error Recovery Strategy specification begins with "ER:" and allows
  1128.   for explicitly specifying the Error Recovery action to be performed
  1129.   when ResetCommand is called due to a SCSI Command failing to complete
  1130.   successfully.  The following specification options are available:
  1131.  
  1132.   ER:Default -- Error Recovery will select between the Hard Reset and
  1133.   Bus Device Reset options based on the recommendation of the SCSI
  1134.   Subsystem.
  1135.  
  1136.   ER:HardReset -- Error Recovery will initiate a Host Adapter Hard Reset
  1137.   which also causes a SCSI Bus Reset.
  1138.  
  1139.   ER:BusDeviceReset -- Error Recovery will send a Bus Device Reset
  1140.   message to the individual Target Device causing the error.  If Error
  1141.   Recovery is again initiated for this Target Device and no SCSI Command
  1142.   to this Target Device has completed successfully since the Bus Device
  1143.   Reset message was sent, then a Hard Reset will be attempted.
  1144.  
  1145.   ER:None -- Error Recovery will be suppressed.  This option should only
  1146.   be selected if a SCSI Bus Reset or Bus Device Reset will cause the
  1147.   Target Device to fail completely and unrecoverably.
  1148.  
  1149.   ER:<Per-Target-Spec> -- Error Recovery will be controlled individually
  1150.   for each Target Device. <Per-Target-Spec> is a sequence of "D", "H",
  1151.   "B", and "N" characters.  "D" selects Default, "H" selects Hard Reset,
  1152.   "B" selects Bus Device Reset, and "N" selects None.  The first
  1153.   character refers to Target Device 0, the second to Target Device 1,
  1154.   and so on; if the sequence of "D", "H", "B", and "N" characters does
  1155.   not cover all the possible Target Devices, unspecified characters are
  1156.   assumed to be "D".
  1157.  
  1158.   The Host Adapter Probing specification comprises the following
  1159.   strings:
  1160.  
  1161.   NoProbe -- No probing of any kind is to be performed, and hence no
  1162.   BusLogic Host Adapters will be detected.
  1163.  
  1164.   NoProbeISA -- No probing of the standard ISA I/O Addresses will be
  1165.   done, and hence only PCI Host Adapters will be detected.
  1166.  
  1167.   NoSortPCI -- PCI Host Adapters will be enumerated in the order
  1168.   provided by the PCI BIOS, ignoring any setting of the AutoSCSI "Use
  1169.   Bus And Device # For PCI Scanning Seq." option.
  1170.  
  1171.   4.2.9.  EATA SCSI Cards (`eata=')
  1172.  
  1173.   As of late v2.0 kernels, the EATA drivers will accept a boot argument
  1174.   to specify the i/o base(s) to be probed. It is of the form:
  1175.  
  1176.   ______________________________________________________________________
  1177.           eata=iobase1[,iobase2][,iobase3]...[,iobaseN]
  1178.   ______________________________________________________________________
  1179.  
  1180.   The driver will probe the addresses in the order that they are listed.
  1181.  
  1182.   4.2.10.  Future Domain TMC-8xx, TMC-950 (`tmc8xx=')
  1183.  
  1184.   The probe code for these SCSI hosts looks for an installed BIOS, and
  1185.   if none is present, the probe will not find your card. Or, if the
  1186.   signature string of your BIOS is not recognized then it will also not
  1187.   be found. In either case, you will then have to use a boot argument of
  1188.   the form:
  1189.  
  1190.   ______________________________________________________________________
  1191.           tmc8xx=mem_base,irq
  1192.   ______________________________________________________________________
  1193.  
  1194.   The mem_base value is the value of the memory mapped I/O region that
  1195.   the card uses. This will usually be one of the following values:
  1196.   0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000.
  1197.  
  1198.   4.2.11.  Future Domain TMC-16xx, TMC-3260, AHA-2920 (`fdomain=')
  1199.  
  1200.   The driver detects these cards according to a list of known BIOS ROM
  1201.   signatures. For a full list of known BIOS revisions, please see
  1202.   linux/drivers/scsi/fdomain.c as it has a lot of information at the top
  1203.   of that file. If your BIOS is not known to the driver, you can use an
  1204.   override of the form:
  1205.  
  1206.   ______________________________________________________________________
  1207.           fdomain=iobase,irq[,scsi_id]
  1208.   ______________________________________________________________________
  1209.  
  1210.   4.2.12.  IOMEGA Parallel Port / ZIP drive (`ppa=')
  1211.  
  1212.   This driver is for the IOMEGA Parallel Port SCSI adapter which is
  1213.   embedded into the IOMEGA ZIP drives. It may also work with the
  1214.   original IOMEGA PPA3 device. The boot argument for this driver is of
  1215.   the form:
  1216.  
  1217.   ______________________________________________________________________
  1218.           ppa=iobase,speed_high,speed_low,nybble
  1219.   ______________________________________________________________________
  1220.  
  1221.   with all but iobase being optionally specified values. If you wish to
  1222.   alter any of the three optional parameters, you are advised to read
  1223.   linux/drivers/scsi/README.ppa for details of what they control.
  1224.  
  1225.   4.2.13.  NCR5380 based controllers (`ncr5380=')
  1226.  
  1227.   Depending on your board, the 5380 can be either i/o mapped or memory
  1228.   mapped. (An address below 0x400 usually implies i/o mapping, but PCI
  1229.   and EISA hardware use i/o addresses above 0x3ff.) In either case, you
  1230.   specify the address, the IRQ value and the DMA channel value. An
  1231.   example for an i/o mapped card would be: ncr5380=0x350,5,3. If the
  1232.   card doesn't use interrupts, then an IRQ value of 255 (0xff) will
  1233.   disable interrupts. An IRQ value of 254 means to autoprobe. More
  1234.   details can be found in the file linux/drivers/scsi/README.g_NCR5380
  1235.  
  1236.   4.2.14.  NCR53c400 based controllers (`ncr53c400=')
  1237.  
  1238.   The generic 53c400 support is done with the same driver as the generic
  1239.   5380 support mentioned above. The boot argument is identical to the
  1240.   above with the exception that no DMA channel is used by the 53c400.
  1241.  
  1242.   4.2.15.  NCR53c406a based controllers (`ncr53c406a=')
  1243.  
  1244.   This driver uses a boot argument of the form:
  1245.  
  1246.   ______________________________________________________________________
  1247.           ncr53c406a=PORTBASE,IRQ,FASTPIO
  1248.   ______________________________________________________________________
  1249.  
  1250.   where the IRQ and FASTPIO parameters are optional. An interrupt value
  1251.   of zero disables the use of interrupts. Using a value of one for the
  1252.   FASTPIO parameter enables the use of insl and outsl instructions
  1253.   instead of the single-byte inb and outb instructions. The driver can
  1254.   also use DMA as a compile-time option.
  1255.  
  1256.   4.2.16.  Pro Audio Spectrum (`pas16=')
  1257.  
  1258.   The PAS16 uses a NCR5380 SCSI chip, and newer models support jumper-
  1259.   less configuration. The boot argument is of the form:
  1260.  
  1261.   ______________________________________________________________________
  1262.           pas16=iobase,irq
  1263.   ______________________________________________________________________
  1264.  
  1265.   The only difference is that you can specify an IRQ value of 255, which
  1266.   will tell the driver to work without using interrupts, albeit at a
  1267.   performance loss. The iobase is usually 0x388.
  1268.  
  1269.   4.2.17.  Seagate ST-0x (`st0x=')
  1270.  
  1271.   The probe code for these SCSI hosts looks for an installed BIOS, and
  1272.   if none is present, the probe will not find your card. Or, if the
  1273.   signature string of your BIOS is not recognized then it will also not
  1274.   be found. In either case, you will then have to use a boot argument of
  1275.   the form:
  1276.  
  1277.   ______________________________________________________________________
  1278.           st0x=mem_base,irq
  1279.   ______________________________________________________________________
  1280.  
  1281.   The mem_base value is the value of the memory mapped I/O region that
  1282.   the card uses. This will usually be one of the following values:
  1283.   0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000.
  1284.  
  1285.   4.2.18.  Trantor T128 (`t128=')
  1286.  
  1287.   These cards are also based on the NCR5380 chip, and accept the
  1288.   following options:
  1289.  
  1290.   ______________________________________________________________________
  1291.           t128=mem_base,irq
  1292.   ______________________________________________________________________
  1293.  
  1294.   The valid values for mem_base are as follows: 0xcc000, 0xc8000,
  1295.   0xdc000, 0xd8000.
  1296.  
  1297.   4.2.19.  Ultrastor SCSI cards (`u14-34f=')
  1298.  
  1299.   Note that there appears to be two independent drivers for this card,
  1300.   namely CONFIG_SCSI_U14_34F that uses u14-34f.c and
  1301.   CONFIG_SCSI_ULTRASTOR that uses ultrastor.c. It is the u14-34f one
  1302.   that (as of late v2.0 kernels) accepts a boot argument of the form:
  1303.  
  1304.   ______________________________________________________________________
  1305.           u14-34f=iobase1[,iobase2][,iobase3]...[,iobaseN]
  1306.   ______________________________________________________________________
  1307.  
  1308.   The driver will probe the addresses in the order that they are listed.
  1309.  
  1310.   4.2.20.  Western Digital WD7000 cards (`wd7000=')
  1311.  
  1312.   The driver probe for the wd7000 looks for a known BIOS ROM string and
  1313.   knows about a few standard configuration settings.  If it doesn't come
  1314.   up with the correct values for your card, or you have an unrecognized
  1315.   BIOS version, you can use a boot argument of the form:
  1316.  
  1317.   ______________________________________________________________________
  1318.           wd7000=irq,dma,iobase
  1319.   ______________________________________________________________________
  1320.  
  1321.   4.3.  SCSI Host Adapters that don't Accept Boot Args
  1322.  
  1323.   At present, the following SCSI cards do not make use of any boot-time
  1324.   parameters. In some cases, you can hard-wire values by directly
  1325.   editing the driver itself, if required.
  1326.  
  1327.           Adaptec aha1740 (EISA probing),
  1328.           NCR53c7xx,8xx (PCI, both drivers)
  1329.           Qlogic Fast (0x230, 0x330)
  1330.           Qlogic ISP (PCI)
  1331.  
  1332.   5.  Hard Disks
  1333.  
  1334.   This section lists all the boot args associated with standard MFM/RLL,
  1335.   ST-506, XT, and IDE disk drive devices.  Note that both the IDE and
  1336.   the generic ST-506 HD driver both accept the `hd=' option.
  1337.  
  1338.   5.1.  IDE Disk/CD-ROM Driver Parameters
  1339.  
  1340.   The IDE driver accepts a number of parameters, which range from disk
  1341.   geometry specifications, to support for advanced or broken controller
  1342.   chips. The following is a summary of all the possible boot arguments.
  1343.   For full details, you really should consult the file ide.txt in the
  1344.   linux/Documentation directory, from which this summary was extracted.
  1345.  
  1346.   ______________________________________________________________________
  1347.  
  1348.    "hdx="  is recognized for all "x" from "a" to "h", such as "hdc".
  1349.    "idex=" is recognized for all "x" from "0" to "3", such as "ide1".
  1350.  
  1351.    "hdx=noprobe"          : drive may be present, but do not probe for it
  1352.    "hdx=none"             : drive is NOT present, ignore cmos and do not probe
  1353.    "hdx=nowerr"           : ignore the WRERR_STAT bit on this drive
  1354.    "hdx=cdrom"            : drive is present, and is a cdrom drive
  1355.    "hdx=cyl,head,sect"    : disk drive is present, with specified geometry
  1356.    "hdx=autotune"         : driver will attempt to tune interface speed
  1357.                                   to the fastest PIO mode supported,
  1358.                                   if possible for this drive only.
  1359.                                   Not fully supported by all chipset types,
  1360.                                   and quite likely to cause trouble with
  1361.                                   older/odd IDE drives.
  1362.  
  1363.    "idex=noprobe"         : do not attempt to access/use this interface
  1364.    "idex=base"            : probe for an interface at the addr specified,
  1365.                                   where "base" is usually 0x1f0 or 0x170
  1366.                                   and "ctl" is assumed to be "base"+0x206
  1367.    "idex=base,ctl"        : specify both base and ctl
  1368.    "idex=base,ctl,irq"    : specify base, ctl, and irq number
  1369.    "idex=autotune"        : driver will attempt to tune interface speed
  1370.                                   to the fastest PIO mode supported,
  1371.                                   for all drives on this interface.
  1372.                                   Not fully supported by all chipset types,
  1373.                                   and quite likely to cause trouble with
  1374.                                   older/odd IDE drives.
  1375.    "idex=noautotune"      : driver will NOT attempt to tune interface speed
  1376.                                   This is the default for most chipsets,
  1377.                                   except the cmd640.
  1378.    "idex=serialize"       : do not overlap operations on idex and ide(x^1)
  1379.   ______________________________________________________________________
  1380.  
  1381.   The following are valid ONLY on ide0, and the defaults for the
  1382.   base,ctl ports must not be altered.
  1383.  
  1384.   ______________________________________________________________________
  1385.  
  1386.    "ide0=dtc2278"         : probe/support DTC2278 interface
  1387.    "ide0=ht6560b"         : probe/support HT6560B interface
  1388.    "ide0=cmd640_vlb"      : *REQUIRED* for VLB cards with the CMD640 chip
  1389.                             (not for PCI -- automatically detected)
  1390.    "ide0=qd6580"          : probe/support qd6580 interface
  1391.    "ide0=ali14xx"         : probe/support ali14xx chipsets (ALI M1439/M1445)
  1392.    "ide0=umc8672"         : probe/support umc8672 chipsets
  1393.   ______________________________________________________________________
  1394.  
  1395.   Everything else is rejected with a "BAD OPTION" message.
  1396.  
  1397.   5.2.  Standard ST-506 Disk Driver Options (`hd=')
  1398.  
  1399.   The standard disk driver can accept geometry arguments for the disks
  1400.   similar to the IDE driver. Note however that it only expects three
  1401.   values (C/H/S) -- any more or any less and it will silently ignore
  1402.   you. Also, it only accepts `hd=' as an argument, i.e. `hda=', `hdb='
  1403.   and so on are not valid here. The format is as follows:
  1404.  
  1405.   ______________________________________________________________________
  1406.           hd=cyls,heads,sects
  1407.   ______________________________________________________________________
  1408.  
  1409.   If there are two disks installed, the above is repeated with the
  1410.   geometry parameters of the second disk.
  1411.  
  1412.   5.3.  XT Disk Driver Options (`xd=')
  1413.  
  1414.   If you are unfortunate enough to be using one of these old 8 bit cards
  1415.   that move data at a whopping 125kB/s then here is the scoop.  The
  1416.   probe code for these cards looks for an installed BIOS, and if none is
  1417.   present, the probe will not find your card. Or, if the signature
  1418.   string of your BIOS is not recognized then it will also not be found.
  1419.   In either case, you will then have to use a boot argument of the form:
  1420.  
  1421.   ______________________________________________________________________
  1422.           xd=type,irq,iobase,dma_chan
  1423.   ______________________________________________________________________
  1424.  
  1425.   The type value specifies the particular manufacturer of the card, and
  1426.   are as follows: 0=generic; 1=DTC; 2,3,4=Western Digital,
  1427.   5,6,7=Seagate; 8=OMTI. The only difference between multiple types from
  1428.   the same manufacturer is the BIOS string used for detection, which is
  1429.   not used if the type is specified.
  1430.  
  1431.   The xd_setup() function does no checking on the values, and assumes
  1432.   that you entered all four values. Don't disappoint it.  Here is an
  1433.   example usage for a WD1002 controller with the BIOS disabled/removed,
  1434.   using the `default' XT controller parameters:
  1435.  
  1436.   ______________________________________________________________________
  1437.           xd=2,5,0x320,3
  1438.   ______________________________________________________________________
  1439.  
  1440.   6.  CD-ROMs (Non-SCSI/ATAPI/IDE)
  1441.  
  1442.   This section lists all the possible boot args pertaining to CD-ROM
  1443.   devices. Note that this does not include SCSI or IDE/ATAPI CD-ROMs.
  1444.   See the appropriate section(s) for those types of CD-ROMs.
  1445.  
  1446.   Note that most of these CD-ROMs have documentation files that you
  1447.   should read, and they are all in one handy place:
  1448.   linux/Documentation/cdrom.
  1449.   6.1.  The Aztech Interface (`aztcd=')
  1450.  
  1451.   The syntax for this type of card is:
  1452.  
  1453.   ______________________________________________________________________
  1454.           aztcd=iobase[,magic_number]
  1455.   ______________________________________________________________________
  1456.  
  1457.   If you set the magic_number to 0x79 then the driver will try and run
  1458.   anyway in the event of an unknown firmware version. All other values
  1459.   are ignored.
  1460.  
  1461.   6.2.  The CDU-31A and CDU-33A Sony Interface (`cdu31a=')
  1462.  
  1463.   This CD-ROM interface is found on some of the Pro Audio Spectrum sound
  1464.   cards, and other Sony supplied interface cards.  The syntax is as
  1465.   follows:
  1466.  
  1467.   ______________________________________________________________________
  1468.           cdu31a=iobase,[irq[,is_pas_card]]
  1469.   ______________________________________________________________________
  1470.  
  1471.   Specifying an IRQ value of zero tells the driver that hardware
  1472.   interrupts aren't supported (as on some PAS cards). If your card
  1473.   supports interrupts, you should use them as it cuts down on the CPU
  1474.   usage of the driver.
  1475.  
  1476.   The `is_pas_card' should be entered as `PAS' if using a Pro Audio
  1477.   Spectrum card, and otherwise it should not be specified at all.
  1478.  
  1479.   6.3.  The CDU-535 Sony Interface (`sonycd535=')
  1480.  
  1481.   The syntax for this CD-ROM interface is:
  1482.  
  1483.   ______________________________________________________________________
  1484.           sonycd535=iobase[,irq]
  1485.   ______________________________________________________________________
  1486.  
  1487.   A zero can be used for the I/O base as a `placeholder' if one wishes
  1488.   to specify an IRQ value.
  1489.  
  1490.   6.4.  The GoldStar Interface (`gscd=')
  1491.  
  1492.   The syntax for this CD-ROM interface is:
  1493.  
  1494.   ______________________________________________________________________
  1495.           gscd=iobase
  1496.   ______________________________________________________________________
  1497.  
  1498.   6.5.  The ISP16 Interface (`isp16=')
  1499.  
  1500.   The syntax for this CD-ROM interface is:
  1501.  
  1502.   ______________________________________________________________________
  1503.           isp16=[port[,irq[,dma]]][[,]drive_type]
  1504.   ______________________________________________________________________
  1505.  
  1506.   Using a zero for irq or dma means that they are not used. The
  1507.   allowable values for drive_type are noisp16, Sanyo, Panasonic, Sony,
  1508.   and Mitsumi.  Using noisp16 disables the driver altogether.
  1509.  
  1510.   6.6.  The Mitsumi Standard Interface (`mcd=')
  1511.  
  1512.   The syntax for this CD-ROM interface is:
  1513.  
  1514.   ______________________________________________________________________
  1515.           mcd=iobase,[irq[,wait_value]]
  1516.   ______________________________________________________________________
  1517.  
  1518.   The wait_value is used as an internal timeout value for people who are
  1519.   having problems with their drive, and may or may not be implemented
  1520.   depending on a compile time DEFINE.
  1521.  
  1522.   6.7.  The Mitsumi XA/MultiSession Interface (`mcdx=')
  1523.  
  1524.   At present this `experimental' driver has a setup function, but no
  1525.   parameters are implemented yet (as of 1.3.15).  This is for the same
  1526.   hardware as above, but the driver has extended features.
  1527.  
  1528.   6.8.  The Optics Storage Interface (`optcd=')
  1529.  
  1530.   The syntax for this type of card is:
  1531.  
  1532.   ______________________________________________________________________
  1533.           optcd=iobase
  1534.   ______________________________________________________________________
  1535.  
  1536.   6.9.  The Phillips CM206 Interface (`cm206=')
  1537.  
  1538.   The syntax for this type of card is:
  1539.  
  1540.   ______________________________________________________________________
  1541.           cm206=[iobase][,irq]
  1542.   ______________________________________________________________________
  1543.  
  1544.   The driver assumes numbers between 3 and 11 are IRQ values, and
  1545.   numbers between 0x300 and 0x370 are I/O ports, so you can specify one,
  1546.   or both numbers, in any order.  It also accepts `cm206=auto' to enable
  1547.   autoprobing.
  1548.  
  1549.   6.10.  The Sanyo Interface (`sjcd=')
  1550.  
  1551.   The syntax for this type of card is:
  1552.  
  1553.   ______________________________________________________________________
  1554.           sjcd=iobase[,irq[,dma_channel]]
  1555.   ______________________________________________________________________
  1556.  
  1557.   6.11.  The SoundBlaster Pro Interface (`sbpcd=')
  1558.  
  1559.   The syntax for this type of card is:
  1560.  
  1561.   ______________________________________________________________________
  1562.           sbpcd=iobase,type
  1563.   ______________________________________________________________________
  1564.  
  1565.   where type is one of the following (case sensitive) strings:
  1566.   `SoundBlaster', `LaserMate', or `SPEA'.  The I/O base is that of the
  1567.   CD-ROM interface, and not that of the sound portion of the card.
  1568.  
  1569.   7.  Other Hardware Devices
  1570.  
  1571.   Any other devices that didn't fit into any of the above categories got
  1572.   lumped together here.
  1573.  
  1574.   7.1.  Ethernet Devices (`ether=')
  1575.  
  1576.   Different drivers make use of different parameters, but they all at
  1577.   least share having an IRQ, an I/O port base value, and a name. In its
  1578.   most generic form, it looks something like this:
  1579.  
  1580.   ______________________________________________________________________
  1581.           ether=irq,iobase[,param_1[,param_2,...param_8]]],name
  1582.   ______________________________________________________________________
  1583.  
  1584.   The first non-numeric argument is taken as the name.  The param_n
  1585.   values (if applicable) usually have different meanings for each
  1586.   different card/driver.  Typical param_n values are used to specify
  1587.   things like shared memory address, interface selection, DMA channel
  1588.   and the like.
  1589.  
  1590.   The most common use of this parameter is to force probing for a second
  1591.   ethercard, as the default is to only probe for one. This can be
  1592.   accomplished with a simple:
  1593.  
  1594.   ______________________________________________________________________
  1595.           ether=0,0,eth1
  1596.   ______________________________________________________________________
  1597.  
  1598.   Note that the values of zero for the IRQ and I/O base in the above
  1599.   example tell the driver(s) to autoprobe.
  1600.  
  1601.   IMPORTANT NOTE TO MODULE USERS: The above will not force a probe for a
  1602.   second card if you are using the driver(s) as run time loadable
  1603.   modules (instead of having them complied into the kernel).  Most Linux
  1604.   distributions use a bare bones kernel combined with a large selection
  1605.   of modular drivers.  The ether= only applies to drivers compiled
  1606.   directly into the kernel.
  1607.  
  1608.   The Ethernet-HowTo has complete and extensive documentation on using
  1609.   multiple cards and on the card/driver specific implementation of the
  1610.   param_n values where used.  Interested readers should refer to the
  1611.   section in that document on their particular card for more complete
  1612.   information.  Ethernet-HowTo
  1613.   <http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html>
  1614.  
  1615.   7.2.  The Floppy Disk Driver (`floppy=')
  1616.  
  1617.   There are many floppy driver options, and they are all listed in
  1618.   README.fd in linux/drivers/block. This information is taken directly
  1619.   from that file.
  1620.  
  1621.   floppy=mask,allowed_drive_mask
  1622.  
  1623.   Sets the bitmask of allowed drives to mask. By default, only units 0
  1624.   and 1 of each floppy controller are allowed. This is done because
  1625.   certain non-standard hardware (ASUS PCI motherboards) mess up the
  1626.   keyboard when accessing units 2 or 3. This option is somewhat
  1627.   obsoleted by the cmos option.
  1628.  
  1629.   floppy=all_drives
  1630.  
  1631.   Sets the bitmask of allowed drives to all drives. Use this if you have
  1632.   more than two drives connected to a floppy controller.
  1633.  
  1634.   floppy=asus_pci
  1635.  
  1636.   Sets the bitmask to allow only units 0 and 1. (The default)
  1637.  
  1638.   floppy=daring
  1639.  
  1640.   Tells the floppy driver that you have a well behaved floppy
  1641.   controller.  This allows more efficient and smoother operation, but
  1642.   may fail on certain controllers. This may speed up certain operations.
  1643.  
  1644.   floppy=0,daring
  1645.  
  1646.   Tells the floppy driver that your floppy controller should be used
  1647.   with caution.
  1648.  
  1649.   floppy=one_fdc
  1650.  
  1651.   Tells the floppy driver that you have only floppy controller (default)
  1652.  
  1653.   floppy=two_fdc or floppy=address,two_fdc
  1654.  
  1655.   Tells the floppy driver that you have two floppy controllers. The
  1656.   second floppy controller is assumed to be at address. If address is
  1657.   not given, 0x370 is assumed.
  1658.  
  1659.   floppy=thinkpad
  1660.  
  1661.   Tells the floppy driver that you have a Thinkpad. Thinkpads use an
  1662.   inverted convention for the disk change line.
  1663.  
  1664.   floppy=0,thinkpad
  1665.  
  1666.   Tells the floppy driver that you don't have a Thinkpad.
  1667.  
  1668.   floppy=drive,type,cmos
  1669.  
  1670.   Sets the cmos type of drive to type.  Additionally, this drive is
  1671.   allowed in the bitmask. This is useful if you have more than two
  1672.   floppy drives (only two can be described in the physical cmos), or if
  1673.   your BIOS uses non-standard CMOS types.  Setting the CMOS to 0 for the
  1674.   first two drives (default) makes the floppy driver read the physical
  1675.   cmos for those drives.
  1676.  
  1677.   floppy=unexpected_interrupts
  1678.  
  1679.   Print a warning message when an unexpected interrupt is received
  1680.   (default behaviour)
  1681.  
  1682.   floppy=no_unexpected_interrupts or floppy=L40SX
  1683.  
  1684.   Don't print a message when an unexpected interrupt is received. This
  1685.   is needed on IBM L40SX laptops in certain video modes. (There seems to
  1686.   be an interaction between video and floppy. The unexpected interrupts
  1687.   only affect performance, and can safely be ignored.)
  1688.  
  1689.   7.3.  The Sound Driver (`sound=')
  1690.  
  1691.   The sound driver can also accept boot args to override the compiled in
  1692.   values. This is not recommended, as it is rather complex. It is (was?)
  1693.   described in the Readme.Linux file, in linux/drivers/sound. It accepts
  1694.   a boot arg of the form:
  1695.  
  1696.   ______________________________________________________________________
  1697.           sound=device1[,device2[,device3...[,device11]]]
  1698.   ______________________________________________________________________
  1699.  
  1700.   where each deviceN value is of the following format 0xTaaaId and the
  1701.   bytes are used as follows:
  1702.  
  1703.   T - device type: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
  1704.   7=SB16-MPU401
  1705.  
  1706.   aaa - I/O address in hex.
  1707.  
  1708.   I - interrupt line in hex (i.e 10=a, 11=b, ...)
  1709.  
  1710.   d - DMA channel.
  1711.  
  1712.   As you can see it gets pretty messy, and you are better off to compile
  1713.   in your own personal values as recommended. Using a boot arg of
  1714.   `sound=0' will disable the sound driver entirely.
  1715.   7.4.  The Bus Mouse Driver (`bmouse=')
  1716.  
  1717.   The busmouse driver only accepts one parameter, that being the
  1718.   hardware IRQ value to be used.
  1719.  
  1720.   7.5.  The MS Bus Mouse Driver (`msmouse=')
  1721.  
  1722.   The MS mouse driver only accepts one parameter, that being the
  1723.   hardware IRQ value to be used.
  1724.  
  1725.   7.6.  The Printer Driver (`lp=')
  1726.  
  1727.   As of kernels newer than 1.3.75, you can tell the printer driver what
  1728.   ports to use and what ports not to use. The latter comes in handy if
  1729.   you don't want the printer driver to claim all available parallel
  1730.   ports, so that other drivers (e.g. PLIP, PPA) can use them instead.
  1731.  
  1732.   The format of the argument is multiple i/o, IRQ pairs. For example,
  1733.   lp=0x3bc,0,0x378,7 would use the port at 0x3bc in IRQ-less (polling)
  1734.   mode, and use IRQ 7 for the port at 0x378. The port at 0x278 (if any)
  1735.   would not be probed, since autoprobing only takes place in the absence
  1736.   of a `lp=' argument. To disable the printer driver entirely, one can
  1737.   use lp=0.
  1738.  
  1739.   7.7.  The ICN ISDN driver (`icn=')
  1740.  
  1741.   This ISDN driver expects a boot argument of the form:
  1742.  
  1743.   ______________________________________________________________________
  1744.           icn=iobase,membase,icn_id1,icn_id2
  1745.   ______________________________________________________________________
  1746.  
  1747.   where iobase is the i/o port address of the card, membase is the
  1748.   shared memory base address of the card, and the two icn_id are unique
  1749.   ASCII string identifiers.
  1750.  
  1751.   7.8.  The PCBIT ISDN driver (`pcbit=')
  1752.  
  1753.   This boot argument takes integer pair arguments of the form:
  1754.  
  1755.   ______________________________________________________________________
  1756.           pcbit=membase1,irq1[,membase2,irq2]
  1757.   ______________________________________________________________________
  1758.  
  1759.   where membaseN is the shared memory base of the N'th card, and irqN is
  1760.   the interrupt setting of the N'th card. The default is IRQ 5 and
  1761.   membase 0xD0000.
  1762.  
  1763.   7.9.  The Teles ISDN driver (`teles=')
  1764.  
  1765.   This ISDN driver expects a boot argument of the form:
  1766.  
  1767.   ______________________________________________________________________
  1768.           teles=iobase,irq,membase,protocol,teles_id
  1769.   ______________________________________________________________________
  1770.  
  1771.   where iobase is the i/o port address of the card, membase is the
  1772.   shared memory base address of the card, irq is the interrupt channel
  1773.   the card uses, and teles_id is the unique ASCII string identifier.
  1774.  
  1775.   7.10.  The DigiBoard Driver (`digi=')
  1776.  
  1777.   The DigiBoard driver accepts a string of six comma separated
  1778.   identifiers or integers.  The 6 values in order are:
  1779.  
  1780.           Enable/Disable this card
  1781.           Type of card: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
  1782.           Enable/Disable alternate pin arrangement
  1783.           Number of ports on this card
  1784.           I/O Port where card is configured (in HEX if using string identifiers)
  1785.           Base of memory window (in HEX if using string identifiers)
  1786.  
  1787.   An example of a correct boot prompt argument (in both identifier and
  1788.   integer form) is:
  1789.  
  1790.   ______________________________________________________________________
  1791.           digi=E,PC/Xi,D,16,200,D0000
  1792.           digi=1,0,0,16,512,851968
  1793.   ______________________________________________________________________
  1794.  
  1795.   Note that the driver defaults to an i/o of 0x200 and a shared memory
  1796.   base of 0xD0000 in the absence of a digi= boot argument.  There is no
  1797.   autoprobing performed. More details can be found in the file
  1798.   linux/Documentation/digiboard.txt.
  1799.  
  1800.   7.11.  The RISCom/8 Multiport Serial Driver (`riscom8=')
  1801.  
  1802.   Up to four boards can be supported by supplying four unique i/o port
  1803.   values for each individual board installed.  Other details can be
  1804.   found in the file linux/Documentation/riscom8.txt.
  1805.  
  1806.   7.12.  The Baycom Serial/Parallel Radio Modem (`baycom=')
  1807.  
  1808.   The format of the boot argument for these devices is:
  1809.  
  1810.   ______________________________________________________________________
  1811.           baycom=modem,io,irq,options[,modem,io,irq,options]
  1812.   ______________________________________________________________________
  1813.  
  1814.   Using modem=1 means you have the ser12 device, modem=2 means you have
  1815.   the par96 device. Using options=0 means use hardware DCD, and
  1816.   options=1 means use software DCD. The io and irq are the i/o port base
  1817.   and interrupt settings as usual.  There is more details in the file
  1818.   README.baycom which is currently in the /linux/drivers/char/
  1819.   directory.
  1820.  
  1821.   8.  Closing
  1822.  
  1823.   If you have found any glaring typos, or outdated info in this
  1824.   document, please let me know. It is easy to overlook stuff.
  1825.  
  1826.   Thanks,
  1827.  
  1828.   Paul Gortmaker, gpg109@rsphy1.anu.edu.au
  1829.  
  1830.