OXE800 / OXE810

OXE810DSE Chip

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

Familie Beschreibung
2010 NAS 782x NAS 7820 mit einfachem SATA II
NAS 7821/7825 mit doppeltem SATA (bis RAID1)
2x ARM 11 MP, 750 MHZ
2008 OXE810 OXE810SE mit einfachem SATA
OXE810DSE mit doppeltem SATA (bis RAID1)
ARM 926EJ-S, 367 MHZ
2007 OXE800 OXE800SE mit einfachem SATA
OXE800DSE mit doppeltem SATA (bis RAID1)
ARM 926EJ-S, 200 MHZ

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.

Speicherbereiche und Peripherie

Adresse U-Boot Definition Beschreibung
0x28000000EXT_UART_BASE externer UART Controller
0x40400000MAC_BASE_PA 10/100/1000 Ethernet Controller
0x41000000STATIC_CS0_BASE_PA CS0 Speicherbereich für externe Controller
0x41400000STATIC_CS1_BASE_PA CS1 Speicherbereich für externe Controller
0x41800000STATIC_CS2_BASE_PA CS2 Speicherbereich für externe Controller
0x41C00000STATIC_CONTROL_BASE_PA (DDR2 Memory Controller ???)
0x42000000SATA_DATA_BASE_PA SATA II Controller
0x44000000APB_BRIDGE_A_BASE_PA AMBA Bridge A (AHB zu APB A)
+ 0x000000 GPIO_1_PA GPIO Controller 1
+ 0x100000 GPIO_2_PA GPIO Controller 2
+ 0x200000 UART_1_BASE interner UART Controller 1 (NS16550)
+ 0x300000 UART_2_BASE interner UART Controller 2 (NS16550)
+ 0x900000 UART_3_BASE interner UART Controller 3 (NS16550)
+ 0xA00000 UART_4_BASE interner UART Controller 4 (NS16550)
0x45000000APB_BRIDGE_B_BASE_PA AMBA Bridge B (AHB zu APB B)
+ 0x000000 SYS_CONTROL_BASE_PA System Controller
+ 0x300000 RPS_BASE (Systemtakt ???)
+ 0x600000 DMA_BASE_PA DMA Controller
0x48000000PHYS_SDRAM_1_PA Anfang externer SDRAM (DDR2)
PHYS_SDRAM_1_MAX_SIZE maximale SDRAM Größe 256MB
0x58000000CFG_SRAM_BASE Anfang interner SRAM
CFG_SRAM_SIZE maximale SRAM Größe 128kB

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.

SATA Boot

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.

OXNAS MBR

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:

Adress Description Size in bytes
Hex Dec
+000h +0 (always set to zero) 420
+1A4h +420 Secondary OXNAS Boot parameter blocks 12
+1B0h +432 Primary 12
+1BCh +444 0000h Disk signature 2
+1BEh +446 Partition entry #1 Partition table 16
+1CEh +462 Partition entry #2 16
+1DEh +478 Partition entry #3 16
+1EEh +494 Partition entry #4 16
+1FEh +510 55h Boot signature 2
+1FFh +511 AAh

OXNAS Boot-Parameterblock

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:

Adress Description Size in bytes Example
Hex Dec
+000h +0 Checksum 4 20570h start + length
+004h +4 Sector number to start 4 2970h 10608 sectors
+008h +8 Number of bytes to copy (≤ 128kB) 4 1DC00h 238 sectors · 512 byte = 121856 byte

OXNAS Boot-Paket

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:

Adress Description Size in bytes Example
Hex Dec
+000h +0 Relative jump to NOP 4 E28FF038h add pc, pc, #56
+004h +4 Gap (always set to zero) 44 0000..00h .org 0x30
+030h +48 Image length 4 000172C8h .word 94920
+034h +52 Image CRC-32 4 1CA7AF7Ah .word 0x1ca7af7a
+038h +56 Header CRC-32 (0..037h) 4 70DC707Ch .word 0x70dc707c
+03Ch +60 NOP Mnemonik 4 E1A00000h nop
+040h +64 Image content, stage2 94920 ea000013 e59ff014 e59ff014 …

CRC-32

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$