  Linux BootPrompt HOWTO
  Paul Gortmaker (Paul.Gortmaker@anu.edu.au) 
  und Antje Faber (af@caldera.de)
  v1.13, 15 November 1997

  Dies ist das BootPrompt-Howto, welches eine Zusammenstellung aller
  mglichen Bootparameter ist, die whrend des Bootvorgangs an den
  Linux-Kernel geschickt werden knnen. Hierbei sind alle Kernel- und
  Gerteparameter eingeschlossen. Es wird diskutiert, wie der Kernel
  Bootparameter sortiert und man erhlt einen berblick ber die 
  bekannteste Software, die zum Booten von Linux-Kerneln verwendet 
  wird.


  1.  Einfhrung

  Der Kernel verfgt ber eine begrenzte Fhigkeit, whrend des
  Bootvorgangs Informationen in Form einer Kommandozeile anzunehmen;
  hnlich einer Parameterliste, die man einem Programm bergeben wrde.
  Dies dient im Allgemeinen dazu, den Kernel mit Informationen ber
  Hardwareparameter zu versorgen, die der Kernel alleine nicht bestimmen
  knnte oder die Werte zu vermeiden/bergehen die der Kernel
  andernfalls erkennen wrde.

  Will man jedoch lediglich ein Kernelimage direkt auf Diskette kopieren
  (z.B.  cp zImage /dev/fd0), dann erhlt man nicht die Mglichkeit,
  einen Parameter fr diesen Kernel festzulegen.  Deshalb werden die
  meisten Linux-Anwender Software wie LILO oder loadlin verwenden, die
  diese Parameter an den Kernel weiterleitet und ihn anschlieend
  bootet.

  WICHTIGER HINWEIS FR DIE VERWENDUNG VON MODULEN: Ein Kennzeichen von
  Bootprompt-Parametern ist die ausschlieliche Anwendung auf Hardware-
  Treiber, die direkt in den Kernel kompiliert werden. Sie haben  keine
  Auswirkung auf Treiber, die als Module geladen sind. Die meisten
  Distributionen verwenden Module. Sollten Zweifel bestehen, sollte man
  man depmod und man modprobe zusammen mit /etc/conf.modules anschauen.

  Die derzeitige Ausgabe beinhaltet alle Kernel bis einschlielich
  v2.0.31.  Es werden ebenfalls einige Eigenschaften dokumentiert, die
  einzigartig fr Entwicklungs-/Test- Kernels bis v2.1.6x sind.

  Das BootPrompt HOWTO wurde geschrieben und wird gepflegt von:

       Paul Gortmaker (Paul.Gortmaker@anu.edu.au)

  (Man beachte, da die speziellen Bootprompt-Parameter fr nicht-
  i386-Ports und -Gerte (speziell Atari/Amiga) zur Zeit undokumentiert
  sind.)

  1.1.  Ablehnungshinweise und Copyright

  Dieses Dokument ist kein Evangelium. Es bietet jedoch mglicherweise
  die aktuellste Information, die man finden kann.  Man ist selbst dafr
  verantwortlich, was mit der eigenen Hardware geschieht. Falls die
  Hardware in Rauch und Flammen aufgeht (...nahezu unmglich!) bernehme
  ich dafr keine Verantwortung.  DER AUTOR UND DIE BERSETZER
  BERNEHMEN KEINE HAFTUNG FR EVENTULLE FOLGESCHDEN AUFGRUND DER
  ANWENDUNG DER IN DIESEM DOKUMENT BEREITGESTELLTEN INFORMATIONEN.

  Falls Sie beabsichtigen, dieses Dokument in eine Verffentlichung
  aufzunehmen, nehmen Sie bitte Kontakt zu mir auf. Ich werde dann mein
  Mglichstes tun, Ihnen die aktuellsten Informationen zur Verfgung zu
  stellen. In der Vergangenheit wurden lngst berholte Versionen der
  Linux-HOWTO-Dokumente verffentlicht, was den Entwicklern stndigen
  Kummer bereitete, da sie mit Fragen geqult wurden, die in den neueren
  Versionen bereits beantwortet waren.

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische BootPrompt HOWTO, auf der dieses Dokument basiert, liegt bei
  Paul Gortmaker. Das Copyright fr die deutsche Version liegt bei
  Caldera GmbH (Antje Faber).

  Das Dokument darf gem der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dieses, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu zu informieren.

  1.2.  Weitere Dokumentationen

  Die aktuellsten Dokumentationen werden immer die Kernel-Quelldateien
  selbst sein. Aber keine Angst! Man bentigt keine
  Programmierkenntnisse zum Lesen der Anmerkungen in den Quelldateien.
  Will man zum Beispiel wissen, welche Parameter vom AHA1542 SCSI-
  Treiber erkannt werden, dann geht man ins Verzeichnis
  linux/drivers/scsi und wirft einen Blick auf die Datei aha1542.c  Dort
  findet man bereits in den ersten 100 Zeilen eine einfache Beschreibung
  (auf englisch) der Bootparameter, die der 1542-Treiber erkennt.

  Die nchstbeste Informationsquelle sind die Dokumentationsdateien, die
  mit dem Kernel selbst ausgeliefert werden. Es gibt bereits einige
  davon und die meisten knnen im Verzeichnis linux/Documentation und
  seinen Unterverzeichnissen gefunden werden. Das Verzeichnis linux
  findet sich normalerweise unter /usr/src/. Es existieren einige
  README.foo-Dateien, die sich in dem jeweiligen Treiber-Verzeichnis
  befinden (z.B. linux/drivers/XXX/, wobei XXX scsi, char oder net ist).

  Hat man sich fr bestimmte Bootparameter entschieden, und will nun
  herausfinden, wie man die Information an den Kernel weitergibt, sollte
  man einen Blick auf die Dokumentation werfen, die mit der Software zum
  Booten des Kernels ausgeliefert wird (z.B. LILO oder loadlin).
  Nachfolgend wird ein kurzer berblick gegeben, der jedoch keinen
  Ersatz fr die mit der Bootsoftware ausgelieferte Dokumentation
  darstellt.

  1.3.  Linux Newsgruppen

  Bei Fragen ber die Weitergabe von Bootparametern an den Kernel sollte
  man zuerst dieses Dokument lesen.  Falls diese und die oben genannte
  Dokumentation die Fragen nicht klren knnen, dann kann man sich an
  die Linux-Newsgruppen wenden. Natrlich sollte man es zuerst mit der
  Lektre der Newsgruppe versuchen, anstatt blindlings eine Frage zu
  schicken. Es ist nmlich gut mglich, da dieselbe Frage bereits
  gestellt wurde oder mglicherweise sogar zu den Frequently Asked
  Questions (hufig gestellte Fragen) gehrt.  Ein schneller Blick auf
  die Linux-FAQS ist eine gute Idee.  Die FAQ sollte man in der Nhe der
  Ursprungsseite dieses Dokuments finden.

  Allgemeine Fragen ber die Systemkonfiguration sollte man an die
  Newsgruppe

       de.comp.os.linux.misc

  richten. Wir bitten darum, sich an diese allgemeinen Richtlinien zu 
  halten und Fragen nicht an andere Gruppen zu stellen.

  1.4.  Neue Versionen dieses Dokuments

  Neue Versionen dieses Dokuments erhlt man via anonymous FTP unter

       sunsite.unc.edu:/pub/Linux/docs/HOWTO/

  Da SunSITE normalerweise stark beansprucht ist, ist man besser
  beraten, sich das Dokument von einer der Linux-FTP-Mirror-Sites zu
  holen. Neue Versionen erscheinen immer dann, sobald neue Informationen
  und/oder Treiber verfgbar sind.  Sollte diese Kopie hier mehr als ein
  paar Monate alt sein, sollte man sich mglicherweise informieren, ob
  nicht bereits eine neue Kopie existiert.

  Dieses Dokument wurde mit einem abgewandelten SGML-System geschrieben,
  welches speziell fr das Linux-HOWTO-Projekt geschaffen wurde. Es
  stehen verschiedene Ausgabe-Formate zur Verfgung, einschlielich
  Postscript, DVI, ASCII, HTML und bald auch TeXinfo.  Ich empfehle die
  Ansicht im HTML- (mit einem WWW-Browser) oder Postscript/DVI-Format.
  Beide enthalten Querverweise, die im ASCII-Format verlorengehen.

  2.  bersicht ber die Bootprompt-Parameter

  In diesem Abschnitt wird Software genannt, die zur Weiterleitung von
  Kernel-Bootparametern zum Kernel selbst verwendet werden kann. Es wird
  ebenfalls erklrt, wie die Parameter ausgefhrt werden, welchen
  Beschrnkungen sie unterliegen und wie sie zu jedem passenden Gert,
  fr das sie bestimmt sind, weitergeleitet werden.

  Man sollte unbedingt beachten, da innerhalb eines Bootparameters
  keine Leerstellen verwendet werden sollten, nur zwischen getrennten
  Parametern. Mehrere Werte fr einen Parameter mssen durch ein Komma
  getrennt werden und zwar wiederum ohne Leerstellen. Siehe folgende
  Beispiele:

     ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1           *RICHTIG*
     ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1   *FALSCH*

  2.1.  LILO (LInux LOader)

  LILO (LInux LOader), von Werner Almesberger, ist der am hufigsten
  verwendete. Er hat die Fhigkeit, verschiedene Kernel zu booten und
  speichert die Konfigurationsinformation als Klartext-Datei. Die
  meisten Distributionen werden mit LILO als Default-Boot-Loader
  ausgeliefert.  LILO kann DOS, OS/2, Linux, FreeBSD, etc. ohne
  Schwierigkeiten booten und ist zudem uerst flexibel.

  Eine typische Konfiguration wird kurz nach dem Systemstart LILO
  stoppen und folgendes ausgeben:  LILO:. Der Anwender hat dann einige
  Sekunden fr einen beliebigen Eintrag Zeit. Erfolgt kein Eintrag wird
  das Default-System gebootet. Typische Systemnamen, die in den LILO-
  Konfigurationsdateien verwendet werden, sind linux und backup und
  msdos. Falls ein Bootparameter eingegeben werden soll, wird man dies
  an dieser Stelle tun, nachdem man den Systemnamen, von dem LILO booten
  soll, eingegeben hat. Folgendes Beispiel soll dies verdeutlichen:

       LILO: linux root=/dev/hda1

  LILO ist hervorragend dokumentiert und fr die hier diskutierten
  Bootparameter ist das LILO-Kommando append= von groer Bedeutung, wenn
  man zur LILO config-Datei einen stndigen Bootparameter hinzufgen
  will.  Man mu einfach nur etwas wie

       append = "foo=bar"

  an die /etc/lilo.conf-Datei anhngen. Dies kann entweder an die
  hchste Ebene der config-Datei eingefgt werden und somit fr alle
  Sektoren gelten, oder es soll nur fr einen einzigen Systemabschnitt
  gelten, dann wird es innerhalb eines image=-Sektors eingefgt.  Eine
  ausfhrliche Beschreibung erhlt man in der LILO-Dokumentation.

  2.2.  LoadLin

  Ein anderer weitverbreiteter Linux-Loader ist `LoadLin'. Dieser ist
  ein DOS-Programm, das die Fhigkeit besitzt, einen Linux-Kernel vom
  DOS-Prompt aus zu starten (mit Bootparametern), vorausgesetzt,
  bestimmte Ressourcen stehen zur Verfgung.  Dies ist ein Vorteil fr
  alle, die Linux von DOS aus starten wollen.

  Es ist ebenfalls sehr ntzlich, wenn man bestimmte Hardware besitzt,
  welche den zur Verfgung stehenden DOS-Treiber bentigt, um die
  Hardware in einen bekannten Zustand zu bringen.  Ein gutes Beispiel
  sind die Soundblaster kompatiblen Soundkarten, welche den DOS-Treiber
  bentigen, um ein paar geheimnisvolle Register ziehen zu knnen, um
  die Karte in einen SB-kompatiblen Modus zu bringen. Das Booten von DOS
  mit dem zur Verfgung stehenden Treiber und das anschlieende Laden
  von Linux mit Loadlin vom DOS-Prompt aus verhindert das Zurckschalten
  der Karte in den vorherigen Zustand, was beim erneuten Booten der Fall
  wre. So jedoch bleibt die Karte in einem SB-kompatiblen Modus und ist
  somit unter Linux verwendbar.

  Es gibt auch noch andere Programme, die zum Booten von Linux verwendet
  werden knnen. Auf dem lokalen Linux-FTP-Server erhlt man unter
  system/Linux-boot/ die komplette Liste aller verfgbaren Programme.

  2.3.  Das Hilfsprogramm ``rdev''

  Es gibt einige Kernel-Bootparameter, deren Standardwerte in mehreren
  Bytes im Kernel-Image selbst gespeichert werden. Es gibt ein
  Hilfsprogramm namens rdev, das auf den meisten Systemen installiert
  ist und das wei, wo sich diese Werte befinden und wie sie gendert
  werden knnen. Dieses Hilfsprogramm kann auch Dinge ndern, die kein
  Kernel-Bootparameter-quivalent besitzen, wie z.B. der standardmig
  verwendete Grafik-Modus.

  Das Hilfsprogramm rdev wird gewhnlich auch swapdev, ramsize, vidmode
  und rootflags genannt. Diese Namen zeigen die 5 nderungsmglichkeiten
  durch rdev an: das Root-Device, das Swap-Device, die RAM-Disk-
  Parameter, der Standard-Grafik-Modus sowie die readonly/readwrite-
  Einstellung vom Root-Device.

  Weitere Informationen ber rdev erhlt man nach Eingabe von rdev -h
  oder durch die Lektre der bereitgestellten Manpage (man rdev).

  2.4.  Sortierung der Parameter durch den Kernel

  Die meisten Bootparameter sind folgendermaen strukturiert:

       name[=value_1][,value_2]...[,value_11]

  name ist hierbei ein einzigartiges Schlsselwort, das Aufschlu
  darber gibt, fr welchen Teil des Kernels die entsprechenden Werte
  (falls berhaupt) bestimmt sind. Mehrere Bootparameter werden als
  Liste nach obigem Format ausgegeben, wobei die einzelnen Parameter
  durch Leerzeichen getrennt sind.  Man beachte das tatschliche Limit
  von 11. Der bestehende Code kann nur 11 durch Kommas getrennte
  Parameter pro Schlsselwort verarbeiten. In ungewhnlich komplizierten
  Fllen kann man jedoch dasselbe Schlsselwort mit 11 zustzlichen
  Parametern erneut benutzen, vorausgesetzt, die Setup-Funktion
  untersttzt dies.  Man beachte auch, da der Kernel die Liste in
  maximal 10 Ganzzahlen- Parameter und eine anschlieende Zeichenfolge
  unterteilt. Das heit, man kann nicht wirklich 11 Ganzzahlen
  bereitstellen, hchstens durch Konvertierung des 11ten Parameters von
  einer Zeichenkette in eine Ganzzahl im Treiber selbst.

  Die Sortierung findet hauptschlich in linux/init/main.c statt. Zuerst
  berprft der Kernel, ob der Parameter zu einem der besonderen gehrt,
  wie root=, ro, rw, oder debug.  Die Bedeutung dieser `special
  arguments' wird im weiteren Verlauf dieser Dokumentation beschrieben.

  Der Kernel geht dann durch eine Liste von Setup-Funktionen (zu finden
  im bootsetups-Array), um zu sehen, ob die entsprechende Zeichenkette
  (wie z.B. foo) mit einer Setup-Funktion (foo_setup()) fr ein
  bestimmtes Gert oder einen Teil des Kernels verbunden ist. Wrde man
  dem Kernel die Zeile foo=3,4,5,6,bar bergeben, dann wrde dieser den
  bootsetups-Array durchgehen, um herauszufinden, ob `foo' registriert
  ist. Falls ja, wrde er die Setup-Funktion, die mit `foo'
  (foo_setup()) verbunden ist, aufrufen und dieser die Ganzzahlen-
  Parameter 3, 4, 5 und 6 bergeben,  wie auf der Kernel- Kommandozeile
  angegeben. Darberhinaus wrde er ebenfalls die Zeichenkette bar
  bergeben.

  2.5.  Umgebungsvariablen bestimmen.

  Alles, was aussieht wie foo=bar und nicht als Setup-Funktion
  akzeptiert wird, wie oben beschrieben, wird dann als festzusetzende
  Umgebungsvariable interpretiert. Ein (sinnloses?) Beispiel wre die
  Verwendung von TERM=vt100 als Bootparameter.

  2.6.  Weitergabe von Parametern zum `init'-Programm

  Alle verbleibenden Parameter, die nicht vom Kernel aufgegriffen und
  nicht als Umgebungsvariablen interpretiert wurden, werden dann zum
  ersten Proze weitergeleitet. Dieser ist normalerweise das init-
  Programm. Der am hufigsten zum init-Proze weitergeleitete Parameter
  ist das Wort single, welches init anweist, den Rechner im Ein-
  Benutzer-Modus zu booten und die blichen Dmonen nicht zu starten. Um
  herauszufinden, welche Parameter von der auf Ihrem System
  installierten Version von init akzeptiert werden, lesen Sie bitte die
  entsprechende Manpage.

  3.  Allgemeine, Gerte-unabhngige Bootparameter

  Hier handelt es sich um Bootparameter, die mit keinem speziellen Gert
  oder Peripheriegert verknpft sind. Statt dessen sind sie mit
  bestimmten internen Kernel-Parametern verbunden, wie z.B. der Umgang
  mit Speicher, Ramdisk, Root-Dateisystem und andere.

  3.1.  Root-Dateisystem-Optionen

  Folgende Optionen beziehen sich alle auf das Vorgehen des Kernels bei
  der Auswahl und dem Umgang mit dem Root-Dateisystem.

  3.1.1.  Der Parameter `root='

  Dieser Parameter teilt dem Kernel mit, welches Gert beim Booten als
  Root-Dateisystem benutzt werden soll. Die Standardeinstellung ist
  hierbei der Wert des Root-Gerts des Systems, auf dem der Kernel
  gebaut wurde. Wurde der fragliche Kernel z.B. auf einem System gebaut,
  das /dev/hda1 als Root-Partition verwendete, dann wre das Standard-
  Root-Gert /dev/hda1.  Will man diesen Standard-Wert auer Kraft
  setzen und das zweite Diskettenlaufwerk als Root-Gert whlen, wrde
  man root=/dev/fd1 whlen.

  Gltige Root-Gerte:

  1. /dev/hdaN bis /dev/hddN, welches Partition N auf der
     ST-506-kompatiblen Platte `a bis d' ist.

  2. /dev/sdaN bis /dev/sdeN, welches Partition N auf der SCSI-
     kompatiblen Platte `a bis e' ist.

  3. /dev/xdaN bis /dev/xdbN, welches Partition N auf der XT-kompatiblen
     Platte `a bis b' ist.

  4. /dev/fdN, welches das Floppy-Platten-Laufwerk Nummer N ist.  N=0
     wre das DOS-Laufwerk `A:' und N=1 wre `B:'.

  5. /dev/nfs, was eigentlich kein wirkliches Gert ist, sondern eher
     ein Kennzeichen, das den Kernel auffordert, das Root-Dateisystem
     ber das Netzwerk zu holen.

  Die schwierigere und weniger portierbare numerische Bestimmung der
  oben genannten, mglichen Plattengerte im major/minor-Format wird
  auch akzeptiert. (z.B. /dev/sda3 ist major 8, minor 3, d.h. man knnte
  als Alternative auch root=0x803 verwenden.)

  Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im
  Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm
  rdev gendert werden kann.

  3.1.2.  Der Parameter `ro'

  Wenn der Kernel bootet, wird dabei ein Root-Dateisystem bentigt, um
  grundlegende Dinge davon abzulesen. Dies ist das Root-Dateisystem, das
  beim Booten gemountet wird. Wird das Root-Dateisystem jedoch mit
  Schreibrecht gemountet, kann man keine verlliche berprfung der
  Dateisystem-Integritt vornehmen, whrend halb-geschriebene Dateien
  geprft werden.  Mit der Option `ro' wird der Kernel aufgefordert, das
  Root-Dateisystem als `readonly' zu mounten, so da Programme zur
  Konsistenzprfung des Dateisystems (fsck) mit Sicherheit annehmen
  knnen, da keinerlei halb-geschriebene Dateien geprft werden,
  whrend die berprfung stattfindet.    Kein Programm oder Proze kann
  Dateien des fraglichen Dateisystems beschreiben bis es nicht mit
  Lese/Schreibrecht wieder gemountet ist.

  Dies ist einer der wenigen Kernel-Bootparameter, dessen Standard im
  Kernelimage gespeichert ist, und welcher deshalb mit dem Hilfsprogramm
  rdev gendert werden kann.

  3.1.3.  Der Paramater `rw'

  Dies ist das exakte Gegenteil vom eben genannten. Hier wird der Kernel
  nmlich aufgefordert, das Root-Dateisystem mit Lese/Schreibrecht zu
  mounten. Die Default-Einstellung ist sowieso das Mounten des Root-
  Datei-Systems mit Lese/Schreibrecht. Man sollte auf keinen Fall
  Programme vom Typ `fsck' auf einem Dateisystem laufen lassen, das mit
  Lese/Schreibrecht gemountet wurde.

  Der bereits oben erwhnte, in der Image-Datei gespeicherte Wert ist
  der gleiche, der auch fr diesen Parameter verwendet wird. Der Zugriff
  darauf erfolgt ber rdev.

  3.2.  Optionen der RAM-Disk-Verwaltung

  Folgende Optionen beziehen sich alle auf den Umgang des Kernels mit
  dem RAM-Disk-Device, welches normalerweise fr Bootstrapping-Rechner
  whrend des Installationsvorgangs verwendet wird, oder fr Rechner mit
  Modultreibern, die zum Zwecke des Zugriffs auf das Root-Dateisystem
  installiert werden mssen.

  3.2.1.  Das Kommando `ramdisk_start='

  Das Kommando `ramdisk_start=<offset>' ermglicht einem Kernel-Image,
  zusammen mit einem komprimierten Ramdisk-Image auf einer Floppy zu
  bleiben.  Der Kernel kann nicht in das komprimierte Ramdisk-
  Dateisystem-Image aufgenommen werden, weil er beginnend mit Block Null
  gespeichert werden mu, so da das BIOS den Bootsektor laden kann.
  Dann kann der Kernel sich selbst erstmalig booten und damit zum Laufen
  bringen.

  Wichtig: Benutzt man ein unkomprimiertes Ramdisk-Image, dann kann der
  Kernel Teil des Dateisystem-Images sein, das in die Ramdisk geladen
  wird und die Floppy kann mit LILO gebootet werden. Die beiden knnen
  auch getrennt sein wie bei den komprimierten Images.

  Verwendet man ein 2-Disketten Boot/Root-Setup (Kernel auf Diskette 1,
  Ramdisk-Image auf Diskette 2) dann startet die Ramdisk bei Block Null
  und es wird ein Offset von Null verwendet. Da dies der Standardwert
  ist braucht man das Kommando in Wirklichkeit gar nicht benutzen.

  3.2.2.  Das Kommando `load_ramdisk='

  Dieser Parameter teilt dem Kernel mit, ob er ein Ramdisk-Image laden
  soll oder nicht. `load_ramdisk=1' soll den Kernel veranlassen, eine
  Floppy in die Ramdisk zu laden. Der Standardwert ist Null, was
  bedeutet, da der Kernel nicht versuchen soll, eine Ramdisk zu laden.

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Verwendung findet man in der Datei linux/Documentation/ramdisk.txt Es
  wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im
  Kernel-Image gespeichert werden kann.

  3.2.3.  Das Kommando `prompt_ramdisk='

  Dieser Parameter teilt dem Kernel mit, ob er einen Prompt ausgeben
  soll mit dem man aufgefordert wird, die Floppy mit dem Ramdisk-Image
  einzulegen.  Bei einer 1-Disketten-Konfiguration befindet sich das
  Ramdisk-Image auf der gleichen Floppy wie der Kernel, der gerade den
  Lade-/Bootvorgang beendet hat.  Somit wird ein Prompt nicht bentigt.
  In diesem Fall kann man das Kommando `prompt_ramdisk=0' verwenden. Bei
  einer 2-Disketten- Konfiguration wird man die Mglichkeit des
  Diskettentauschs bentigen. Somit kann `prompt_ramdisk=1' verwendet
  werden. Da dies der Standardwert ist, mu er eigentlich nicht
  angegeben werden.  (Geschichtliche Anmerkung: Heimtckische Anwender
  verwendeten gewhnlich die Option `vga=ask' LILO, um den Bootproze
  zeitweilig zu stoppen und ein Umschalten von der Boot- zur Rootfloppy
  zu ermglichen.)

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es
  wird auch beschrieben, wie dieser Parameter bestimmt und via rdev im
  Kernel-Image gespeichert werden kann.

  3.2.4.  Das Kommando `ramdisk_size='

  Zwar stimmt es, da die Ramdisk je nach Bedarf dynamisch wchst,
  jedoch gibt es eine Obergrenze fr ihre Gre, so da nicht der
  gesamte RAM verbraucht wird und einem Schwierigkeiten erspart werden.
  Der Standardwert ist 4096 (4MB), was den meisten Ansprchen gengen
  sollte. Mit diesem Bootparameter kann man den Standardwert verringern
  oder vergrern.

  Eine komplette Beschreibung der neuen Bootparameter und deren
  Benutzung findet man in der Datei linux/Documentation/ramdisk.txt Es
  wird auch beschrieben, wie dieser Parameter bestimmt und via `rdev' im
  Kernel-Image gespeichert werden kann.

  3.2.5.  Das Kommando `ramdisk=' (veraltet)

  Wichtig: Dieser Parameter ist veraltet und sollte nicht verwendet
  werden, es sei denn fr die Kernelversion v1.3.47 oder ltere.  Die
  Kommandos, die fr das Ramdisk-Device verwendet werden sollten sind
  oben beschrieben.

  Dies gibt in KB die Gre des RAM-Disk-Devices an.  Wrde man z.B. ein
  Root-Dateisystem auf einer 1,44 MB Floppy in ein RAM-Disk-Device laden
  wollen, wrde man folgendes Kommando verwenden:

       ramdisk=1440

  Dies ist einer der wenigen Kernel-Bootparameter, dessen Standardwert
  im Kernel-Image gespeichert ist und somit mit dem Hilfsprogramm rdev
  verndert werden kann.

  3.2.6.  Das Kommando `noinitrd' (initial RAM-Disk)

  Kernel v2.x und neuere verfgen ber ein Feature, bei dem das Root-
  Dateisystem anfangs eine RAM-Disk ist und der Kernel /linuxrc auf
  diesem RAM-Image ausfhrt. Dieses Feature wird typischerweise dazu
  verwendet, das Laden von Modulen zu ermglichen, die zum Mounten des
  eigentlichen Root-Dateisystems bentigt werden (z.B. Laden der SCSI-
  Treiber-Module, die im RAM-Disk-Image gespeichert sind und
  anschlieendes Mounten des eigentlichen Root-Dateisystems auf einer
  SCSI-Diskette.)

  Der eigentliche `noinitrd'-Parameter bestimmt, was mit den initrd-
  Daten passiert, nachdem der Kernel gebootet hat.  Wenn Sie bestimmt
  werden, statt auf eine RAM-Disk konvertiert zu werden, sind die Daten
  erhltlich unter /dev/initrd, welche eingesehen werden kann bevor der
  RAM wieder dem System bergeben wird. Umfassende Informationen ber
  die Benutzung der initial RAM-Disk erhlt man unter
  linux/Documentation/initrd.txt. Zustzlich sollten die neuesten
  Versionen  von LILO und LOADLIN weitere ntzliche Informationen
  enthalten.

  3.3.  Bootparameter fr den Umgang mit dem Speicher

  Folgende Parameter ndern sich, je nach, wie Linux den physikalischen
  oder virtuellen Systemspeicher erkennt oder behandelt.

  3.3.1.  Der Parameter `mem='

  Dieser Parameter dient zwei verschiedenen Zwecken: Der ursprngliche
  Zweck war die Bestimmung der installierten Speicherkapazitt (oder ein
  kleinerer Wert, falls man den Speicherplatz fr Linux verringern
  wollte). Der andere (und kaum verwendete) Zweck ist die Bestimmung von
  mem=nopentium, das den Linux-Kernel auffordert, das 4 MB
  Seitentabellen-Performance-Feature nicht zu verwenden.

  Der ursprngliche BIOS-Aufruf, definiert in der PC-Spezifikation, der
  den installierten Speicherplatz wiedergibt, wurde nur deswegen
  eingefhrt, um bis zu 64 MB angeben zu knnen. (Richtig, wieder
  mangelnde Voraussicht, genau wie bei den 1024 Zylinder-Platten...
  seufz.) Linux verwendet diesen BIOS-Aufruf beim Booten zur Bestimmung
  des installierten Speicherplatzes.  Sind mehr als 64 MB RAM
  installiert, kann man Linux mit diesem Bootparameter mitteilen,
  wieviel Speicherplatz vorhanden ist.  Hier ein Zitat von Linus ber
  die Verwendung des `mem=' Parameters:

       The kernel will accept any `mem=xx' parameter you give it,
       and if it turns out that you lied to it, it will crash hor
       ribly sooner or later.  The parameter indicates the highest
       addressable RAM address, so `mem=0x1000000' means you have
       16 MB of memory, for example.  For a 96 MB machine this
       would be `mem=0x6000000'.

  WICHTIG WICHTIG WICHTIG: Einige Rechner verwenden mglicherweise den
  grtmglichen Speicherplatz fr das Bereithalten des BIOS im Cache o.
  ., so da man mglicherweise nicht wirklich die vollen 96 MB belegen
  kann.  Auch das Gegenteil trifft zu: Einige Chipsets werden den
  physikalischen Speicher, der vom BIOS belegt wird, auf den Bereich
  ber dem Speichermaximum abbilden, d.h. der maximale Speicher wird in
  Wirklichkeit z.B. 96 MB + 384 kB betragen.  Teilt man Linux mit, da
  es ber mehr als den tatschlich vorhandenen Speicherplatz verfgt,
  dann wird dies schlimme Folgen haben: vielleicht nicht sofort, aber
  irgendwann mit Sicherheit.''

  Man beachte, da der Parameter keine Hexadezimalzahl sein mu und da
  die Endungen `k' und `M' (egal, ob Gro- oder Kleinschreibung) zur
  Bestimmung von Kilobytes, beziehungsweise Megabytes verwendet werden
  knnen. (`k' verursacht auf dem Wert eine Verschiebung von 10 Bit und
  `M' verursacht eine Verschiebung um 20 Bit.)  Die oben genannte
  Warnung hat insofern noch Gltigkeit, da ein 96 MB Rechner mit
  mem=97920k laufen mag, jedoch mit mem=98304k oder mem=96M versagt.

  3.3.2.  Der Parameter `swap='

  Hier wird dem Anwender die Feineinstellung eines Teils der virtuellen
  Speicherparameter ermglicht, die mit Diskswapping zu tun haben.
  Folgende 8 Parameter werden akzeptiert:

       MAX_PAGE_AGE
       PAGE_ADVANCE
       PAGE_DECLINE
       PAGE_INITIAL_AGE
       AGE_CLUSTER_FRACT
       AGE_CLUSTER_MIN
       PAGEOUT_WEIGHT
       BUFFEROUT_WEIGHT

  Interessierten Hackern sei die Lektre von linux/mm/swap.c empfohlen.
  Auch sollten sie einen Blick auf die `Goodies' in /proc/sys/vm werfen.

  3.3.3.  Der Parameter `buff='

  hnlich dem `swap='-Parameter wird dem Anwender die Feineinstellung
  einiger der Parameter fr die Buffer-Speicherverwaltung ermglicht.
  Folgende 6 Parameter werden akzeptiert:

       MAX_BUFF_AGE
       BUFF_ADVANCE
       BUFF_DECLINE
       BUFF_INITIAL_AGE
       BUFFEROUT_WEIGHT
       BUFFERMEM_GRACE

  Interessierten Hackern sei die Lektre von linux/mm/swap.c empfohlen.
  Auch sollten sie einen Blick auf die `Goodies' in /proc/sys/vm werfen.

  3.4.  Bootparameter fr das NFS-Root-Dateisystem

  Linux untersttzt Systeme wie laufwerkslose Workstations, indem ihr
  Rootfilesystem als NFS (Network FileSystem) besteht.  Diese Parameter
  werden dazu verwendet, der laufwerkslosen Workstation mitzuteilen, von
  welchem Rechner sie ihr System erhlt. Man beachte, da der Parameter
  root=/dev/nfs bentigt wird. Detaillierte Informationen ber die
  Verwendung eines NFS-Root-Dateisystems findet man in der Datei
  linux/Documentation/nfsroot.txt. Es wird empfohlen, diese Datei zu
  lesen, da folgende Information lediglich aus einer Zusammenfassung
  dieser Datei besteht.

  3.4.1.  Der Parameter `nfsroot='

  Dieser Parameter teilt dem Kernel mit, welcher Rechner, welches
  Verzeichnis und welche NFS-Optionen fr das Rootfilesystem ver- wendet
  werden sollen. Der Parameter ist folgendermaen aufgebaut:

       nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]

  Wird der nfsroot-Parameter nicht auf der Kommandozeile angegeben, dann
  wird defaultmig `/tftpboot/%s' verwendet. Andere mgliche Optionen
  sind:

     <server-ip>
        Bestimmt die IP-Adresse des NFS-Servers. Fehlt dieses Feld, dann
        wird die von der nfsaddrs-Variablen (siehe unten) bestimmte
        Default-Adresse verwendet. Dieser Parameter wird z.B. dazu
        verwendet, die Benutzung mehrerer Server fr RARP und NFS zu
        ermglichen. Normalerweise kann dieses Feld leer bleiben.

     <root-dir>
        Name des Verzeichnisses auf dem Server, das als root gemountet
        werden mu. Ist in der Zeichenkette ein `%s'-Token enthalten,
        dann wird der Token durch die ASCII-Darstellung der IP-Adresse
        des Clients ersetzt.

     <nfs-options>
        Standard-NFS-Optionen. Alle Optionen sind durch Kommas getrennt.
        Fehlt das Optionen-Feld werden folgende Standardwerte verwendet:

       port            = wie vom Portmap-Daemon angegeben
       rsize           = 1024
       wsize           = 1024
       timeo           = 7
       retrans         = 3
       acregmin        = 3
       acregmax        = 60
       acdirmin        = 30
       acdirmax        = 60
       flags           = hard, nointr, noposix, cto, ac

  3.4.2.  Der Parameter `nfsaddrs='

  Dieser Bootparameter bestimmt die verschiedenen Adressen der
  Netzwerkschnittstellen, die zur Kommunikation bers Netzwerk bentigt
  werden. Wird dieser Parameter nicht angegeben, dann versucht der
  Kernel die Verwendung von RARP und/oder BOOTP, um diese Parameter
  herauszufinden. Dies sieht folgendermaen aus:

       nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>

     <my-ip>
        IP-Adresse des Clients. Ist dieses Feld leer, wird die Adresse
        entweder von RARP oder von BOOTP bestimmt. Welches Protokoll
        verwendet wird, hngt vom <auto> Parameter ab und davon, was
        whrend der Kernelkonfiguration aktiviert wurde. Ist dieser
        Parameter nicht leer, dann wird weder RARP noch BOOTP benutzt.

     <serv-ip>
        IP-Adresse des NFS-Servers. Wird RARP zur Bestimmung der Client-
        Adresse verwendet und ist dieser Parameter NICHT leer, dann
        werden nur Antworten vom festgelegten Server akzeptiert. Zur
        Verwendung verschiedener RARP- und NFS-Server, bestimmt man hier
        den RARP-Server (oder lt das Feld leer), und legt den NFS-
        Server im nfsroot- Parameter fest (siehe oben). Bleibt dieser
        Eintrag aus, dann wird die Adresse des Servers verwendet,
        welcher auf die RARP- oder BOOTP-Anfrage antwortete.
     <gw-ip>
        IP-Adresse eines Gateways, falls der Server sich auf einem
        anderen Subnetz befindet. Ist dieser Eintrag leer, dann wird
        kein Gateway verwendet und es wird angenommen, da sich der
        Server auf dem lokalen Netzwerk befindet, bis BOOTP einen Wert
        erhlt.

     <netmask>
        Netzmaske fr die lokale Netzwerkschnittstelle.  Ist dieser
        Eintrag leer, dann wird die Netzmaske von der Client-IP-Adresse
        abgeleitet, bis BOOTP einen Wert erhlt.

     <name>
        Name des Clients. Bleibt dieses Feld leer, dann wird die Client-
        IP-Adresse in ASCII-Notation verwendet oder der von BOOTP
        empfangene Wert.

     <dev>
        Name des zu verwendenden Netzwerk-Gerts. Ist dieses Feld leer,
        dann werden alle Gerte fr RARP-Anfragen verwendet und das
        erste fr BOOTP. Fr NFS wird das Gert benutzt, von dem
        entweder RARP- oder BOOTP-Antworten empfangen wurden. Besitzt
        man nur ein Gert kann man dieses Feld getrost leer lassen.

     <auto>
        Zu verwendende Methode fr die AutoKonfiguration. Ist dies
        entweder `rarp' oder `bootp', dann wird das angegebene Protokoll
        verwendet. Ist der Wert `both' oder leer, dann werden beide
        Protokolle in dem Umfang verwendet, wie es ihnen whrend der
        Kernelkonfiguration ermglicht wurde. Der Eintrag Fall mssen
        alle notwendigen Werte in den vorherigen Feldern bestimmt
        werden.

  Der Parameter <auto> kann alleine als Wert fr den Parameter nfsaddrs
  erscheinen (ohne die ganzen `:' Zeichen davor). In diesem Fall wird
  Autokonfiguration verwendet. Jedoch ist der Wert `none' in diesem Fall
  nicht verfgbar.

  3.5.  Weitere verschiedene Kernel-Bootparameter

  Diese verschiedenen Bootparameter erlauben dem Benutzer die
  Feineinstellung bestimmter interner Parameter.

  3.5.1.  Der Parameter `debug'

  Mittels der Funktion printk() schickt der Kernel wichtige (und weniger
  wichtige) Nachrichten an den Operator.  Wird die Nachricht als wichtig
  angesehen, dann wird die Funktion printk() eine Kopie auf die aktuelle
  Konsole senden und sie an das Hilfsprogramm klogd() aushndigen, so
  da sie auf Festplatte aufgezeichnet wird. Der Grund fr die Ausgabe
  wichtiger Nachrichten auf der Konsole und gleichzeitiger
  Protokollierung durch die Festplatte liegt darin, da unter
  unglcklichen Umstnden (z.B. ein Plattenausfall) die Nachricht nicht
  zur Festplatte gelangt und somit verlorengeht.

  Der Level dafr, was als wichtig oder nicht wichtig betrachtet wird,
  wird von der Variablen console_loglevel festgelegt. Standardmig wird
  alles, was wichtiger ist als DEBUG (Level 7) auf der Konsole
  festgehalten. (Die verschiedenen Level sind in der include-Datei
  kernel.h) definiert. Das Festlegen von debug als Bootparameter setzt
  den Loglevel der Konsole auf 10, so da alle Kernel- Mitteilungen auf
  der Konsole erscheinen.

  Der Loglevel der Konsole kann normalerweise auch bei der Ausfhrung
  mittels einer Option an das Programm klogd() festgelegt werden.
  Informationen darber kann man der Manpage zu der auf dem System
  installierten Version entnehmen.

  3.5.2.  Der Parameter `init='

  Der Kernel wird beim Booten immer das `init'-Programm starten, welches
  getty-Programme startet, `rc'-Skripts laufen lt, u.. und somit den
  Rechner fr die Benutzer einrichtet.  Der Kernel schaut zuerst nach
  /sbin/init, dann nach /etc/init (herabgesetzt) und als letzte
  Mglichkeit wird er versuchen, /bin/sh zu verwenden (mglicherweise
  auf /etc/rc). Wurde z.B. das init-Programm verflscht und somit das
  Booten unmglich gemacht, dann kann man einfach den Bootprompt
  init=/bin/sh verwenden, was beim Booten direkt eine Shell ffnet und
  somit ein Ersetzen des verflschten Programms ermglicht.

  3.5.3.  Der Parameter `no387'

  Einige i387 Koprozessor-Chips haben Bugs, die sich bei der Verwendung
  im 32 bit-geschtzten Modus zeigen. Einige der frhen ULSI-387 Chips
  verursachen z.B. massive Totalsperren whrend der Ausfhrung von
  Fliepunkt-Berechnungen, was offensichtlich ein Bug in den
  FRSAV/FRRESTOR Anweisungen ist.  Die Verwendung des Bootparameters
  `no387' veranlat Linux, den mathematischen Koprozessor zu ignorieren,
  sogar wenn einer vorhanden ist.  Natrlich mu der Kernel dann mit
  mathematischer Emulations-Untersttzung kompiliert sein! Dies ist
  mglicherweise auch dann sinnvoll, wenn man einen dieser wirklich
  alten 386er hat, die einen 80287 FPU verwenden knnen, da Linux keinen
  80287 verwenden kann.

  3.5.4.  Der Parameter `no-hlt'

  Die i386-Familie der CPUs (und deren Nachfolger) verfgen ber die
  Anweisung `hlt', die der CPU mitteilt, da nichts geschehen wird,
  solange nicht ein externes Gert (Tastatur, Modem, Platte, etc.) die
  CPU auffordert, eine Aufgabe auszufhren.  Dies erlaubt der CPU in
  einen `low-power' Modus einzutreten, wo sie wie ein Zombie verharrt,
  bis sie von einem externen Gert geweckt wird (gewhnlich durch einen
  Interrupt).  Einige der frhen i486DX-100 Chips hatten insofern ein
  Problem mit der Anweisung `hlt', da sie nach deren Ausfhrung nicht
  mehr verllich in den Betriebsmodus zurckkehren konnten. Durch die
  Benutzung der Anweisung `no-hlt' wird Linux mitgeteilt, einfach eine
  Endlosschleife laufen zu lassen, wenn es nichts anderes zu tun gibt
  und die CPU nicht zu stoppen, wenn es keine aktiven Prozesse gibt.
  Dies ermglicht Benutzern mit solchen kaputten Chips die Verwendung
  von Linux, obwohl sie gut beraten wren, sich durch eine
  mglicherweise vorhandene Garantie einen Ersatz zu suchen.

  3.5.5.  Der Parameter `no-scroll'

  Die Angabe dieses Parameters beim Booten setzt Bildlauf-Features auer
  Kraft, die die Verwendung von Braille-Terminals erschweren.

  3.5.6.  Der Parameter `panic='

  Fr den unwahrscheinlichen Fall einer Kernel-Panic (ein interner
  Fehler, der vom Kernel erkannt wurde und den der Kernel als ernst
  genug erachtet, um sich laut zu beschweren und dann alles zu stoppen),
  wird fr gewhnlich gewartet, bis jemand vorbeikommt, die Panik-
  Message auf dem Bildschirm entdeckt und den Rechner neu bootet.  Falls
  sich ein Rechner jedoch unbewacht in einer abgelegenen Ecke befindet,
  mag es wnschenswert sein, da automatisch ein Reset stattfindet, so
  da der Rechner wieder zum normalen Betrieb zurckkehrt.  Die Angabe
  von `panic=30' beim Booten htte z.B. zur Folge, da der Kernel 30
  Sekunden nach der Kernel-Panic versuchen wrde, sich selbst zu booten.
  Standardwert ist Null und fhrt zum Standardverhalten, das darin
  besteht, endlos zu warten.

  Man beachte, da dieser Zeitlimit-Wert auch durch die Schnittstelle
  /proc/sys/kernel/panic sysctl gelesen und festgelegt werden kann.

  3.5.7.  Der Parameter `profile='

  Kernel-Entwickler knnen eine Option aktivieren, die es ihnen erlaubt,
  festzulegen, wie und wo der Kernel seine CPU-Zyklen einsetzt, um das
  uerste an Effizienz und Leistung herauszuholen. Mit dieser Option
  kann man die Profil-Verschiebungszhlung beim Booten bestimmen.
  Normalerweise wird diese auf 2 gesetzt. Man kann den Kernel auch mit
  automatischer Aktivierung des Profiling kompilieren. In jedem Fall
  braucht man ein Tool wie readprofile.c , das die Ausgabe /proc/profile
  verwenden kann.

  3.5.8.  Der Parameter `reboot='

  Diese Option kontrolliert die Art des Reboots, die Linux beim Reset
  des Rechners ausfhrt (normalerweise via /sbin/init das Control-Alt-
  Delete ausfhrt). Seit den spten v2.0-Kerneln ist der Standard ein
  `kalter' Neustart (kompletter Reset, BIOS macht einen Speicher-Check,
  etc.) statt eines `warmen' Neustarts (kein kompletter Reset, kein
  Speicher-Check). Die Voreinstellung wurde in einen Kaltstart gendert,
  da dies bei billiger/kaputter Hardware, die es nicht schafft neu zu
  booten, wenn ein Warmstart erforderlich wre, normalerweise
  funktioniert. Zum Wiederherstellen des alten Zustands (hier:
  Warmstart) verwendet man reboot=w Tatschlich funktioniert auch jedes
  beliebige Wort, das mit w beginnt.

  Warum sollte man sich darum kmmern? Einige Platten-Kontroller mit
  eingebautem Cache-Speicher knnen einen Warmstart wahrnehmen und Daten
  vom Cache auf die Festplatte schreiben. Nach einem Kaltstart wird die
  Speicherkarte mglicherweise zurckgeschaltet und die write-back-Daten
  im Cache-Speicher gehen verloren. Andere haben Systeme, die lange fr
  den Speicher-Check brauchen und/oder SCSI BIOSe, die nach einem
  Kaltstart lnger fr die Initialisierung brauchen als guten Grund fr
  den Einsatz eines Warmstarts gemeldet.

  3.5.9.  Der Parameter `reserve='

  Dieser wird dazu benutzt, I/O Port-Bereiche vor berprfungen zu
  schtzen. Das Kommando ist folgendermaen aufgebaut:

       reserve=iobase,extent[,iobase,extent]...

  Bei einigen Rechnern mag es notwendig sein, Gertetreiber davon
  abzuhalten, in einer bestimmten Region nach Gerten zu suchen
  (automatische Hardwareerkennung). Der Grund dafr kann z.B. schlecht
  entwickelte Hardware sein, die den Bootvorgang stoppt (wie z.B.
  einige Ethernetkarten), irrtmlicherweise erkannte Hardware, Hardware,
  deren Zustand durch eine frhere Erkennung gendert wurde oder einfach
  Hardware, die vom Kernel nicht initialisiert werden soll.

  Der Bootparameter reserve geht dieses Problem dadurch an, da er einen
  I/O Port-Bereich angibt, der nicht geprft werden soll.  Diese Region
  wird in der Port-Registrationstabelle des Kernels so behandelt, als ob
  dort bereits ein Gert gefunden wurde (trgt den Namen reserved). Man
  beachte, da dieser Mechanismus fr die meisten Rechner nicht
  notwendig sein drfte. Er ist nur bei Problemen und in besonderen
  Fllen erforderlich.

  Die I/O Ports sind gegen eine Gerteerkennung geschtzt, bei der
  vorrangig check_region() ausgefhrt wird, statt da blind ein I/O
  Bereich geprft wird. Dies wird dann eingesetzt, wenn Treiber auf
  einem NE2000 hngenbleiben oder irrtmlich andere Gerte als eigene
  erkannt werden. Ein korrekter Gertetreiber sollte keine reservierten
  Bereiche prfen, wenn nicht ein anderer Bootparameter dies
  ausdrcklich verlangt. Das bedeutet, da reserve meistens zusammmen
  mit einem anderen Bootparameter verwendet wird. Wenn man also einen
  reservierten Bereich festlegt, der ein bestimmtes Gert schtzen soll,
  dann mu man im Allgemeinen eine genaue Erkennung fr dieses Gert
  bestimmen. Die meisten Treiber ignorieren die Port- Registrations-
  Tabelle, wenn ihnen eine bestimmte Adresse genannt wird.

  Die Bootzeile

               reserve=0x300,32  blah=0x300

  hlt z.B. alle Gertetreiber, mit Ausnahme des Treibers fr `blah'
  davon ab, 0x300-0x31f zu prfen.

  Wie blich bei Boot-Argumenten gibt es ein Limit von 11 Parametern,
  d.h. man kann nur 5 reservierte Bereiche pro reserve Schlsselwort
  bestimmen. Bei ungewhnlich komplizierten Anfragen sind jedoch mehrere
  reserve Argumente mglich.

  3.5.10.  Der Parameter `vga='

  Man beachte, da es sich hierbei nicht um einen wirklichen
  Bootparameter handelt. Es ist vielmehr eine Option, die von LILO
  interpretiert wird und nicht vom Kernel wie all die anderen
  Bootparameter.  Sie wird jedoch so hufig verwendet, da sie an dieser
  Stelle eine Erwhnug verdient. Sie kann auch durch die Verwendung von
  rdev -v festgelegt werden und ebenso durch vidmode auf der Datei
  vmlinuz. Dies ermglicht dem setup code die Benutzung des Video- BIOS
  zur nderung des Standard-Anzeige-Modus vor dem tatschlichen Booten
  des Linux-Kernels. Typische Modi sind 80x50, 132x44 usw. Man verwendet
  diese Option am besten,indem man mit vga=ask beginnt, worauf man eine
  Liste verschiedener Modi erhlt, die man mit dem Grafik-Adapter
  benutzen kann bevor man den Kernel bootet. Hat man einmal eine Nummer
  aus obiger Liste gewhlt, kann man sie spter anstelle von `ask'
  setzen. Weitere Informationen findet man in der Datei
  linux/Documentation/svga.txt, die mit allen neueren Kernel-Versionen
  ausgeliefert wird.

  Man beachte, da neuere Kernelversionen (v2.1 und hher) den Setup-
  Code, der den Grafik-Modus ndert, als Option enthalten. Diese ist
  aufgelistet als Video mode selection support , d.h. man mu diese
  Option aktivieren, um dieses Feature verwenden zu knnen.

  4.  Bootparameter fr SCSI-Peripheriegerte.

  Dieser Abschnitt enthlt eine Beschreibung der Bootparameter, die zur
  Weitergabe von Informationen ber die installierten SCSI-Host-Adapter
  und SCSI-Gerte verwendet werden.

  4.1.  Parameter fr MIDLEVEL-Treiber

  MIDLEVEL-Treiber sind zustndig fr Dinge wie Disketten, CD-ROMs und
  Tapes ohne dabei in Host-Adapter-Bezeichnungen zu geraten.

  4.1.1.  Maximale Anzahl berprfter LUNs (`max_scsi_luns=')

  Jedes SCSI-Gert kann eine Reihe von `Sub-Gerten' enthalten.  Das
  beste Beispiel ist eines der neuen SCSI CD-ROMs, das gleichzeitig mehr
  als eine CD bedienen kann.  Jede CD wird als `Logical Unit Number'
  (LUN) dieses bestimmten Gertes angesprochen. Die meisten Gerte
  jedoch, wie z.B.  Festplatten, Bandlaufwerke u.. bestehen nur aus
  einer Gerteeinheit und erhalten LUN Null.

  Das Problem ergibt sich bei Gerten mit einer einzigen LUN mit
  schlechter Firmware. Einige schlecht entwickelte SCSI-Gerte (alte und
  unglcklicherweise auch neue) knnen nicht mit der berprfung fr
  LUNs ungleich Null umgehen. Sie antworten, indem sie sich und
  mglicherweise mit sich den gesamten SCSI-Bus sperren.

  Neuere Kernel verfgen ber eine Konfigurations-Option, die es
  ermglicht, die maximale Anzahl von geprften LUNs festzulegen.
  Standardmig untersucht man nur LUN Null, um das oben erwhnte
  Problem zu vermeiden.

  Zur Bestimmung der Anzahl von geprften LUNs beim Booten gibt man
  `max_scsi_luns=n' als Bootparameter ein, wobei n eine Zahl zwischen 1
  und 8 ist. Um oben genannte Probleme zu vermeiden, wrde man n=1
  verwenden, um solche defekten Gerte nicht zu verwirren.

  4.1.2.  Parameter fr den SCSI-Tape-Treiber (`st=')

  Ein Teil der Boot- Konfiguration des SCSI-Tape-Treibers kann mit
  folgendem Kommando erfolgen:
       st=buf_size[,write_threshold[,max_bufs]]

  Die ersten zwei Zahlen werden in kB-Einheiten angegeben.  Die
  Standard- buf_size ist 32 kB und die maximal zu bestimmende Gre sind
  lcherliche 16384 kB.  write_threshold ist der Wert bei dem der Puffer
  an das Tape weitergegeben wird. Standardwert hierbei sind 30 kB.  Die
  maximale Anzahl von Puffern ndert sich je nach der Zahl der erkannten
  Laufwerke. Standardwert ist 2. Hier eine Beispielverwendung:

       st=32,30,2

  Umfassende Details findet man in der Datei README.st im Verzeichnis
  scsi des Kernel-Quell-Baums.

  4.2.  Parameter fr SCSI-Host-Adapter

  Allgemeine Anmerkungen zu diesem Abschnitt:

     iobase
        Der erste I/O Port, der vom SCSI-Host besetzt wird.  Diese
        werden in der Hexadezimalschreibweise angegeben und liegen fr
        gewhnlich zwischen 0x200 und 0x3ff.

     irq
        Der Hardware-Interrupt, den die Karte per Konfiguration
        verwendet. Die gltigen Werte sind abhngig von der fraglichen
        Karte.  Normalerweise gelten die Werte 5, 7, 9, 10, 11, 12 und
        15. Die anderen Werte werden normalerweise fr bliche
        Peripheriegerte wie IDE- Festplatten, Disketten, serielle
        Anschlsse etc. verwendet.

     dma
        Der von der Karte verwendete DMA (Direct Memory Access)- Kanal.
        Dies gilt typischerweise nur fr Bus-Kontroller-Karten.  PCI und
        VLB Karten bentigen keinen ISA-DMA-Kanal.

     scsi-id
        Die ID, die der Host-Adapter verwendet, um sich auf dem SCSI-Bus
        zu identifizieren. Nur einige Host-Adapter erlauben die nderung
        dieses Werts, da die meisten ihn stndig intern bestimmen
        lassen. Normal ist der Standardwert 7. Die Seagate und Future
        Domain TMC-950-Boards jedoch verwenden 6.

     parity
        Ob der SCSI Host-Adapter von den angeschlossenen Gerten
        erwartet, da sie einen Parittswert mit dem gesamten
        Informationsaustausch zur Verfgung stellen. Der Wert 1
        aktiviert den Paritts-Check und Null schaltet ihn ab. Auch hier
        gilt, da nicht alle Adapter die Auswahl eines
        Parittsverhaltens als Bootparameter untersttzen.

  4.2.1.  Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI
          (`aha152x=')

  Die aha-Zahlen beziehen sich auf Karten und die aic-Zahlen beziehen
  sich auf den tatschlichen SCSI-Chip auf diesem Kartentyp,
  Soundblaster-16 SCSI eingeschlossen.

  Der Prf-Code fr diese SCSI Hosts schaut nach einem installierten
  BIOS. Falls keines vorhanden ist, dann wird die Karte nicht gefunden.
  Fr diesen Fall wird man einen Bootparameter folgender Form verwenden
  mssen:

       aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]]

  Beachte: Wurde der Treiber bei aktiviertem Debugging kompiliert, dann
  kann ein sechster Wert zur Bestimmung des Debug-Levels bestimmt
  werden.

  Alle Parameter verhalten sich wie eingangs dieses Abschnitts
  beschrieben und der reconnect Wert erlaubt die Abstpselung oder ein
  erneutes Anschlieen des Gerts, falls ein Wert ungleich Null benutzt
  wird.  Hier eine Beispielverwendung:

       aha152x=0x340,11,7,1

  Man beachte, da die Angabe der Parameter einer bestimmten Reihenfolge
  folgen mu, d.h. wenn man eine Parittseinstellung angeben will, dann
  mu man auch einen iobase-, einen irq-, einen scsi-id- und einen
  Umklemmwert angeben.

  4.2.2.  Adaptec aha154x (`aha1542=')

  Dies sind die Karten aus der aha154x-Serie. Die Karten aus der
  aha1542-Serie verfgen ber einen i82077 Floppy-Kontroller, die
  aha1540 Serienkarten hingegen nicht. Diese sind Busmaster-Karten und
  haben Parameter zur Festlegung der ``Fairness'', die dazu verwendet
  wird, den Bus mit anderen Gerten zu teilen. Der Bootparameter sieht
  folgendermaen aus:

       aha1542=iobase[,buson,busoff[,dmaspeed]]

  Gewhnlich ist einer der folgenden iobase Werte gltig: 0x130, 0x134,
  0x230, 0x234, 0x330, 0x334.  Clone-Karten lassen mglicherweise andere
  Werte zu.

  Die buson, busoff Werte beziehen sich auf die Anzahl von Mikrosekunden
  in denen die Karte den ISA Bus beherrscht. Standardmig gilt: 11 us
  an und 4 us aus, so da andere Karten (wie z.B. eine ISA LANCE
  Ethernetkarte) eine Chance haben, auf den ISA-Bus zuzugreifen.

  Der Wert dmaspeed bezieht sich auf die Geschwindigkeitsrate (in MB/s)
  in der der DMA (Direct Memory Access)-Transfer erfolgt.  Defaultwert
  ist 5 MB/s. Karten einer neueren Revision ermglichen die Auswahl
  dieses Werts als Teil der Soft-Konfiguration, ltere Karten verwenden
  Jumper. Man kann Werte bis 10 MB/s benutzen, vorausgesetzt das
  Motherboard kann damit umgehen. Bei der Verwendung von Werten ber 5
  MB/s sollte man vorsichtig vorgehen.

  4.2.3.  Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=')

  Diese Boards knnen einen Parameter folgender Form annehmen:

       aic7xxx=extended,no_reset

  Der Wert extended, falls ungleich Null, besagt, da die erweiterte
  bersetzung fr groe Platten eingeschaltet ist. Der Wert no_reset,
  falls ungleich Null, teilt dem Treiber mit, den SCSI-Bus nicht
  zurckzuschalten, wenn der Host-Adapter beim Booten bestimmt wird.

  4.2.4.  AdvanSys SCSI Host-Adapter (`advansys=')

  Der AdvanSys-Treiber akzeptiert bis zu 4 I/O Adressen, die fr eine
  AdvanSys SCSI-Karte berprft werden. Man beachte, da diese Werte
  (falls verwendet) berhaupt keinen Einflu auf die EISA- oder PCI-
  berprfung haben. Sie werden nur fr die berprfung von ISA- und
  VLB-Karten eingesetzt. Wurde der Treiber bei eingeschalteter
  Fehlererkennung kompiliert, kann zustzlich der Level der
  Fehlermeldung durch Hinzufgen des Parameters 0xdeb[0-f] bestimmt
  werden. 0-f ermglicht die Festlegung des Levels der Fehlermeldungen
  auf jeden der 16 Wort-Level.

  4.2.5.  Always IN2000-Host-Adapter (`in2000=')

  Im Gegensatz zu anderen SCSI Host-Bootparametern verwendet der
  IN2000-Treiber fr die meisten seiner Ganzzahlen-Parameter ASCII-
  String-Vorsilben. Hier eine Liste von untersttzten Parametern:

     ioport:addr
        Wobei addr die IO-Adresse einer (gewhnlich ROM-losen) Karte
        ist.

     noreset
        Keine optionalen Parameter. Verhindert die Zurckschaltung des
        SCSI-Bus beim Booten.

     nosync:x
        x ist eine Bitmaske, wobei die ersten 7 Bit mit den 7 mglichen
        SCSI-Gerten bereinstimmen (Bit 0 fr Gert #0, etc).  Um
        sync-bertragung auf diesem Gert zu VERHINDERN, bestimmt man
        ein Bit.  Treiber-Standard ist sync auf allen Gerten
        DEAKTIVIERT.

     period:ns
        ns ist die minimale # von Nanosekunden fr einen SCSI-
        Datentransfer. Standard ist 500; erlaubte Werte sind 250 bis
        1000.

     disconnect:x
        x = 0verhindert das Abschalten, 2 erlaubt das Abschalten.  x = 1
        fhrt 'adaptive' Unterbrechungen durch. Dies ist Standard, und
        wohl allgemein die beste Wahl.

     debug:x
        Ist `DEBUGGING_ON' angegeben, dann ist x eine Bitmaske, durch
        die verschiedene Debug-Ausgaben gedruckt werden - see the DB_xxx
        defines in in2000.h.

     proc:x
        Ist `PROC_INTERFACE' angegeben, dann ist x eine Bitmaske, die
        festlegt, wie die /proc Schnittstelle funktioniert und was sie
        macht - see the PR_xxx defines in in2000.h.

  Hier einige Anwendungs-Beispiele :

       in2000=ioport:0x220,noreset
       in2000=period:250,disconnect:2,nosync:0x03
       in2000=debug:0x1e
       in2000=proc:3

  4.2.6.  AMD AM53C974-basierte Hardware (`AM53C974=')

  Im Gegensatz zu anderen Treibern verwendet dieser keine Bootparameter,
  um I/O-, IRQ- or DMA-Kanle mitzuteilen.  (Da AM53C974 ein PCI-Gert
  ist, sollte dafr auch kein Grund bestehen.) Stattdessen teilen die
  Parameter fr gewhnlich die Transfermodi und Transferraten mit, die
  zwischen dem Host- und dem Zielgert verwendet werden sollen. Dies
  lt sich am besten anhand eines Beispiels beschreiben:

       AM53C974=7,2,8,15

  Dies wrde folgendermaen interpretiert werden: `Fr die Kommunikation
  zwischen dem Kontroller mit SCSI-ID 7 und dem Gert mit SCSI-ID 2
  sollte man eine Transferrate von 8 MHz im Synchronmodus mit max. 15
  Bytes Abweichung in Betracht ziehen.' Weitere Informationen findet man
  in der Datei linux/drivers/scsi/README.AM53C974

  4.2.7.  BusLogic SCSI-Hosts mit v1.2 Kerneln (`buslogic=')

  In lteren Kerneln akzeptiert der buslogic-Treiber nur einen
  Parameter, und zwar die I/O base. Sie erwartet, einer der folgenden
  Werte zu sein: 0x130, 0x134, 0x230, 0x234, 0x330, 0x334.

  4.2.8.  BusLogic SCSI Hosts mit v2.x Kerneln (`BusLogic=')

  Bei v2.x Kerneln akzeptiert der BusLogic-Treiber viele Parameter.
  (Man beachte obige Schreibweise; Gro B und L!!!).  Die folgende
  detaillierte Beschreibung ist direkt Leonard N. Zubkoffs Treiber des
  v2.0 Kernels entnommen.

  Beim BusLogic-Treiber umfat der Kernel-Kommandozeilen-Eintrag den
  Treiber-Identifier "BusLogic=" , optional gefolgt von einer durch
  Komma getrennten Ganzzahlenfolge und darauf optional gefolgt von einer
  durch Komma getrennten Stringfolge. Jeder Kommandozeilen- Eintrag gilt
  fr einen BusLogic Host-Adapter.  Bei Systemen, die mehrere BusLogic
  Host-Adapter enthalten, knnen mehrere Kommandozeilen-Eintrge
  verwendet werden.

  Die erste angegebene Ganzzahl ist die I/O Addresse, auf der sich der
  Host-Adapter befindet.  Fehlt diese Angabe wird der Standardwert 0
  benutzt. Das bedeutet, dieser Eintrag gilt fr den ersten BusLogic-
  Host-Adapter, der whrend der Standard- berprfungs-Sequenz gefunden
  wurde.  Wurden irgendwelche I/O Adressen-Parameter auf der
  Kommandozeile angegeben, dann wird die Standard-berprfungs-Sequenz
  ausgelassen.

  Die zweite angegebene Ganzzahl ist die Tagged Queue Depth, die fr
  Zielgerte, die Tagged Queuing untersttzen, zu verwenden ist.  Die
  Queue Depth ist die Anzahl von SCSI-Kommandos, die gleichzeitig als
  auszufhrend angegeben werden drfen. Fehlt eine Angabe wird
  standardmig 0 verwendet, d.h. es wird ein automatisch bestimmter
  Wert verwendet, basierend auf der maximalen Queue Depth des Host-
  Adapters und der Anzahl, dem Typ, der Geschwindigkeit und den
  Fhigkeiten der erkannten Zielgerte.       Bei Host-Adaptern, die ISA
  Bounce Buffers bentigen, wird die Tagged Queue Depth automatisch auf
  BusLogic_TaggedQueueDepth_BB gesetzt, um ausschweifende Vor-Zuordnung
  von DMA Bounce Buffer-Speicher zu vermeiden.  Zielgerte, die Tagged
  Queuing nicht untersttzen verwenden eine Queue Depth von
  BusLogic_UntaggedQueueDepth.

  Die dritte angegebene Ganzzahl ist die Bus Settle Time in Sekunden.
  Dies gibt die Zeit an, die man zwischen einem Host Adapter Hard Reset,
  der einen SCSI Bus Reset einleitet, und der Eingabe von SCSI-Kommandos
  wartet. Fehlt eine Angabe, dann wird standardmig 0 verwendet, d.h.
  es wird der Wert von BusLogic_DefaultBusSettleTime verwendet.

  Die vierte angegebene Ganzzahl sind die Local Options.  Fehlt die
  Angabe, dann wird standardmig 0 verwendet. Man beachte, da Local
  Options nur fr einen bestimmten Host-Adapter gelten.

  Die fnfte angegebene Ganzzahl sind die Global Options.  Fehlt die
  Angabe wird standardmig 0 verwendet.  Man beachte, da Global
  Options auf alle Host Adapter angewendet wird.

  Die String-Optionen dienen der Kontrolle ber Tagged Queuing, Error
  Recovery (Fehlerkorrektur) und Host-Adapter-berprfung.

  Die Tagged Queuing-Bestimmung beginnt mit "TQ:" und erlaubt die
  ausdrckliche Festlegung, ob Tagged Queuing auf Zielgerten, die dies
  untersttzen, erlaubt ist.  Folgende Optionen zur Bestimmung stehen
  zur Verfgung:

     TQ:Default
        Ob Tagged Queuing erlaubt ist, hngt von der Firmware- Version
        des BusLogic Host-Adapters ab und davon, ob es der Tagged Queue
        Depth-Wert erlaubt, mehrere Kommandos in die Warteschlange zu
        stellen.

     TQ:Enable
        Tagged Queuing wird fr alle Zielgerte auf diesem Host-Adapter
        aktiviert, wobei jegliche Beschrnkungen bergangen werden, die
        ansonsten, basierend auf der Host Adapter Firmware-Version,
        auferlegt werden wrden.

     TQ:Disable
        Tagged Queuing wird fr alle Zielgerte auf diesem Host-Adapter
        deaktiviert.

     TQ:<Per-Target-Spec>
        Tagged Queuing wird fr jedes einzelne Zielgert kontrolliert.
        <Per-Target-Spec> ist eine Sequenz aus "Y", "N", und "X"
        Zeichen.  "Y" aktiviert Tagged Queuing, "N" deaktiviert Tagged
        Queuing und "X" akzeptiert den Standardwert, basierend auf der
        Firmware-Version.  Das erste Zeichen bezieht sich auf Zielgert
        0, das zweite auf Zielgert 1 usw.; falls die Sequenz aus "Y",
        "N" und "X" Zeichen nicht alle Zielgerte abdeckt, werden nicht
        spezifizierte Zeichen als "X" angenommen.

  Man beachte, da das ausdrckliche Verlangen nach Tagged Queuing zu
  Problemen fhren kann; diese Mglichkeit dient primr dazu, das
  Deaktivieren von Tagged Queuing auf Zielgerten zu ermglichen, die es
  nicht korrekt durchfhren.

  Die Error Recovery Strategy-Spezifikation beginnt mit "ER:" Sie
  ermglicht, ausdrcklich festzulegen, da die Error Recovery- Aktion
  ausgefhrt wird, wenn das ResetCommand aufgerufen wird - aufgrund
  eines Versagens des SCSI-Kommandos, erfolgreich abzulaufen.  Folgende
  Optionen zur Bestimmung stehen zur Verfgung:

     ER:Default
        Ausgehend von der Empfehlung des SCSI-Subsystems wird Error
        Recovery zwischen einem Hard Reset und den Bus Device Reset-
        Optionen whlen.

     ER:HardReset
        Error Recovery wird einen Host Adapter Hard Reset einleiten, was
        zustzlich einen SCSI Bus Reset verursacht.

     ER:BusDeviceReset
        Error Recovery wird eine Bus Device Reset-Mitteilung zu dem
        jeweiligen Zielgert schicken, das den Fehler verursacht hat.
        Wird noch einmal Error Recovery fr dieses Zielgert
        eingeleitet, und hat kein SCSI-Kommando an dieses Zielgert
        erfolgreich ausgefhrt, seit die Bus Device Reset-Nachricht
        geschickt wurde, dann wird ein Hard Reset ntig sein.

     ER:None
        Error Recovery wird unterdrckt. Diese Option sollte nur dann
        gewhlt werden, wenn ein SCSI Bus-Reset oder Bus Device-Reset
        das Zielgert veranlat, komplett und unwiderruflich zu
        versagen.

     ER:<Per-Target-Spec>
        Error Recovery wird fr jedes einzelne Zielgert kontrolliert.
        <Per-Target-Spec> ist eine Sequenz aus "D", "H", "B" und "N"
        Zeichen.  Mit "D" wird Default gewhlt, "H" steht fr Hard
        Reset, "B" fr Bus Device-Reset und mit "N" wird None gewhlt.
        Das erste Zeichen bezieht sich auf Zielgert 0, das zweite auf
        Zielgert 1 usw. werden mit "D", "H", "B" und "N" nicht alle
        mglichen Zielgerte abgedeckt, dann werden undefinierte Zeichen
        als "D" angenommen.

  Die Host-Adapter-berprfungs-Spezifikation umfat folgende
  Zeichenketten:

     NoProbe
        Es soll keine berprfung stattfinden; somit werden keine
        BusLogic-Host-Adapter erkannt.

     NoProbeISA
        Die Standard ISA I/O Adresssen werden nicht untersucht; somit
        werden nur PCI-Host-Adapter erkannt.

     NoSortPCI
        PCI-Host-Adapter werden in der vom PCI BIOS bereitgestellten
        Reihenfolge aufgezhlt, wobei die Einstellungen der Option
        AutoSCSI "Use Bus And Device # For PCI Scanning Seq." ignoriert
        werden.

  4.2.9.  EATA SCSI-Karten (`eata=')

  Seit den spten Kernelversionen v2.0 akzeptieren die EATA-Treiber die
  berprfung eines Bootparameters, der die i/o base(s) bestimmt.  Dies
  sieht folgendermaen aus:

       eata=iobase1[,iobase2][,iobase3]...[,iobaseN]

  Der Treiber berprft die Adressen in der Reihenfolge, in der sie
  aufgelistet sind.

  4.2.10.  Future Domain TMC-8xx, TMC-950 (`tmc8xx=')

  Der berprfungscode fr diese SCSI-Hosts schaut nach einem
  installierten BIOS; falls keines vorhanden ist, wird die Karte nicht
  gefunden werden. Oder, wenn die Signature-String des BIOS nicht
  erkannt wurde, dann wird die Karte auch nicht gefunden. In jedem der
  beiden Flle wird man dann einen Bootparameter folgender Form
  verwenden:

       tmc8xx=mem_base,irq

  Der Wert mem_base ist der Wert des speicherkonformen I/O-Bereichs, den
  die Karte verwendet. Dieser ist fr gewhnlich einer der folgenden
  Werte: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000.

  4.2.11.  Future Domain TMC-16xx, TMC-3260, AHA-2920 (`fdomain=')

  Der Treiber erkennt diese Karten entsprechend einer Liste von
  bekannten BIOS ROM-Signatures. Eine komplette Liste bekannter BIOS-
  Ausgaben erhlt man in der Datei linux/drivers/scsi/fdomain.c. Diese
  wird mit einer Flle von Informationen eingeleitet. Ist das Bios dem
  Treiber nicht bekannt, dann kann man dies folgendermaen berbrcken:

       fdomain=iobase,irq[,scsi_id]

  4.2.12.  IOMEGA Parallel Port / ZIP-Laufwerk (`ppa=')

  Dies ist ein Treiber fr den IOMEGA Parallel Port SCSI Adapter,
  welcher in den IOMEGA ZIP-Laufwerken enthalten ist.  Es knnte auch
  mit dem original IOMEGA PPA3-Gert funktionieren.  Der Bootparameter
  fr diesen Treiber sieht folgendermaen aus:

       ppa=iobase,speed_high,speed_low,nybble

  Alle auer iobase sind optional festgelegte Werte. Will man einen der
  unverbindlichen Parameter verndern, dann sollte man einen Blick auf
  die Datei linux/drivers/scsi/README.ppa werfen.  Dort findet man
  genaue Informationen darber, was von diesen Parametern kontrolliert
  wird.

  4.2.13.  NCR5380-basierte Kontroller (`ncr5380=')

  Je nach Board kann der 5380 entweder I/O- oder speicherkonform sein.
  (Eine Adresse unter 0x400 ist fr gewhnlich I/O-konform.  PCI- und
  EISA-Hardware verwenden jedoch i/o-Adressen ber 0x3ff.)  In jedem
  Fall gibt man die Adresse, den IRQ-Wert und den DMA-Channel-Wert an.
  Hier ein Beispiel einer I/O-konformen Karte: ncr5380=0x350,5,3.
  Verwendet die Karte keine Interrupts, dann knnen mit einem IRQ-Wert
  von 255 (0xff) Interrupts deaktiviert werden. Ein IRQ-Wert von 254
  bedeutet automatische Hardwareerkennung.  Weitere Informationen findet
  man in der Datei linux/drivers/scsi/README.g_NCR5380

  4.2.14.  NCR53c400-basierte Kontroller (`ncr53c400=')

  Die generische 53c400-Untersttzung erfolgt mit demselben Treiber wie
  fr die oben erwhnte generische 5380-Untersttzung. Der Bootparameter
  ist identisch zum obig genannten, mit der Ausnahme, da vom 53c400
  kein DMA-Channel verwendet wird.

  4.2.15.  NCR53c406a-basierte Kontroller (`ncr53c406a=')

  Dieser Treiber verwendet einen Bootparameter folgender Form:

       ncr53c406a=PORTBASE,IRQ,FASTPIO

  wobei die IRQ- und FASTPIO-Parameter optional sind. Ein Interrupt-
  Wert von Null schaltet die Verwendung von Interrupts aus.  Der Wert 1
  fr den FASTPIO-Parameter aktiviert die Verwendung von insl und outsl-
  Anweisungen, statt den aus einem einzigen Byte bestehenden inb und
  outb-Anweisungen. Der Treiber kann eine Option fr die
  Kompilierungszeit nehmen.

  4.2.16.  Pro Audio Spectrum (`pas16=')

  PAS16 verwendet einen NCR5380 SCSI-Chip und neuere Modelle
  untersttzen die Konfiguration ohne Jumper. Der Bootparameter sieht
  folgendermaen aus:

       pas16=iobase,irq

  Der einzige Unterschied besteht darin, da man einen IRQ-Wert von 255
  verwenden kann, welcher dem Treiber mitteilt ohne Interrupts, jedoch
  mit einem Leistungsverlust, zu funktionieren.  Die iobase ist
  gewhnlich 0x388.

  4.2.17.  Seagate ST-0x (`st0x=')

  Der Code zur berprfung fr diese SCSI-Hosts sucht nach einem
  installierten BIOS. Ist keines vorhanden, wird die Karte nicht
  gefunden.  Oder, wenn die Signature-Zeichenkette des BIOS nicht
  erkannt wird, dann wird sie auch nicht gefunden. In jedem Fall wird
  man einen Bootparameter folgender Form verwenden:

       st0x=mem_base,irq

  Der Wert mem_base ist der Wert der speicherkonformen I/O-Region, den
  die Karte verwendet. Dieser wird fr gewhnlich einer der folgenden
  Werte sein: 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000.

  4.2.18.  Trantor T128 (`t128=')

  Diese Karten basieren ebenfalls auf dem NCR5380-Chip und verstehen
  folgende Optionen:

       t128=mem_base,irq

  Gltige Werte fr mem_base sind: 0xcc000, 0xc8000, 0xdc000, 0xd8000.

  4.2.19.  Ultrastor SCSI-Karten (`u14-34f=')

  Man beachte, da es anscheinend zwei unabhngige Treiber fr diese
  Karte gibt, nmlich CONFIG_SCSI_U14_34F der u14-34f.c benutzt, und
  CONFIG_SCSI_ULTRASTOR , der ultrastor.c verwendet. u14-34f ist
  derjenige, der (seit den spten Kernelversionen v2.0) einen
  Bootparameter folgender Form akzeptiert:

       u14-34f=iobase1[,iobase2][,iobase3]...[,iobaseN]

  Der Treiber berprft die Adressen in der Reihenfolge, wie sie
  aufgelistet sind.

  4.2.20.  Western Digital WD7000-Karten (`wd7000=')

  Der Treiber-Check fr wd7000 sucht nach einer bekannten BIOS ROM-
  Zeichenkette und kennt einige Standard-Konfigurations-Einstellungen.
  Werden die korrekten Werte fr die eigene Karte nicht geliefert oder
  hat man eine nicht erkannte BIOS-Version, dann kann man einen
  Bootparameter folgender Form verwenden:

       wd7000=irq,dma,iobase

  4.3.  SCSI-Host-Adapter, die keine Bootparameter akzeptieren

  Zur Zeit verwenden folgende SCSI-Karten keine Bootparameter.  In
  einigen Fllen kann man Werte hartkodieren, indem man, falls ntig,
  den Treiber selbst editiert.

          Adaptec aha1740 (EISA-berprfung),
          NCR53c7xx,8xx (PCI, beide Treiber)
          Qlogic Fast (0x230, 0x330)
          Qligic ISP (PCI)

  5.  Festplatten

  In diesem Abschnitt werden alle Bootparameter aufgelistet, die mit
  Standard-MFM/RLL, ST-506, XT und IDE-Festplatten-Gerten verbunden
  sind. Man beachte, da sowohl der IDE- als auch der generische ST-506
  HD-Treiber die Option `hd=' akzeptieren.

  5.1.  IDE Disk/CD-ROM-Treiber-Parameter

  Der IDE-Treiber akzeptiert eine Reihe von Parametern, die von
  Plattengeometrie-Spezifikationen bis zur Untersttzung fr hher
  entwickelte oder kaputte Kontroller-Chips reichen. Es folgt eine
  Zusammenfassung aller mglichen Bootparameter. Bentigt man weitere
  Informationen, sollte man unbedingt einen Blick auf die Datei ide.txt
  im Verzeichnis linux/Documentation werfen, dem diese Zusammenfassung
  entnommen wurde.

   "hdx="  wird fr alle "x" von "a" bis "h", wie z.B. "hdc" erkannt.
   "idex=" wird fr alle "x" von "0" bis "3", wie z.B. "ide1" erkannt.

   "hdx=noprobe"          : Treiber mag vorhanden sein, jedoch soll keine
                            berprfung stattfinden
   "hdx=none"             : Treiber ist NICHT vorhanden, cmos soll
                            ignoriert werden
                            und eine berprfung soll nicht
                            stattfinden
   "hdx=nowerr"           : Das WRERR_STAT-Bit auf diesem Laufwerk soll
                            ignoriert werden
   "hdx=cdrom"            : Laufwerk ist vorhanden und
                             ist ein CDROM-Laufwerk
   "hdx=cyl,head,sect"    : Plattenlaufwerk ist vorhanden, mit angegebener
                            Geometrie
   "hdx=autotune"         : der Treiber wird versuchen, die Schnittstellen-
                            Geschwindigkeit auf den schnellsten
                            untersttzten PIO-Modus einzustellen; falls
                            mglich, nur fr dieses Laufwerk.
                            Wird nicht von allen Chipset-Typen voll
                            untersttzt
                                  Verursacht wahrscheinlich Probleme bei
                                  lteren/odd IDE-Laufwerken.

   "idex=noprobe"         : Es soll nicht versucht werden, auf diese
                            Schnittstelle zuzugreifen oder sie zu verwenden
   "idex=base"            : Fhre Schnittstellen-Check bei der angegebenen
                            Adresse aus,
                                  wobei "base" normalerweise 0x1f0 oder 0x170 ist
                                  und angenommen wird, da "ctl"  "base"+0x206 ist.
   "idex=base,ctl"        : bestimme sowohl base und ctl
   "idex=base,ctl,irq"    : bestimme base, ctl, und irq-Nummer
   "idex=autotune"        : der Treiber wird versuchen, die Schnittstellen-
                            Geschwindigkeit auf den schnellsten
                            untersttzten PIO-Modus einzustellen,
                            und zwar fr alle auf dieser Schnittstelle
                            befindlichen Laufwerke.
                                  Wird nicht von allen Chipset-Typen voll
                                  untersttzt
                                  Verursacht wahrscheinlich Probleme bei
                                  lteren/odd IDE-Laufwerken.
   "idex=noautotune"      : Treiber versucht NICHT, die Schnittstellen-
                            Geschwindigkeit einzustellen.
                                  Dies ist der Standard fr die meisten
                                  Chipsets,
                                  mit Ausnahme von cmd640.
   "idex=serialize"       : keine berlappenden Aktionen auf idex und
                            ide(x^1)

  Das Folgende gilt NUR auf ide0, und die Standardwerte fr die base,ctl
  Ports drfen nicht gendert werden.

   "ide0=dtc2278"         : prfe/untersttze DTC2278 Schnittstelle
   "ide0=ht6560b"         : prfe/untersttze HT6560B Schnittstelle
   "ide0=cmd640_vlb"      : *NOTWENDIG* fr VLB-Karten mit dem CMD640 Chip
                            (nicht fr PCI -- wird automatisch erkannt)
   "ide0=qd6580"          : prfe/untersttze qd6580 Schnittstelle
   "ide0=ali14xx"         : prfe/untersttze ali14xx Chipsets
                            (ALI M1439/M1445)
   "ide0=umc8672"         : prfe/untersttze umc8672 Chipsets

  Alles brige wird mit der Nachricht "BAD OPTION" abgewiesen.

  5.2.  Standard ST-506-Platten-Treiber-Optionen (`hd=')

  Der Standard-Plattentreiber kann, hnlich wie der IDE-Treiber,
  Geometrie-Parameter fr die Platten akzeptieren. Man beachte jedoch,
  da er nur drei Werte (C/H/S) erwartet -- nur einer mehr oder weniger,
  und man wird einfach von ihm ignoriert. Er akzeptiert auch nur `hd='
  als Argument, d.h. `hda=', `hdb=' usw. sind hier nicht gltig.  Das
  Format sieht folgendermaen aus:

       hd=cyls,heads,sects

  Wenn zwei Platten installiert sind, wird das obenstehende mit den
  Geometrie-Parametern der zweiten Platte wiederholt.

  5.3.  XT-Platten-Treiber-Optionen (`xd=')

  Sollten Sie zu den Unglcklichen gehren, die eine dieser alten 8-Bit-
  Karten verwenden, die Daten keuchend mit 125kB/s verschieben, dann
  kommt hier der Knller. Der berprfungscode fr diese Karten schaut
  nach einem installierten BIOS. Falls keines vorhanden ist, dann wird
  die Karte nicht erkannt werden. Oder, falls der Signature-String Ihres
  BIOS nicht erkannt wurde, dann wird sie ebenfalls nicht gefunden. In
  jedem Fall wird man dann einen Bootparameter folgender Form verwenden
  mssen:

       xd=type,irq,iobase,dma_chan

  Der Wert type bestimmt den einzelnen Hersteller der Karte, und zwar
  wie folgt: 0=generic; 1=DTC; 2,3,4=Western Digital, 5,6,7=Seagate;
  8=OMTI. Der einzige Unterschied zwischen den verschiedenen Typen
  desselben Herstellers liegt in dem BIOS-String, der fr die Erkennung
  verwendet wird. Dieser wird nicht benutzt, wenn der Typ angegeben
  wurde.

  Die xd_setup()-Funktion berprft die Werte nicht und nimmt an, da
  alle vier Werte eingetragen wurden. Man sollte sie nicht enttuschen.
  Hier ist eine Beispiel-Verwendung fr einen WD1002- Kontroller mit
  ausgeschaltetem/entferntem BIOS, wobei die `Default' Parameter vom XT-
  Kontroller verwendet werden:

       xd=2,5,0x320,3

  6.  CD-ROMs (nicht-SCSI/ATAPI/IDE)

  In diesem Abschnitt werden alle mglichen Bootparameter aufgelistet,
  die zu den CD-ROM-Gerten gehren. Man beachte, da dies nicht fr
  SCSI- oder IDE/ATAPI-CD-ROMs gilt. Informationen ber diese CD-ROM-
  Typen findet man in den entsprechenden Abschnitten.

  Man beachte, da die meisten dieser CD-ROMs Dokumentationsdateien
  enthalten, die man lesen sollte . Sie alle sind gnstig plaziert:
  linux/Documentation/cdrom.

  6.1.  Die Aztech-Schnittstelle (`aztcd=')

  Dieser Kartentyp hat folgende Syntax:

       aztcd=iobase[,magic_number]

  Setzt man magic_number auf 0x79 , dann wird der Treiber einen Versuch
  starten und im Falle einer unbekannten Firmware sowieso laufen. Alle
  brigen Werte werden ignoriert.

  6.2.  Die CDU-31A- und CDU-33A-Sony-Schnittstelle (`cdu31a=')

  Diese CD-ROM-Schnittstelle kann auf einigen der Pro Audio Spectrum
  Soundkarten gefunden werden und auf anderen Schnittstellen-Karten von
  Sony. Die Syntax ist folgendermaen:

       cdu31a=iobase,[irq[,is_pas_card]]

  Setzt man einen IRQ-Wert auf Null, dann wird dem Treiber damit
  mitgeteilt, da Hardware-Interrupts nicht untersttzt werden (wie auf
  einigen PAS-Karten). Untersttzt die eigene Karte Interrupts, dann
  sollte man diese nutzen, da diese die CPU-Last des Treibers
  verringern.

  Die `is_pas_card' sollte als `PAS' eingetragen werden, falls eine Pro
  Audio Spectrum-Karte verwendet wird. Andernfalls sollte sie berhaupt
  nicht bestimmt werden.

  6.3.  Die CDU-535 Sony-Schnittstelle (`sonycd535=')

  Diese CD-ROM-Schnittstelle hat folgende Syntax:

       sonycd535=iobase[,irq]

  Fr die I/O base kann eine Null als `Platzhalter' verwendet werden,
  falls man einen IRQ-Wert bestimmen will.

  6.4.  Die GoldStar-Schnittstelle (`gscd=')

  Diese CD-ROM-Schnittstelle hat folgende Syntax:

       gscd=iobase

  6.5.  Die ISP16-Schnittstelle (`isp16=')

  Diese CD-ROM-Schnittstelle hat folgende Syntax:

       isp16=[port[,irq[,dma]]][[,]drive_type]

  Der Wert Null fr irq oder dma besagt, da sie nicht benutzt werden.
  Erlaubte Werte fr drive_type sind noisp16, Sanyo, Panasonic, Sony,
  und Mitsumi.  Die Verwendung von noisp16 deaktiviert den gesamten
  Treiber.

  6.6.  Die Mitsumi Standard-Schnittstelle (`mcd=')

  Die CD-ROM-Schnittstelle hat folgende Syntax:

       mcd=iobase,[irq[,wait_value]]

  wait_value wird als interner Timeout-Wert fr diejenigen verwendet,
  die Probleme mit ihrem Laufwerk haben, und wird je nach einem
  Kompilierungszeit-DEFINE implementiert oder nicht.

  6.7.  Die Mitsumi XA/MultiSession-Schnittstelle (`mcdx=')

  Zur Zeit verfgt dieser `experimental'-Treiber ber eine Setup-
  Funktion, jedoch sind bis jetzt (seit 1.3.15) keine Parameter
  implementiert. Dies gilt fr dieselbe Hardware wie oben genannt, aber
  der Treiber verfgt ber erweiterte Features.

  6.8.  Die Optics Storage-Schnittstelle (`optcd=')

  Dieser Kartentyp hat folgende Syntax:

       optcd=iobase

  6.9.  Die Phillips CM206-Schnittstelle (`cm206=')

  Dieser Kartentyp hat folgende Syntax:

       cm206=[iobase][,irq]

  Zahlen zwischen 3 und 11 werden vom Treiber als IRQ-Werte
  interpretiert und Zahlen zwischen 0x300 und 0x370 als I/O Ports, so
  da man eine oder beide Zahlen in beliebiger Reihenfolge angeben kann.
  Der Treiber akzeptiert auch `cm206=auto' zum Aktivieren der
  automatischen Hardwareerkennung.

  6.10.  Die Sanyo-Schnittstelle (`sjcd=')

  Diese Karte hat folgende Syntax:

       sjcd=iobase[,irq[,dma_channel]]

  6.11.  Die SoundBlaster Pro-Schnittstelle (`sbpcd=')

  Diese Karte hat folgende Syntax:

       sbpcd=iobase,type

  wobei type einer der folgenden Zeichenketten ist (egal, ob Gro- oder
  Kleinschreibung): `SoundBlaster', `LaserMate' oder `SPEA'.  Die I/O-
  Basisadresse ist die der CD-ROM-Schnittstelle und nicht die des Sound-
  Teils der Karte.

  7.  Andere Hardware-Gerte

  Alle brigen Gerte, die nicht in eine der oben erwhnten Kategorien
  passen, wurden hier zusammengefat.

  7.1.  Ethernet-Gerte (`ether=')

  Unterschiedliche Treiber verwenden unterschiedliche Parameter.  Ihnen
  allen gemeinsam ist, da sie alle ber einen IRQ, einen Wert der I/O
  Port-Basisadresse und einen Namen verfgen. In seiner generischsten
  Form schaut dies in etwa so aus:

       ether=irq,iobase[,param_1[,param_2,...param_8]]],name

  Das erste, nicht-numerische Argument wird als Name genommen.  Die
  param_n Werte (falls anwendbar) haben normalerweise fr jede(n)
  einzelne Karte/Treiber eine unterschiedliche Bedeutung. Typische
  param_n Werte werden zur Bestimmung von Dingen wie Shared Memory-
  Adresse, Schnittstellen-Auswahl, DMA-Channel u.. verwendet.

  Dieser Parameter wird am hufigsten dafr eingesetzt, automatische
  Hardwareerkennung fr eine zweite Ethernetkarte zu erzwingen, da
  defaultmig nur nach einer gesucht wird. Dies erreicht man mit einem
  einfachen Befehl:

       ether=0,0,eth1

  Man beachte, da im obigen Beispiel der Wert Null fr die IRQ und I/O-
  Basisadresse den/die Treiber auffordert, eine automatische
  Hardwareerkennung durchzufhren.

  WICHTIGER HINWEIS FR DIE BENUTZER VON MODULEN: Oben genanntes
  Kommando wird keine berprfung nach einer zweiten Karte erzwingen,
  wenn der/die Treiber als ladbare Module whrend der Laufzeit verwendet
  werden (anstatt sie in den Kernel hineinkompilieren zu lassen).  Die
  meisten Linux-Distributionen verwenden ein bloes Kernel-Gerst
  zusammen mit einer groen Auswahl an Modul-Treibern.  ether= gilt nur
  fr Treiber, die direkt in den Kernel kompiliert sind.

  Das Ethernet HOWTO verfgt ber eine komplette und ausfhrliche
  Dokumentation ber die Verwendung mehrerer Karten und ber die
  Karten-/Treiber-spezifische Implementation der param_n Werte, wenn
  verwendet.  Interessierten Lesern sei empfohlen, sich in dem
  entsprechenden Abschnitt dieses Dokuments komplette Informationen ber
  ihre spezielle Karte zu holen.

  7.2.  Der Disketten-Treiber (`floppy=')

  Es gibt eine Flle von Disketten-Treiber-Optionen, die alle in der
  Datei README.fd unter linux/drivers/block aufgelistet sind.  Diese
  Informationen wurden direkt dieser Datei entnommen.

     floppy=mask,allowed_drive_mask
        Setzt die Bitmaske der mglichen Laufwerke auf mask.
        Standardmig sind nur die Einheiten 0 und 1 eines jeden Floppy-
        Kontrollers zugelassen.  Dies liegt darin begrndet, da
        bestimmte auer-standardmige Hardware (ASUS PCI-Motherboards)
        die Tastatur durch Zugriff auf die Einheiten 2 or 3
        durcheinanderbringen. Diese Option ist durch die Option cmos
        etwas veraltet.

     floppy=all_drives
        Bestimmt die Bitmaske der mglichen Laufwerke fr alle
        Laufwerke.  Man verwende diese Option, wenn man mehr als zwei
        Laufwerke an einem Floppy-Kontroller angeschlossen hat.

     floppy=asus_pci
        Die Bitmaske wird so eingestellt, da sie nur die Einheiten 0
        und 1 erlaubt.  (Standard)

     floppy=daring
        Teilt den Floppy-Treiber mit, da man einen gut funktionierenden
        Floppy- Kontroller hat. Dies ermglicht ein effizienteres und
        glatteres Arbeiten, kann jedoch bei bestimmten Kontrollern
        versagen. Bestimmte Aktionen knnen dadurch verschnellert
        werden.

     floppy=0,daring
        Teilt dem Floppy-Treiber mit, da der Floppy-Kontroller mit
        Vorsicht behandelt werden soll.

     floppy=one_fdc
        Teilt dem Floppy-Treiber mit, da nur Floppy-Kontroller
        vorhanden sind (Standard)

     floppy=two_fdc or floppy=address,two_fdc
        Teilt dem Floppy-Treiber mit, da zwei Floppy-Kontroller
        vorhanden sind. Es wird angenomen, da sich der zweite Floppy-
        Kontroller auf der Adresse <address> befindet.  Ist keine
        Adresse angegeben, wird 0x370 angenommen.

     floppy=thinkpad
        Teilt dem Floppy-Treiber mit, da ein Thinkpad vorhanden ist.
        Thinkpads verwenden eine umgekehrte Konvention fr die
        Platten-nderungszeile.

     floppy=0,thinkpad
        Teilt dem Floppy-Treiber mit, da kein Thinkpad vorhanden ist.

     floppy=drive,type,cmos
        Setzt den cmos Typ von drive auf type.  Zustzlich ist dieses
        Laufwerk in der Bitmaske erlaubt. Dies ist dann hilfreich, wenn
        mehr als zwei Floppy-Laufwerke vorhanden sind (es knnen
        lediglich zwei im physikalischen cmos beschrieben werden) oder
        wenn das BIOS auer-standardmige CMOS-Typen verwendet. Wenn
        CMOS fr die ersten beiden Laufwerke auf 0 gesetzt wird
        (Standard), dann wird der Floppy-Treiber den physikalischen cmos
        fr diese Laufwerke lesen.

     floppy=unexpected_interrupts
        Gibt einen Warnhinweis aus, wenn ein unerwarteter Interrupt
        erhalten wird (Standardverhalten)

     floppy=no_unexpected_interrupts or floppy=L40SX
        Gibt keine Nachricht aus, wenn ein unerwarteter Interrupt
        erhalten wird.  Dies wird auf IBM L40SX Laptops in bestimmten
        Grafikmodi bentigt. (Es scheint eine Interaktion zwischen
        Grafikkarte und Floppy zu bestehen. Die unerwarteten Interrupts
        betreffen nur die Performance und knnen beruhigt ignoriert
        werden.)

  7.3.  Der Sound-Treiber (`sound=')

  Der Sound-Treiber kann auch Bootparameter annehmen, um die
  hineinkompilierten Werte zu bergehen. Dies wird jedoch nicht
  empfohlen, da es ziemlich komplex ist. Es ist (war?) in der Datei
  Readme.Linux unter linux/drivers/sound beschrieben. Ein Bootparameter
  folgender Form wird akzeptiert:

       sound=device1[,device2[,device3...[,device11]]]

  wobei jeder deviceN Wert von folgendem Format ist 0xTaaaId und die
  Bytes folgendermaen verwendet werden:

    T - Gerte-Typ: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
     7=SB16-MPU401

    aaa - I/O Adresse in hex.

    I - Interrupt-Zeile in hex (i.e 10=a, 11=b, ...)

    d - DMA-Channel.

  Wie man sieht, ein ganz schnes Durcheinander. Man ist wohl besser
  beraten, sich, wie empfohlen, seine eigenen, persnlichen Werte
  hineinzukompilieren. Die Verwendung des Bootparameters `sound=0'
  deaktiviert den gesamten Sound-Treiber.

  7.4.  Der Bus-Maus-Treiber (`bmouse=')

  Der Bus-Maus-Treiber akzeptiert nur einen Parameter, und zwar den zu
  verwendenden Hardware IRQ Wert.

  7.5.  Der MS-Bus-Maus-Treiber (`msmouse=')

  Der MS-Maustreiber akzeptiert nur einen Parameter, und zwar den zu
  verwendenden Hardware IRQ-Wert.

  7.6.  Der Druckertreiber (`lp=')

  Bei den Kernelversionen nach 1.3.75 kann man dem Druckertreiber
  mitteilen, welche Ports verwendet werden sollen und welche nicht.
  Letzteres ist dann praktisch, wenn man verhindern will ,da der
  Druckertreiber alle zur Verfgung stehenden parallelen Ports
  beansprucht, so da andere Treiber (z.B. PLIP, PPA) sie stattdessen
  verwenden knnen.

  Das Argument besteht aus mehreren I/O-, IRQ-Paaren.
  lp=0x3bc,0,0x378,7 verwendet z.B. den Port auf 0x3bc im IRQ-losen
  (Aufruf)-Modus, und benutzt IRQ 7 fr den Port auf 0x378.  Der Port
  auf 0x278 (falls vorhanden) wrde nicht berprft werden, da
  automatische Hardwareerkennung nur ohne ein `lp=' Argument
  stattfindet. Zum kompletten Deaktivieren des Druckertreibers kann man
  lp=0 verwenden.

  7.7.  Der ICN ISDN Treiber (`icn=')

  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:

       icn=iobase,membase,icn_id1,icn_id2

  wobei iobase die I/O Port-Adresse der Karte ist, membase die
  Gemeinschaftsspeicher-Base-Adresse der Karte und die zwei icn_id sind
  einzelne ASCII-Zeichenketten-Identifier.

  7.8.  Der PCBIT ISDN-Treiber (`pcbit=')

  Dieser Bootparameter verwendet Paare von Ganzzahlen-Argumenten, z.B.:

       pcbit=membase1,irq1[,membase2,irq2]

  wobei membaseN die Shared Memory-Basisadresse der Nten Karte ist, und
  irqN die Interrupt-Einstellung der Nten Karte. Default ist IRQ 5 und
  membase 0xD0000.

  7.9.  Der Teles ISDN-Treiber (`teles=')

  Dieser ISDN-Treiber erwartet einen Bootparameter folgender Form:

       teles=iobase,irq,membase,protocol,teles_id

  wobei iobase die I/O Port Adresse der Karte ist, membase die Shared
  Memory-Basisadresse der Karte, irq ist der von der Karte verwendete
  Interrupt-Channel und teles_id ist ein eindeutiger ASCII-String
  Bezeichner.

  7.10.  Der DigiBoard-Treiber (`digi=')

  Der DigiBoard-Treiber akzeptiert eine Zeichenkette von 6 durch Kommas
  getrennten Bezeichner oder Ganzzahlen.  Hier die 6 Werte in
  Reihenfolge:

  Aktivieren/Deaktivieren der Karte PC/Xi(0), PC/Xe(1),
  PC/Xeve(2), PC/Xem(3) : Kartentyp wechselnde Pin-Anordnung
  aktivieren/deaktivieren Anzahl der Ports auf dieser Karte I/O
  Port mit konfigurierter Karte (in HEX, falls String-Bezeichner
  verwendet werden) Basisadresse des Memory Window (in HEX, falls
  String-Bezeichner verwendet werden)

  Hier ein Beispiel eines korrekten Bootprompt-Parameters (sowohl in
  Bezeichner- als auch in Ganzzahlen-Form):

       digi=E,PC/Xi,D,16,200,D0000
       digi=1,0,0,16,512,851968

  Man beachte, da der Treiber eine I/O von 0x200 und eine Shared
  Memory-Basisadresse von 0xD0000 voreingestellt hat, falls kein digi=
  Boot-Argument angegeben wurde.  Es wird keine automatische
  Hardwareerkennung durchgefhrt. Weitere Informationen findet man in
  der Datei linux/Documentation/digiboard.txt.

  7.11.  Der RISCom/8 Multiport Serial-Treiber (`riscom8=')

  Bis zu 4 Karten werden untersttzt, indem man 4 eindeutige I/O Port-
  Werte fr jede einzelne Karte angibt.  Weitere Informationen findet
  man in der Datei linux/Documentation/riscom8.txt.

  7.12.  Das Baycom Serial/Parallel Radio Modem (`baycom=')

  Der Bootparameter fr diese Gerte hat folgendes Format:

       baycom=modem,io,irq,options[,modem,io,irq,options]

  Die Verwendung von modem=1 bedeutet, da man das ser12-Gert hat,
  modem=2 bedeutet, man hat das par96-Gert. options=0 bedeutet
  Verwendung von Hardware-DCD, und options=1 bedeutet Verwendung von
  Software-DCD. io und irq sind wie gewhnlich die I/O Port-
  Basisadresse- und Interrupt-Einstellungen.  Weitere Informationen
  findet man in der Datei README.baycom, die sich zur Zeit im
  Verzeichnis /linux/drivers/char/ befindet.

  8.  Schlubemerkung

  Sollten Ihnen irgendwelche Tippfehler ins Auge gesprungen sein, oder
  haben Sie veraltete Informationen in diesem Dokument gefunden, dann
  lassen Sie es mich bitte wissen. Es macht nicht viel Mhe, den Text
  durchzugehen.

  Danke,

  Paul Gortmaker, gpg109@rsphy1.anu.edu.au

