OXE800 / OXE810

Geräte mit einem OXNAS Controller sind Netzwerkspeichergeräte auf Basis eines OXE810 Prozessors oder seines Vorgängers OXE800. Beide Prozessoren wurden von Oxford Semiconductor entwickelt und sind bereits durch den Nachfolger NAS782x (OXE820) abgelöst. Oxford Semiconductor ist 2009 in PLX Technology aufgegangen.

Diese Seite beschäftigt sich ausschließlich mit den beiden ARM9 Prozessoren OXE800 bzw. OXE810 und nicht mit dem aktuellen Prozessor NAS782x auf Basis des ARM11.

http://www.avnet-israel.co.il/wp-content/uploads/2013/08/PLX_Storage_Products.pdf

Leider stehen alle Dokumentationen zu den Prozessoren unter Verschluss und können nur nach Unterzeichnung einer NDA von PLX Technology bezogen wewrden. Alle hier und im weiteren Verlauf der untergeordneten Seiten getroffenen Aussagen sind Ergebnisse aus meinen Untersuchungen von Opene Source Quellen wie U-Boot oder dem Linux Kernel.

Ein genaues Szenario konnte Mangels ausreichender Dokumentation bisher noch nicht ermittelt werden. Alle Indizien sprechen aber dafür, dass es einen im Prozessor eingebauten stage1 Bootloader gibt, der so genannte OXNAS Boot ROM. Dieser versetzt den Prozessor in die Lage, von einem linearen FLASH Speicher oder auch von einer angeschlossenen SATA Festplatte weiter zu booten. Letzteres wurde durch die Analyse des Iomega Home Media Network Hard Drive genauer untersucht, mit folgendem Ergebnis.

Bei dieser Variante wird der OXNAS Boot ROM dazu benutzt, einen stage2 Bootloader oder andere Software von einer bestimmten Stelle einer angeschlossenen SATA Festplatte zu laden und zu starten. In aller Regel wird das der Bootloader U-Boot sein. Der OXNAS Boot ROM hält sich dabei an folgende Reihenfolge:

1. Sektor 0, den Master Boot Record (MBR), von der SATA Festplatte laden
2. Interpretation des primären Boot-Parameterblock
   1. wenn valid, dann den stage2 Bootloader vom primären Sektor mit vorgegebener Anzahl Bytes in den Prozessor internen SRAM laden
   2. wenn nicht valid, dann mit dem sekundären Boot-Parameterblock fortfahren
3. Interpretation des sekundären Boot-Parameterblock
   1. wenn valid, dann den stage2 Bootloader vom sekundären Sektor mit vorgegebener Anzahl Bytes in den Prozessor internen SRAM laden
   2. wenn nicht valid, dann mit dem primären Boot-Parameterblock fortfahren (u.s.w.)
4. Nach dem Laden des stage2 Bootloaders in Form eines Boot-Pakets wird dessen Kopf-Kennung interpretiert
   1. wenn valid, dann wird der Code durch direkten Sprung an den Anfang des SRAM gestartet
   2. wenn nicht valid, dann beginnt alles von neuem

Dieser Vorgang wurde so bisher nur am Iomega Home Media Network Hard Drive nachvollzogen und muss nicht vollständig der Realität entsprechen.

Der Inhalt des Master Boot Record (MBR) für die Interpretation durch den OXNAS Boot ROM entspricht dem eines klassischen MBR. Anstatt eines 446 Byte umfassenden Bootstrap Codes befinden sich unmittelbar vor der Partitionstabelle zwei von mir als OXNAS Boot-Parameterblock bezeichnete Bereiche.

Der OXNAS Master Boot Record hat folgenden Aufbau:

Der OXNAS Boot-Parameterblock besteht aus drei 32-Bit Werten. Diese dienen der Definition von zwei Werten: woher und wie viele Bytes in den internen SRAM kopiert werden sollen. Dies geschieht durch das festlegen eines Startsektors im 2. Wert und der pauschalen Ladelänge im 3. Wert. Im 1. Wert wird eine einfache Prüfsumme über beide Werte abgelegt. Diese Prüfsumme ist nichts weiter als die Addition des 2. und 3. Werts, also des Startsektors und der Ladelänge.

Ein einzelner OXNAS Boot-Parameterblock hat folgenden Aufbau:

Das OXNAS Boot-Paket ist eine Art Kopf, der dem eigentlich ausführbaren Code vorangestellt ist und dessen Inhalt der Validierung des eigentlichen stage2 Bootloader Codes dient. Der Kopf beinhaltet die exakte Anzahl Bytes des eigentlichen Code (Image) und eine CRC-32 Prüfsumme darüber. Die Kopfdaten selbst sind wiederum über eine CRC-32 Prüfsumme abgesichert. Der OXNAS Boot ROM wird diese Informationen nutzen, um den von der SATA Festplatte in den SRAM kopierten Inhalt zu überprüfen. Ist das erfolgreich, wird er direkt an den Anfang, also an die Adresse im SRAM, wo der Kopf des OXNAS Boot-Paket beginnt, springen. Damit es hier nicht zur Ausführung ungültiger Code Sequenzen kommt, muss also am Kopfanfang ein relativer Sprung an das Kopfende erfolgen. Dort befindet sich dann noch direkt vor dem Start des eigentlichen Codes eine NOP Mnemonik, um die Prozessorpipeline auszuräumen.

Ein OXNAS Boot-Paket hat folgenden Aufbau:

Die benutzte CRC-32 Prüfsumme entspricht dem im HDLC bzw. Ethernet benutzten Polynom (0x04C11DB7):

$x^{32} + x^{26} + x^{23} + x^{22} + x^{16} + x^{12} + x^{11} + x^{10} + x^{8} + x^{7} + x^{5} + x^{4} + x^{2} + x + 1$