1.101.7 Konfiguration von USB-Geräten

800px-Uganda-Kob

Wikimedia Commons Frank Dickert

Aus dem Bereich 1.101 Hardware und Systemarchitektur der Unterlangen für die Linux Zertifizierung LPIC-1 [101]
Quellen, Weblinks
Prüfungskandidaten sollten in der Lage sein, USB-Unterstützung zu aktivieren und verschiedene USB-Geräte zu verwenden und zu konfigurieren. Dieses Lernziel beinhaltet die korrekte Auswahl des USB-Chipsatzes und des dazugehörigen Moduls. Ebenfalls enthalten ist das Wissen über die allgemeine Architektur des USB-Schichtenmodells und die verschiedenen Module, die in den einzelnen Schichten verwendet werden.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen:
lspci(8), usb-uhci.o, usb-ohci.o, /etc/usbmgr/, usbmodules, /etc/hotplug
Grundsätzliche Unterstützung von {de:USB}
USB wird von Kerneln ab Version 2.2.7 unterstützt. Besser sind die Kernel ab 2.4.0. Die generelle Unterstützung von USB ist heute meist fest in einen Kernel hineingebaut, kann aber auch als Modul realisiert werden. Dieses Modul muß – falls mit USB gearbeitet werden soll – entsprechend geladen werden. Das Modul heißt usbcore.o und kann mit dem Befehl
modprobe usbcore
im laufenden Betrieb eingehängt werden. Üblich ist aber, daß diese grundsätzliche USB-Unterstützung fest integriert ist. Beim Booten sollte – falls das der Fall ist – eine Meldung wie die folgende angezeigt werden:
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.

Damit ist klar, daß die USB-Unterstützung grundsätzlich aktiviert ist.
UHCI oder OHCI
Die meisten modernen Mainboards stellen einen USB-Controller zur Verfügung. Ältere Maschinen können mit einem USB-Controller auf einer PCI-Karte nachgerüstet werden. USB-Controler sind entweder kompatibel zum Open Host Controller Interface (OHCI – Compaq) oder zum Universal Host Controller Interface (UHCI – Intel). Beide Typen haben die selben Fähigkeiten und USB-Geräte arbeiten mit beiden Typen zusammen.
Die wesentliche Aufgabe bei der Konfiguration von USB unter Linux ist es, herauszufinden, welchen der beiden Controller auf dem Rechner verwendet wird, auf dem USB konfiguriert werden soll.
Mainboards der folgenden Firmen benutzen UHCI: Intel, VIA (auch VIA basierte USB-Adapter)
Mainboards der folgenden Firmen benutzen OHCI: Compaq, Ali, SiS, NEC, Opti Chipsatz
Eine gute Methode, um den entsprechenden Chipsatz herauszufinden ist ein Aufruf von lspci. Eine typische Ausgabe wäre z.B.
...
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 16)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
...

was eindeutig VIA – also UHCI bedeutet.
Falls das nicht weiterführt, gibt es die Möglichkeit, die Datei /proc/pci anzusehen. Dort findet sich ein Eintrag in der Art:
Bus 0, device 7, function 3:
USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 22).
IRQ 10.
Master Capable. Latency=32.
I/O at 0xa800 [0xa81f].

Wenn auch hier keine Angaben stehen, dann sollte die IO-Adresse angesehen werden. Ist sie in der Form 0xHHHH (wobei HHHH für vier hexadezimale Ziffern steht), dann haben wir es mit UHCI zu tun, ansonsten, wenn die Form der Adresse 0xHH000000 ist, dann ist es OHCI.
Sobald herausgefunden wurde, welcher Controller benutzt wird, kann das Grundmodul für USB geladen werden. Das ist eines der beiden folgenden Module: * usb-ohci.o oder * usb-uhci.o
Geladen werden diese Module entweder von Hand über den Befehl
modprobe usb-uhci oder modprobe usb-ohci
oder automatisiert über einen entsprechenden Eintrag in /etc/modules.conf etwa in der Art:
alias usb uhci
Jetzt kann in einer Systemstartdatei ein modprobe usb eingetragen werden und das entsprechende Modul wird automatisch beim Start geladen. Es ist sogar möglich dadurch alle gewünschten anderen USB-Module gleich mitzuladen, etwa indem dort eingetragen wird
alias usb uhci
post-install uhci modprobe printer
post-install printer modprobe joydev
post-install joydev modprobe hid

Das USBDevFS-Dateisystem
Das USB Geräte-Dateisystem ist ein dynamisch generiertes Dateisystem, ähnlich dem /proc Dateisystem. Es kann theoretisch an jede beliebige Stelle des Systems gemountet werden, es hat sich aber durchgesetzt, es nach /proc/bus/usb einzuhängen.
Wenn im Kernel die Unterstützung für dieses Dateisystem aktiviert ist (Preliminary USB Device Filesystem) dann sollte es – bei 2.4er Kerneln automatisch beim Start gemountet werden. Ältere Kernel erfordern entweder Handarbeit wie
mount -t usbdevfs none /proc/bus/usb
oder einen Eintrag nach /etc/fstab in der Art
none /proc/bus/usb usbdevfs defaults 0 0
Nachdem das Dateisystem gemountet ist, sollte der Inhalt von /proc/bus/usb etwa folgendermaßen aussehen:
-r--r--r-- 1 root root 0 2002-08-20 00:02 devices
-r--r--r-- 1 root root 0 2002-08-20 00:02 drivers

Sobald das entsprechende Modul usb-ohci.o oder usb-uhci.o geladen ist, der USB-Controller also ansprechbar ist, sollte mindestens noch ein (meist aber zwei) Unterverzeichnis zu finden sein, für jede USB-Schnittstelle eines:
dr-xr-xr-x 1 root root 0 2002-08-20 00:11 001
dr-xr-xr-x 1 root root 0 2002-08-20 00:11 002
-r--r--r-- 1 root root 0 2002-08-20 00:11 devices
-r--r--r-- 1 root root 0 2002-08-20 00:11 drivers

Die Einträge in diesen Verzeichnissen und Dateien sind binär und somit nicht für menschliche Augen gedacht. Es geht darum, im Fehlerfall Zugriff auf jedes einzelne Gerät zu haben und Diagnosen stellen zu können.
Das USB-Schichtenmodell von Linux
Um zu verstehen, welche Module wie voneinander abhängen, folgt hier eine Darstellung des USB-Schichtenmodells, wie es der Linux-Kernel benutzt. Daraus wird klar, daß der USB-Kern (usbcore) nicht die unterste Schicht des USB-Stapels ist, sondern in beide Richtungen erweiterbar ist.
Nach „unten“ hin, also Richtung Controller-Hardware sind ihm die bereits besprochenen USB-Hostcontroller-Module (usb-ohci und usb-uhci) angeschlossen, mit denen er in die Lage versetzt wird, den entsprechenden USB-Controller anzusprechen. Nach „oben“ hin folgen die Module, die für die einzelnen Geräte selbst notwendig sind.
Der Kern (usbcore) selbst stellt die Funktionalität von USB selbst zur Verfügung, also alles, was für alle Geräte gleich ist.
Die einzelnen Geräte, die über USB angeschlossen werden, können in sogenannte Klassen aufgeteilt werden. Als Klassen werden Geräte zusammengefasst, die eine bestimmte Menge gleichartiger Mechanismen benutzen. Unter Linux ist die Aufteilung nicht besonders intensiv, die einzige große Klasse, die sich ergibt ist die Klasse HID. (Human Interface Device – Gerät für eine menschliche Schnittstelle). Diese Klasse fasst alles zusammen, was als Eingabegerät des Benutzers klassifiziert werden kann. Also z.B. Tastatur, Mouse und Joystick. Das entsprechende Modul unter Linux heißt hid.o.
Diese Klasse wiederum benutzt ein weiteres Modul, das die Eingabe (input) von solchen Geräten regelt. Unter Linux wird diese Aufgabe vom Modul input.o gelöst. Erst darauf bauen dann die einzelnen Module für die jeweiligen Eingabegeräte wie etwa usbkbd.o oder usbmouse.o auf.
Durch diese Architektur ist es relativ wenig Aufwand, neue Treiber für Eingabegeräte zu schreiben. Die wesentliche Funktionalität ist ja schon durch die Module hid.o und input.o gegeben. Nur noch die spezifischen Besonderheiten des jeweiligen Gerätes müssen in den entsprechenden Treiber integriert werden.
Andere Geräte, die nicht zur HID-Klasse gehören, verwenden nur jeweils ein Modul, um die entsprechende Funktionalität zur Verfügung zu stellen. So wird z.B. für den Einsatz eines USB-Druckers nur das Modul printer.o benötigt. Dieses Modul erstellt dann eine (oder mehrere) Gerätedatei(en) im Verzeichnis /dev/usb, die wie parallele Schnittstellen zu benutzen sind (/dev/usb/lp0), um einen dort angeschlossenen Drucker entsprechend anzusprechen.
Wenn also an USB kein Eingabegerät angehängt ist, so kann auf den Einsatz des gesamten HID/Input Astes verzichtet werden.
Genauere Informationen, über die gefundenen (angeschlossenen) USB-Geräte sind mit dem Programm lsusb zu ermitteln.
Module für die USB-Geräte automatisch einbinden
USB ist von seinem ganzen Ansatz her ein sogenannter Hotplugging Service, also ein Dienst, der im laufenden Betrieb ein- und ausgehängt werden kann. Diese Fähigkeit wird von Linux unterstützt, es müssen dazu aber ein paar Voraussetzungen erfüllt sein.
Grundsätzlich existieren zwei unterschiedliche Ansätze, um diese Fähigkeit anzubieten:
* hotplug
Ein Programm, das die Hotplugging-Fähigkeit für viele verschiedene Systeme anbietet, etwa USB oder PCMCIA.
* usbmgr
Ein Programm, das die Hotplugging-Fähigkeit nur für USB anbietet.
Beide Ansätze werden hier kurz beschrieben:
Funktionsweise von hotplug
hotplug ist ein Programm, das vom Kernel benutzt werden kann, um User-Programme von bestimmten Ereignissen (zumeist Hardware-spezifisch) zu unterrichten. Ein solches Ereignis kann beispielsweise das Anstecken eines USB- oder PCMCIA Gerätes sein. Das kann brauchbar sein, um die entsprechenden Module für dieses Gerät automatisch zu laden.
hotplug benutzt für jedes zu überwachende System einen sogenannten Agenten, ein Shellscript, normalerweise unter /etc/hotplug/Systemname.agent. Für USB wäre das also das Script /etc/hotplug/usb.agent.
Informationen über solche Ereignisse werden den Agenten vom Kernel über Umgebungsvariablen übermittelt. Das Programm usbmodules wird beispielsweise vom usb-Agenten benutzt, um die erkannten Geräte mit den notwendigen Modulen auszustatten. Die Information über die Geräte erhält hotplug über die Umgebungsvariable DEVICES.
hotplug ist ein Daemon, der über ein init-Script (/etc/init.d/hotplug) gestartet wird.
Funktionsweise von usbmgr
usbmgr ist ein Daemon, der benötigte USB-Module etsprechend seiner Konfigurationsdateien läd und entläd. Zusätzlich können noch Scripts ausgeführt werden, sofern das notwendig sein sollte. usbmgr benutzt die offiziellen USB-Vendor-IDs und die USB-Device-IDs, die vom USB-Consortium offiziell vergeben werden, um herauszufinden, welche Geräte er gefunden hat. Die beiden Konfigurationsdateien des Programms sind:
* /etc/usbmgr/usbmgr.conf
Eine Datei, die die offiziellen IDs enthält. Diese Datei kann aktuell über https://www.wondernetworkresources.com/staff/shuu/linux/usbmgr/ bezogen werden und muß nicht verändert werden. Sie dient nur der Information, welche Module für welche IDs geladen werden müssen.
* /etc/usbmgr/preload.conf
Diese Datei enthält eine Liste der Module, die usbmgr laden soll, wenn er startet. Diese Datei kann vom Systemverwalter entsprechend verändert werden.
* /etc/usbmgr/host
enthält den Modulnamen (ohne .o) des verwendeten USB-Hostcontrollers also entweder usb-ohci oder usb-uhci
Für eine korrekte Funktion von usbmgr müssen folgende Voraussetzungen erfüllt sein:
* Der Kernel muß USB-fähig sein (usbcore)
* Das USBDEVFS muß unterstützt werden
* Die benötigten Kernelmodule müssen existieren

Auch usbmgr ist ein Daemon, der über ein init-Script gestartet wird.
Alle Artikel zur LPIC unterliegen der GNU Free Documentation License.

Quellen, Weblinks:

Linux USB
USB 2.0
auch das ist möglich Linux vom USB-Stick

(571)

1.101.6 Konfiguration von Kommunikationsgeräten

800px-Uganda-Kob

Wikimedia Commons Frank Dickert

Aus dem Bereich 1.101 Hardware und Systemarchitektur der Unterlangen für die Linux Zertifizierung LPIC-1 [101]
Quellen, Weblinks
Prüfungskandidaten sollten in der Lage sein, verschiedene interne und externe Kommunikationsgeräte wie Modems, ISDN-Adapter und DSL-Router zu installieren und zu konfigurieren. Dieses Lernziel beinhaltet die Prüfung von Kompatibilitätskriterien (besonders wichtig, wenn es sich um ein Winmodem handelt), notwendige Hardwareeinstellungen für interne Geräte (Interrupts, DMAs, I/O-Adressen) und das Laden und Konfigurieren von passenden Gerätetreibern. Ebenfalls enthalten sind Anforderungen an die Konfiguration von Kommunikationsgeräten und -schnittstellen, wie z.B. der korrekte serielle Port für 115.2 kbps und korrekte Modemeinstellungen für ausgehende PPP-Verbindungen.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:* /proc/dma, /proc/interrupts, /proc/ioports, setserial(8)
Die Installation von Kommunikationsgeräten unterscheidet sich nicht von der anderer Erweiterungsgeräte. Also gilt für diese Geräte wiederum all das, was unter
* Hardwareparameter, * Das /proc-Verzeichnis und * Plug and Play mit Linux
schon gesagt wurde. Auch die bereits gemachten Erklärungen zu Kompatibilitätskriterien insbesondere von WIN-Modems wurden in Konfiguration von Modem und Soundkarten bereits besprochen. Die konkrete Einrichtung von PPP wird in der Vorbereitung auf die Prüfung LPI102 noch Thema werden.
Setzen der seriellen Schnittstelle auf 115.2 kbps mit setserial
Das Programm zur Konfiguration serieller Schnittstellen heißt setserial. setserial wurde dazu entworfen, Konfigurationsinformation einer seriellen Schnittstelle zu setzen oder zu lesen. Diese Information beinhaltet welche IO-Ports und IRQs serielle Schnittstellen benutzen und mit welchem Multiplikator Hochgeschwindigkeitsverbindungen bearbeitet werden.
Normalerweise wird setserial über ein init-Script beim Systemstart für alle angeschlossenen seriellen Schnittstellen gestartet um sie zu konfigurieren. Ohne besondere Parameter gibt setserial die Informationen über eine bestimmte serielle Schnittstelle aus.
Die vier standardmäßigen seriellen Schnittstellen des PC werden als /dev/ttyS0 bis /dev/ttyS3 bezeichnet. Mit diesen Bezeichnungen kann setserial arbeiten. Der Aufruf von
setserial /dev/ttyS0
gibt uns beispielsweise folgende Ausgabe:
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
Um jetzt Einstellungen vorzunehmen, müssen dem Programm setserial mehr Parameter mitgegeben werden. Die Aufrufform ist dabei
setserial Gerätedatei Parameter
Wichtige solcher Einstellungsparameter sind
port Portnummer
setzt die IO-Portadresse der angegebenen Schnittstelle
irq IRQ-Nummer
setzt den IRQ der angegebenen Schnittstelle
uart UART-Typ
setzt den verwendeten UART Baustein (Universal Assynchronous Receiver Transmitter – der Chip, der die ser. Schnittstelle ansteuert). Gültige Werte sind: none, 8250, 16450, 16550, 16550A, 16650, 16650V2, 16654, 16750, 16850, 16950, und 16954. Der Wert none schaltet die Schnittstelle aus.
Viele Anwendungen, die mit seriellen Schnittstellen und Modems arbeiten kennen nur Geschwindigkeitseinstellungen bis zu 38,4 kb. Moderne Modems erfordern aber wesentlich schnellere Verbindungen zwischen Rechner und Modem, da diese Modems selbst noch Datenkompression anbieten, also mehr Daten zwischen Rechner und Modem transportiert werden müssen, als zwischen Modem und Modem. Damit auch ältere Anwendungen mit diesen Hochgeschwindigkeitsschnittstellen arbeiten können, bietet setserial die Möglichkeit an, verschiedene Flags zu setzen, die eine höhere Geschwindigkeit anschalten, wenn die Anwendung 38,4 kb anfordert.
spd_normal
Benutzt 38,4kb wenn die Anwendung 38,4kb einstellt.
spd_hi
Benutzt 57,6kb wenn die Anwendung 38,4kb einstellt.
spd_vhi
Benutzt 115kb wenn die Anwendung 38,4kb einstellt.
spd_shi
Benutzt 230kb wenn die Anwendung 38,4kb einstellt.
spd_warp
Benutzt 460kb wenn die Anwendung 38,4kb einstellt.
Natürlich muß der verwendete UART diese Geschwindigkeiten tatsächlich unterstützen. Um also die von LPI geforderte Einstellung von 115kb auf der Schnittstelle /dev/ttyS0 vorzunehmen schreiben wir:
setserial /dev/ttyS0 spd_vhi
ein erneuter Aufruf von
setserial /dev/ttyS0
bringt uns jetzt die Ausgabe:
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3, Flags: spd_vhi
Wenn eine Anwendung jetzt 38,4kb anfordert, wird die Schnittstelle in Wahrheit mit 115kb angesteuert.
Konfiguration eines Modems
Ein Modem wird über einen seriellen Port angeschlossen. Entweder ist es ein externes Modem, dann wird die Verbindung direkt über einen existierenden Port und ein serielles Kabel hergestellt, oder das Modem ist eine interne Steckkarte, die einen eigenen – zusätzlichen – seriellen Port enthält. Auch dieser zusätzliche serielle Port muß entsprechend mit setserial konfiguriert werden.
Modems werden über einen Befehlssatz gesteuert, der nicht hundertprozentig standardisiert ist. Grundsätzlich beginnen Modembefehle mit dem Wort AT, dem weitere Zeichen folgen. Die genauen Befehle müssen dem jeweiligen Modemhandbuch entnommen werden. Hier ein kleiner Überblick über die Befehle, die in der Regel alle Modems kennen. Jeder der folgenden Befehle muß mit einem Enter abgeschlossen werden, damit ihn das Modem überhaupt erst ausführt:
AT Das Modem antwortet mit OK. Tut es das nicht, so stimmt etwas mit der Kommunikation zwischen Modem und Rechner nicht.
ATD Nummer Das Modem wählt die angegebene Nummer und baut eine Verbindung auf.
ATH0 Modem legt auf
ATH1 Modem nimmt ab
ATXZiffer Stellt das Modem-Verhalten beim Verbindungsaufbau ein.
* ATX0 – Modem wählt und meldet CONNECT bei erfolgreichem Verbindungsaufbau
* ATX1 – Modem wählt und meldet CONNECT (Geschwindigkeit)
* ATX2 – Modem wartet auf Freizeichen, wählt und meldet CONNECT (Geschwindigkeit).
* ATX3 – Modem wählt und meldet CONNECT (Geschwindigkeit) oder BUSY (belegt). X3 sollte bei Nebenstellenanlagen verwendet werden, um das Warten auf ein Freizeichen der Amtsleitung zu vermeiden.
* ATX4 – X4 Modem wartet auf Freizeichen, wählt und meldet CONNECT (Geschwindigkeit).
* ATX5 – Modem wählt und meldet CONNECT (Geschwindigkeit), Busy, Voice (Telefon anstatt eines Modems an der Gegenstelle).
* ATX6 – Modem wartet auf Freizeichen, wählt und meldet CONNECT (Geschwindigkeit), Busy (belegt), Voice.
ATS0=0 Das Modem nimmt nicht selbstständig Anrufe entgegen. ATS0=1 bedeutet das Modem nimmt nach einem Läuten ab, S0=2 wäre nach zweimal Klingeln abheben …
AT&W Das Modem speichert seine gegenwärtige Einstellung
ATZ Das Modem liesst die gespeicherte Einstellung und aktiviert sie.
Jedes Datenfernübertragungsprogramm wie z.B. minicom, aber auch andere Programme, die mit Modems arbeiten, wie etwa die Programme, die PPP und SLIP Verbindungen aufbauen, müssen diese Befehle nutzen. Normalerweise wird entweder ein Modeminitialisierungsbefehl angegeben, der alle notwendigen Einstellungen enthält wie etwa
ATS0=0 X3
oder es ist vorher dafür gesorgt worden, daß das Modem seine Einstellungen gespeichert hat, dann genügt ein
ATZ
Nun sollte das Modem für ausgehende Verbindungen konfiguriert sein.
Alle Artikel zur LPIC unterliegen der GNU Free Documentation License.

Quellen, Weblinks:

(222)

1.101.5 Einrichtung verschiedener PC-Erweiterungskarten

800px-Uganda-Kob

Wikimedia Commons Frank Dickert

Aus dem Bereich 1.101 Hardware und Systemarchitektur der Unterlangen für die Linux Zertifizierung LPIC-1 [101]
Quellen, Weblinks
Prüfungskandidaten sollten in der Lage sein, verschiedene Karten für die unterschiedlichen Erweiterungssteckplätze zu konfigurieren. Sie sollten die Unterschiede zwischen ISA- und PCI-Karten in Hinsicht auf Konfigurationsfragen kennen. Dieses Lernziel beinhaltet das korrekte Setzen von Interrupts, DMAs und I/O-Ports der Karten, speziell um Konflikte zwischen Geräten zu vermeiden. Ebenfalls enthalten ist die Verwendung von isapnp, wenn es sich um eine ISA PnP-Karte handelt.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen: * /proc/dma, /proc/interrupts, /proc/ioports, /proc/pci, pnpdump(8), isapnp(8), lspci(8)
Alles, was für dieses Thema wichtig ist, wurde schon in den Abschnitten
* Hardwareparameter, * Das /proc-Verzeichnis und * Plug and Play mit Linux
besprochen. Hier also nur noch eine kurze Zusammenfassung:
Unterschied zwischen ISA und PCI
# Die Unterschiede zwischen ISA-Karten und PCI Karten wurden im Groben bereits unter Hardwareparameter besprochen. Wichtig ist hier insbesondere, daß PCI ein System ist, das die bei ISA eher wackelige Funktionalität des Plug and Play wirklich standardisiert übernommen hat. Das heißt, es existieren weltweite Standards, wie sich eine PCI-Karte gegenüber dem System ausweist. Jeder Hersteller von PCI-Karten ist zentral registriert (ähnlich wie bei der Vergabe der Hardware-Adressen bei Netzwerkkarten) und hat eine eindeutige ID. Jedes Gerät, das der Hersteller produziert, bekommt wiederum eine eindeutige ID, die bei der Bestimmung der Funktionalität hilft. Zudem hat jede PCI-Karte die entsprechenden Informationen (IDs und ausgeschriebene Beschreibung) auf einem kleinen ROM-Speicherstein gespeichert und kann sich so gegenüber einem System ausweisen. Linux speichert die Informationen über diese IDs in der Datei /usr/share/misc/pci.ids.
Im Gegensatz zu ISA-Karten ist also bei PCI Karten niemals die manuelle Vergabe von Hardware-Parametern (IO-Ports, IRQs, DMA-Kanäle) notwendig. Linux unterstützt die PCI-Technik vollständig.
Die ISA Karten benötigen unter Linux grundsätzlich immer diese Parameter, egal, ob sie alte Karten mit manueller Einstellung sind, oder Plug and Play Karten. Bei den letzteren wird das Programm isapnp benutzt, um die Einstellungen festzulegen, beim Laden der Module müssen die Einstellungen aber trotzdem vorgenommen werden.
Um von Vorneherein Mißverständnisse auszuschließen, hier noch eine kurze Beschreibung des AGP-Busses für Graphikkarten. Der AGP-Bus ist – technisch gesehen – ein eigenständiger PCI-Bus mit einer anderen Bauform der Steckverbinder. Dieser Bus hat nur einen Steckplatz und der ist für die Graphikkarte gedacht. Der Grund für diese Technik liegt in dem besonders großen Datentransfer-Volumen von Graphikkarten. Um einen ungebremsten Transfer zwischen Computer und Monitor sicherzustellen, wurde für diese Aufgabe ein eigenständiger Bus entwickelt, bei dem sich die Graphikkarte die Leistung des Bussystems nicht mit anderen Karten teilen muß.
PCI-Bussysteme werden intern ähnlich adressiert wie SCSI-Systeme. Auch hier gibt es eine dreigeteilte Adressierung in der Form
Busnummer:Steckplatznummer.Funktionsnummer
Die Busnummer für den normalen PCI-Bus ist 00, die für den AGP-Bus ist 01. Die beiden Bussysteme werden also tatsächlich als unterschiedliche Systeme behandelt. Die Funktionsnummer steht für das jeweilige Gerät, das die entsprechende Funktionalität zur Verfügung stellt.
Das Programm lspci
Damit Linux in die Lage versetzt wird, den PCI-Bus zu scannen, existiert das Programm lspci. lspci ist ein Hilfsmittel, um Informationen über alle PCI-Bussysteme des Systems und alle dort angeschlossenen Geräte darzustellen.
Das Programm lspci ermöglicht es, genau zu bestimmen, welche Geräte (Karten) am PCI-Bus angeschlossen sind und als was sie sich ausgeben. Das ist insbesondere wichtig, um herauszufinden, welche Chipsätze oder Kompatibilitätskriterien bestimmte Karten aufweisen, um mit dieser Information dann das entsprechende Modul zu laden. Moderne Linux-Distributionen, die bei der Installation selbstständig herausfinden, welche Karten angeschlossen sind (Hardwareerkennung) bedienen sich dieses Programms.
Die eigentlichen Informationen, welche Hersteller und welche Geräte die gefundenen Ergebnisse repräsentieren, wird die systemweite Datenbank /usr/share/misc/pci.ids benutzt. Durch den Parameter -n wird lspci dazu gezwungen, diese Datei nicht zu konsultieren, sondern die Ergebnisse numerisch auszugeben.
Linux Kernel, die neuer als die Version 2.1.82 sind, stellen zudem im Verzeichnis /proc/pci weitere Informationen (binär) zur Verfügung. Das Verzeichnis enthält für jeden PCI-Bus ein entsprechendes Unterverzeichnis, das wiederum für jede angeschlossene Karte eine Datei beinhaltet.
Alle Artikel zur LPIC unterliegen der GNU Free Documentation License.

Quellen, Weblinks:

(346)

1.101.4 Einrichten von SCSI-Geräten

800px-Uganda-Kob

Wikimedia Commons Frank Dickert

Aus dem Bereich 1.101 Hardware und Systemarchitektur der Unterlangen für die Linux Zertifizierung LPIC-1 [101]
Quellen, Weblinks
Prüfungskandidaten sollten in der Lage sein, SCSI-Geräte unter Verwendung des SCSI-BIOS und der notwendigen Linux-Werkzeuge zu konfigurieren. Sie sollten ebenso fähig sein, zwischen den verschiedenen SCSI-Typen zu unterscheiden. Dieses Lernziel beinhaltet die Handhabung des SCSI-BIOS zum Auffinden von verwendeten und freien SCSI-IDs und zum Setzen der korrekten ID-Nummer für verschiedene Geräte, im speziellen für das Boot-Device. Ebenso enthalten ist das Verwalten der Einstellungen im System-BIOS zur Bestimmung der gewünschten Bootreihenfolge, wenn sowohl SCSI- als auch IDE-Laufwerke verwendet werden.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen sind:
SCSI-ID, /proc/scsi, scsi-info
Das Small Computer System Interface (SCSI) ist jahrelang die Profi-Schnittstelle für Geräte wie Festplatten, CD-ROMs aber auch Scanner und anderer externer Geräte gewesen. Auch heute noch finden sich in den meisten Server-Installationen SCSI Geräte, anstelle der sonst üblichen IDE-Platten. SCSI-Geräte sind in der Regel um einiges teurer als ihre IDE-Pendants, bieten aber oft eine bessere Eignung für den Dauerbetrieb und haben auch sonst Features, die unter IDE nicht oder nur schwer zu realisieren sind (Hot-Pluging).
Grundsätzliche Architektur von {de:SCSI}
SCSI ist ein Bussystem, das bis zu 8 Geräte (16 Geräte bei Wide-SCSI) verwalten kann. Eines der 8 (oder 16) Geräte ist der SCSI-Hostadapter selbst. Der Hostadapter (oft fälschlicherweise als SCSI-Controller bezeichnet) ist das SCSI-Gerät, das den Bus mit dem Computer verbindet.
Grundsätzlich besteht ein SCSI System aus einem Bus, der in der Regel im Inneren des Computers durch ein 50poliges Flachbandkabel realisiert wird. Nach außen hin (für externe Geräte wie Scanner) wird ein abgeschirmtes Spezialkabel verwendet. An diesem Bus hängen die SCSI-Geräte, auch der Hostadapter.
Beim Aufbau des Busses müssen folgende Punkte beachtet werden:
* Der Bus darf nur zwei Enden haben, T-Stücke (Abzweigungen) sind verboten.
* Jedes Ende des Busses muß mit einem Terminator (Abschlußwiderstand) abgeschlossen sein. (Die Werte betragen 330 Ohm gegen Masse und 220 Ohm gegen +5V.) Heute werden diese Widerstände entweder softwaremäßig oder gar automatisch gesetzt. Bei älteren SCSI-Geräten war hier noch Steckarbeit erforderlich.
* Der Leitungsabstand zwischen zwei SCSI Geräten muß mindestens 10 cm betragen.
* Der SCSI Bus darf eine Gesamtlänge von drei Metern nicht überschreiten. (Bei mehr als vier Geräten darf er bei klassischem SCSI sogar nur 1,5 Meter lang sein.)
* Bastlerverbindungen (Pfostenstecker o.ä.) sind nicht zulässig, das Flachbandkabel muß durchgängig sein.
* Der Bus darf nicht durch ein offenes Kabelende abgeschlossen sein, d.h., daß selbst wenn nur ein Gerät (außer dem Adapter) angeschlossen ist immer der letzte Anschluß des Kabels verwendet werden muß.
Diese Regeln sind unbedingt einzuhalten, sonst kommt es mit Sicherheit zu Fehlern, deren Ursache oft sehr schwer ermittelbar ist.
Unterschiedliche SCSI-Typen
SCSI ist ein gewachsenes System, das in verschiedenen Generationen auftritt. Die ursprünglichen Bezeichnungen SCSI, SCSI2 und SCSI3 haben mehr zur Verwirrung beigetragen, als zur Klärung, daher werden heute die folgenden Begriffe verwendet:
SCSI (oder SCSI1)
Das klassische SCSI, bis zu 8 Geräte (7+Hostadapter) an einem 50poligen Kabel. Es wurde 1986 standardisiert, seitdem können alle SCSI-Hostadapter Geräte ansteuern, die diesem Standard folgen.
SCSI2 (Wide-SCSI-2)
Eine Erweiterung des SCSI-Befehlssatzes, die hauptsächlich auch die Ansteuerung anderer Geräte als Festplatten ermöglichte. Diese Form von SCSI wurde weiter aufgespalten in eine schnellere Variante (Fast SCSI2) und eine Variante mit der Möglichkeit mehrere Geräte (16 statt 8) anzuschließen .
SCSI3 (oder Ultra SCSI)
SCSI3 ist noch nicht vollständig fertig entwickelt, trotzdem bieten es einige Hersteller schon an. Es zeichnet sich durch eine noch höhere Geschwindigkeit aus. Für SCSI3 existieren auch völlig neue Kabelformen (Glasfaser, serielle Übertragung), die aber keine Bedeutung für die LPI-Prüfung haben.
Die Wide-SCSI Varianten benutzen statt einem 50poligen Kabel (8-Bit-Bus) ein 68poliges Kabel (16 Bit Bus), damit die einzelnen Geräte adressiert werden können. Die folgende Tabelle zeigt die verschiedenen Kombinationsmöglichkeiten, die auf dem Markt sind, samt ihren maximalen Transferraten:
Busbreite Kabelbreite Standard Fast Ultra
8-Bit 50-polig 5 MB/sec 10 MB/sec 20 MB/sec
16-Bit 68-polig 10 MB/sec 20 MB/sec 40 MB/sec
Durch entsprechende Kombinationen entstehen dadurch etwas verständlichere Namen wie Ultra-Wide-SCSI oder Fast-Wide-SCSI,…
Adressierung im SCSI-Bus
Jedes SCSI Gerät muß über eine SCSI-ID verfügen, also einer numerischen Adresse, über die es eindeutig ansprechbar ist. Diese Eindeutigkeit bedeutet, daß kein SCSI Gerät in einem Bus die gleiche ID wie ein anderes haben darf. Die IDs beginnen mit der Null und enden mit der Sieben (Normales SCSI) oder der 15 (Wide-SCSI) Es gibt inzwischen auch schon Versuche mit 32 Geräten, die erfordern jedoch ganz andere Kabel und zum Teil auch andere Protokolle. (Es ist schlicht unmöglich auf einem 1,5 Meter langen Kabel 32 Geräte mit einem Mindestabstand von 10 cm anzuschließen.)
Der Hostadapter hat üblicherweise die ID 7. Die Vergabe der ID sollte nicht wahllos geschehen, den die höchste ID hat immer auch die höchste Priorität im System. Hingegen hat die ID nichts mit der physikalischen Position am Bus zu tun.
Die IDs müssen entweder softwaremäßig (Adapter) oder über Schalter (externe Geräte) und Jumper (interne Geräte) eingestellt werden. Falls eine reine SCSI-Installation ohne IDE Platten eingerichtet werden soll, muß die Bootfestplatte die ID 0 haben.
Neben der SCSI-ID gibt es für jedes Gerät noch eine sogenannte LUN (Logical Unit Number), die eventuell existierende Untergeräte addressiert. So kann etwa ein SCSI-Plattenschrank mit 5 Festplatten aus der Sicht des SCSI-Busses nur ein Gerät mit einer SCSI-ID sein. Um die einzelnen Platten trotzdem ansprechen zu können werden die eigentlichen SCSI-IDs der Platten jetzt zu den LUNs des Plattenschrankes.
Um auch mehrere SCSI-Hostadapter in einem Rechner betreiben zu können, bekommt auch der SCSI-Bus selbst eine Nummerierung. Auch diese Busnummer fängt mit 0 zu zählen an, der erste SCSI-Bus hat also die Busnummer 0, der zweite die 1 usw.
Aus der Kombination der drei Angaben (durch Komma getrennt) lässt sich so eine eindeutige Adressierung innerhalb eines Systems erreichen. Jedes SCSI-Gerät kann mit der Adresse
Busnummer,SCSI-ID,LUN
angesprochen werden. In den meisten Fällen werden Busnummer und LUN jeweils auf 0 gesetzt sein (wenn nicht mehrere SCSI-Adapter oder Geräte mit Untergeräten im Einsatz sind).
Das SCSI-BIOS
SCSI ist ein intelligentes Subsystem, von dem das Standard-BIOS des PC nichts weiß. Die Ansteuerung von SCSI-Geräten erfolgt durch entsprechende Gerätetreiber des Betriebssystems. Das ist weiter kein Problem, wenn das Betriebssystem von einem Medium gebootet werden kann, das vom BIOS erkannt wird. Auf einem System, das nur SCSI-Platten aufweist, ist das aber nicht möglich.
Auf einem solchen System muß ein Hostadapter mit eigenem BIOS installiert werden, damit auch von SCSI-Geräten gebootet werden kann. In diesem Punkt unterscheiden sich die Hostadapter stark voneinander. Billige Adapter, wie sie etwa beim Kauf eines SCSI-Scanners mitgeliefert werden, besitzen kein eigenes BIOS sondern dienen ausschließlich der Ansteuerung von SCSI-Geräten im laufenden Betrieb. Teurere Adapter weisen ein eigenes BIOS auf, das – analog zum BIOS des Computers selbst – auch ein Setup-Programm beinhaltet.
Durch eine Tastenkombination beim Hochfahren des Rechners (etwa Strg-A bei Adaptec-Adaptern) wird das Setup-Programm des SCSI-BIOS gestartet. Hier können verschiedene Einstellungen vorgenommen werden, die den Adapter selbst und die angeschlossenen Geräte betreffen (etwa seine SCSI-ID) und Informationen über alle angeschlossenen Geräte ermittelt werden. Dazu zählen insbesondere
* Ermittlung aller vergebenen SCSI-IDs
* Einstellungen die Transferrate betreffend
* Einstellung, von welchem Gerät gebootet werden soll
Manche modernen SCSI-Geräte sind auch in der Lage, ihre SCSI-ID softwaremäßig einzustellen, was dann auch innerhalb dieses Programms vorgenommen werden kann.
Booten von SCSI-Geräten
Wenn von einem SCSI-Gerät gebootet werden soll, müssen die oben genannten Einstellungen im SCSI-BIOS vorgenommen werden. SCSI-Hostadapter ohne eigenes BIOS eignen sich nicht, um zu booten.
Im System-BIOS muß dann noch eingestellt werden, daß von einem SCSI-Gerät gebootet werden soll. Um welches Gerät es sich handelt, kann das System-BIOS nicht bestimmen, dazu hat der Hostadapter ja sein eigenes BIOS. Bei der Einstellung der Boot-Reihenfolge im System-BIOS (Bootsequence) wird einfach nur SCSI angegeben. In diesem Fall übergibt das System-BIOS die Aufgabe des Bootens an das SCSI-BIOS, das wiederum über die entsprechenden Informationen verfügt, von welchem Gerät gebootet werden soll.

SCSI im Linux-System
Im /proc-Verzeichnis findet sich ein Unterverzeichnis scsi, das alle gefundenen SCSI-Hostadapter wiederum als Unterverzeichnis enthält. Jedes dieser Unterverzeichnisse enthält wiederum eine Datei, die eine Nummer als Namen trägt. Das ist die Nummer, mit der der SCSI-Bus an diesem Adapter bezeichnet wird. Die Datei selbst enthält Informationen über den entsprechenden Adapter.
Ein Beispiel: Auf einem Linux-System sind ein Adaptec-SCSI Adapter AHA-2940 und ein Zip-Laufwerk am Parallelport installiert. Auch das Zip-Laufwerk ist ein SCSI-Gerät, der Parallelport dient hier als SCSI-Adapter (PPA-ParallelPort Adapter). Im Verzeichnis /proc/scsi findet sich folgender Inhalt:
dr-xr-xr-x … aic7xxx
|
+ -rw-r–r– … 0
dr-xr-xr-x … ppa
|
+ -rw-r–r– … 1
-r–r–r– … scsi
Jedes der beiden Verzeichnisse enthält eine Datei. Das Verzeichnis aic7xxx enthält eine Datei mit Namen 0, das Verzeichnis ppa eine mit Namen 1. Der Bus am Adaptec-Adapter ist also Bus 0, der am Parallelport Bus 1. Die Datei scsi enthält Informationen über alle angeschlossene Geräte, egal auf welchem Bus sie hängen.
Die Namensgebung von SCSI-Geräten unter Linux
Die Namen der SCSI-Geräte unter Linux sind abhängig von der Reihenfolge, in der die Hostadapter beim Booten erkannt werden. Die einzelnen Platten werden anhand der Reihenfolge ihrer Erkennung durchnummeriert. So ist die erste erkannte Festplatte auf dem ersten erkannten SCSI-Adapter die Platte mit dem Namen /dev/sda. Die nächste Platte des selben Adapters bekäme den Namen /dev/sdb. Sind keine weiteren Platten mehr angeschlossen, beginnt das gleiche Spiel beim nächsten Adapter wieder. Die dortige Platte, die zuerst erkannt wurde wäre also in unserem Beispiel /dev/sdc…
CDROM-Laufwerke bekommen entsprechend die Namen /dev/sr0, /dev/sr1,… oder auch (gleichzeitig) /dev/scd0, /dev/scd1,… Das sr steht für SCSI-Removable also SCSI-Wechselplatte.
Eine andere Form der Adressierung wäre eindeutiger, die schon bekannte Form
Busnummer,SCSI-ID,LUN
Um die beiden Adressierungsformen zueinander in Verbindung zu bringen, existiert das kleine Programm scsi_info, dem als Parameter der Name der Gerätedatei eines beliebigen SCSI-Gerätes mitgegeben wird. Als Ausgabe gibt das Programm dann die Adresse in der Form Busnummer,SCSI-ID,LUN und weitere Informationen aus /proc/scsi/scsi. Ein Aufruf von
scsi_info /dev/sda
ergibt beispielsweise eine Ausgabe wie
SCSI_ID="0,2,0"
MODEL="IBM DFHSS1F !c"
FW_REV="1717"

Mit diesem Hilfsmittel ist es also möglich, die tatsächlichen physikalischen Adressen zu ermitteln.
Alle Artikel zur LPIC unterliegen der GNU Free Documentation License.

Quellen, Weblinks:

(437)

1.101.3 Konfiguration von Modem und Soundkarten

800px-Uganda-Kob

Wikimedia Commons Frank Dickert

Aus dem Bereich 1.101 Hardware und Systemarchitektur der Unterlangen für die Linux Zertifizierung LPIC-1 [101]
Quellen, Weblinks
Prüfungskandidaten sollten in der Lage sein sicherzustellen, daß die Geräte Kompatibilitätskriterien erfüllen (speziell, daß es sich bei einem Modem NICHT um ein Win-Modem handelt). Ebenfalls enthalten ist die Überprüfung, daß sowohl Modem und Soundkarte eigene und die richtigen Interrupts, I/O- und DMA-Adressen verwenden, die Installation und Ausführung von sndconfig und isapnp bei PnP-Soundkarten, die Konfiguration des Modems für DFÜ und PPP/SLIP/CSLIP-Verbindungen und das Setzen des seriellen Ports auf 115.2 kbps.
Die Konfiguration von Modem und Soundkarte enthält nichts, was hardwaremäßig sich von anderen Karten unterscheiden würde oder was nicht von anderen Themen dieser Prüfungsziele auch schon behandelt wäre. Insbesondere der Abschnitt 1.101.6 – Konfiguration von Kommunikationsgeräten deckt den Bereich Modem vollständig ab.
Kompatibilitätskriterien
Bemerkenswert sind die Kompatibilitätskriterien für diese beiden Gerätearten. Bei der Anschaffung eines Gerätes, das unter Linux betrieben werden soll, ist es natürlich einfach, entsprechend darauf zu achten, daß es sich um Geräte handelt, die auch unter Linux betrieben werden können. Es gibt sowohl Kompatibilitätslisten einzelner Distributoren, als auch unabhängige Aufzählungen, welche Hardware von Linux mit welchem Treiber angesprochen werden kann. Ein guter Startpunkt für die Suche ist hierbei das Hardware-HOWTO des Linux-Documentation-Project.
Schlimmer sieht es aus, wenn mit bestehender Hardware auf Linux umgerüstet werden soll. In diesem Fall kann es hin und wieder vorkommen, daß die entsprechenden Geräte nicht, oder nur eingeschränkt benutzbar sind. Ein typisches Beispiel für solche Geräte sind die sogenannten Winmodems, die hier noch einer genaueren Betrachtung unterworfen werden sollen.
Winmodems
Früher waren alle Modems eigenständige Geräte, die eine eigene Logik und Steuerung enthielten. Das einzige Problem am Anschluß eines Modems war (und ist – bei echten Modems – bis heute) die Einstellung der verwendeten seriellen Schnittstelle und ihrer Kommunikationsparameter. Wenn der Computer das Modem ansprechen konnte, dann konnte er es auch benutzen. Modems benötigen eigentlich keinerlei Treiber, sondern ein Programm, das ihren Befehlssatz kennt. Die normalen Modems arbeiten alle mit einem Befehlssatz, der kompatibel zum früheren Marktführer auf diesem Gebiet, der Firma Hayes, ist. Dieser Befehlssatz beginnt alle Befehle mit einem AT (Attention prefix) und antwortet mit entsprechenden Meldungen wie OK… Ein Programm zur Ansteuerung eines Modems musste also nur diese Befehle kennen und konnte mit dem Modem umgehen. In der Regel konnte der Benutzer des Programms die entsprechenden Befehle (wählen, auflegen, …) in eine Konfigurationsmaske eintragen und das Programm konnte dann damit arbeiten.
Moderne, sogenannte Winmodems, arbeiten leider nicht mehr mit diesem Prinzip. Aus Kostengründen ist den Modems die Eigenintelligenz gestrichen worden, das heißt, der Rechner muß den größten Teil der Arbeit leisten. Solche Modems halten sich an keinen Standard, sondern benötigen entsprechende Gerätetreiber. Diese Treiber werden in der Regel nur für Windows ausgeliefert, was es in einigen Fällen unmöglich macht, unter Linux mit diesen Modems zu arbeiten. Das Linux Documentation Project hat ein spezielles Winmodem-Howto zu diesem Thema zusammengestellt. Außerdem gibt es eine Webseite unter linmodems.org, auf der Versucht wird, auch Winmodems unter Linux zum Laufen zu bringen.
Architektur von Sound unter Linux
Es gibt unter Linux verschiedene Arten, wie eine Soundkarte zum Laufen gebracht werden kann. Die LPI-Examensziele nennen in diesem Zusammenhang nur die OSS-Technik, die hier also kurz angesprochen werden soll.
Bei {de:Open_Sound_System|OSS} (Open Sound System) handelt es sich um eine Treiberschnittstelle zum Kernel, die neben der eigentlichen Schnittstelle noch sogenannte Low-Level Treiber für jede Soundkarte benötigt. Es gibt eine große Menge solcher Treiber für fast alle Soundkarten, die manchmal aber nur rudimentäre Unterstützung gewährleisten. Alle Treiber können als Module oder als fester Bestandteil des Kernels implementiert werden, heute wird sich aber auf die Verwendung von Modulen beschränkt.
Die meisten {de:Soundkarte}n sind heute PCI-Karten, es existieren aber immer noch alte ISA und ISA-PnP Karten, für die all das gilt, was unter Hardwareparameter und isapnp schon gesagt wurde. Zur einfacheren Installation von Soundkarten hat der Distributor RedHat ein kleines Programm geschrieben, das inzwischen auch für andere Distributionen erhältlich ist, sndconfig. Dieses Programm scant die Bussysteme durch und sucht Soundkarten. Falls es sich um ISA-PnP Karten handelt, erledigt sndconfig gleich die Aufgabe, mit isapnp die entsprechenden Einstellungen menügeführt vorzunehmen.
Voraussetzung für die Verwendung von sndconfig ist die Verfügbarkeit von OSS-Treibern und der OSS-Schnittstelle im Kernel. sndconfig ist ein menügeführtes Programm, das im Normalfall keine Kommandozeilenparameter benötigt.
Alle Artikel zur LPIC unterliegen der GNU Free Documentation License.

Quellen, Weblinks:

The ISAPNPTOOLS home page
Multimedia
Configuring Sound in Debian GNU/Linux
Linux Modem-HOWTO
LinuxHardware – SoundKarten

(265)