SATA-HDD und SD-Karte ersetzen SCSI-Technologie

Anbieter zum Thema

MicroConsult Academy GmbH

ISH Ingenieursozietät GmbH

Syslogic GmbH

Tieto Deutschland GmbH

Rückblick in die SCSI-Zeit

Zum besseren Verständnis ein Rückblick in die alte SCSI-Zeit. So werden z.B. für die Abarbeitung eines SCSI-READ-Kommandos mehrere Busphasen durchlaufen: Command-Phase (zum Übertragen der Kommandobytes ans Gerät), Message-Phase (zum Festlegen der Art des Bustransfers), Data-Phase (zur Übertragung der Nutzdaten) und Status-Phase (zur Quittierung durch das Gerät), wobei das selektierte Gerät am SCSI-Bus diese Phasen treibt.

Abhängig von der Busphase, steuert ein Mikrocode auf dem HBA lediglich korrespondierende Datentransfers zwischen PU und Gerät, deren Inhalte vom SCSI-Treiber der PU vorgegeben werden. Der Mikrocode ist im RAM der PU gespeichert und wird vom HBA geladen. Während des Abarbeitens eines Kommandos können interrupt-gesteuert mehrfache Interaktionen zwischen HBA und PU erfolgen, um z.B. PU-seitig Datenpuffer nachzufüllen oder parallel das zweite Gerät anzusteuern (während das erste den SCSI-Bus freigegeben hat).

Der SCSI-Treiber der PU ist also stärker mit der SCSI-Busansteuerung verknüpft als man es vermuten würde. Eine der Herausforderungen auf dem neuen Flyer-Subboard besteht somit darin, der PU einen SCSI-Bus inklusive SCSI-Busphasen vorzuspiegeln, den es physikalisch im System nicht mehr gibt.

Detaillierte Analyse des alten SCSI-Treibers erforderlich

Um Aufwand und Komplexität der zu entwickelnden Software in Grenzen zu halten, musste der alte SCSI-Treiber detailliert analysiert werden. Es galt herauszufinden, welche der vielen Features des HBA in welcher Weise genutzt werden und mit welchen Abläufen die neue Software rechnen muss. Eine Realisierung der kompletten Funktionalität des HBA wäre sowohl an der fehlenden Kenntnis des exakten Verhaltens des HBA als auch an inakzeptablem Aufwand gescheitert.

Hierbei wird es paradoxerweise zum Vorteil, dass die Software der PU nicht geändert werden darf: Wäre es nämlich möglich, dass geänderte PU-Software im Glauben, den gleichen HBA vorzufinden, diesem einen geänderten Mikrocode zur Ausführung gäbe, dann müsste man den kompletten Befehlssatz des Mikrocodes für den HBA softwaremäßig emulieren. Da aber der Mikrocode unverändert bleiben muss, genügt es, nur die entsprechende Funktionalität abhängig von den jeweiligen Einsprungstellen des Mikrocodes zu realisieren.

Die neue Hardware-Software-Lösung spiegelt also PU-seitig SCSI-Busphasen vor, in Richtung der Massenspeichergeräte muss sie dagegen den Transfer von der SCSI-Welt in die SATA- und SD-Karten Welt leisten. Dies betrifft sowohl Befehle als auch Quittungen, Fehlerbehandlung und Diagnose. In diesem Fall ist die Wahl von Embedded Linux als Betriebssystem hilfreich.

SCSI-Subsystem des Linux-Kernels steuert das SATA-Festplattenlaufwerk

Linux verfügt über ein sehr ausgereiftes, dreischichtiges SCSI-Subsystem im Kernel. Die oberste Schicht dient als Schnittstelle (via open(), close(), read(), write(), usw.) zu den Applikationen für Gerätetypen wie Festplatte, Bandlaufwerk oder CDROM. Die unterste Schicht bilden die Treiber für die diversen HBAs. Die mittlere Schicht (SCSI Midlayer) leitet als Verbindungsschicht zwischen diesen beiden die Kommandos nach unten weiter, führt Fehler-, Timeout- und Abbruchbehandlungen durch, und übernimmt Geräteerkennungs- und Management-Funktionen.

Das entscheidende Merkmal der mittleren Schicht ist, dass sie nicht nur SCSI-, sondern auch ATA-HBA-Treiber der unteren Schicht bedienen kann. Dies wird über ein spezielles Modul („libata“) realisiert, das SCSI-Befehle, Quittungen, usw. in entsprechende ATA- Instruktionen transformiert. Die Ansteuerung des neuen SATA Festplattenlaufwerks erfolgt somit über das SCSI-Subsystem des Kernels.

Die SD-Karte wird hingegen über das neuere MultiMediaCard Subsystem des Kernels angesteuert, der Host-Controller der SD-Karte ist Teil des FPGA.

(ID:282758)