Reverse Engineering einer IBM DS3400 Storage Batterie

Heute wurde mal wieder die Batterie unseres Storage-Systems hier in der Arbeit leer… eine neue kostet mindestens 250 € dafür bietet sie eine Willkommene Gelegenheit die alte mal etwas auseinanderzunehmen und vorallem nachzusehen ob man die 250 € nicht durch Eigen-Reparatur etwas verringern kann…

Vorab gleichmal: Dieser Beitrag erschien in ähnlicher Form auch auf der Website des Chaostreff Gunzenhausen, denn dort gab es einen schönen warmen Bastelkeller der mit Getränken und Gummibärchen lockte!

Nun erstmal zu den Grundlagen:
Ein Storage-System für Server ist nichts anderes als viele (bei uns so um die 40) Festplatten die gemeinsam in einem großen Gehäuse sitzen. In diesem Gehäuse dabei ist ein sogenannter Controller der sich drum kümmert die Daten gleichmäßig auf die Platten zu verteilen (grob gesagt). Dieser Controller hat einen sehr schnellen Speicher (Cache) und kann Daten die auf die Platte geschrieben werden zuerst in diesen Speicher schreiben. Das geht sehr schnell, deutlicher schneller als wenn eine Festplatte erst ihren langsamen mechanischen Schreibkopf irgendwo hinbewegen müsste.

Im nächsten Moment „lügt“ nun der Controller das Betriebssystem an und behauptet die Daten wären zu 100% auf der Festplatte gelandet. Das heißt auch wenn das Betriebssytem darauf besteht dass die Daten auf einem dauerhaften Medium (Festplatte) sein sollen (weil die Daten sehr wichtig sind oder ein Neustart anliegt) landen die Daten trotzdem „nur“ im Cache.
Ein paar Sekunden später (wenn der Controller es gerade für sinnvoll hält) werden die Daten dann erst wirklich auf die Festplatten geschrieben.

Diese Lüge kann sich der Controller nur leisten weil er eine Batterie hat. Sollte nämlich der Strom urplötzlich ausfallen wäre der schnelle Cache-Speicher ohne Strom sofort leer. Das passiert aber nicht da es eine Batterie gibt die den Speicher noch tagelang mit Strom versorgen kann. Wenn nun irgendwann wieder Strom da ist so kann der Controller die Daten aus dem Cache endlich auch auf die Platten schreiben und seine Lüge fällt nie auf 🙂

Die Frage ist nun: Wie weiß der Controller ob seine Batterie noch gut ist?
Hier scheint es zwei Möglichkeiten zu geben. Die eine ist ein sogenannter Learn-Cycle. Ds heißt in der Nacht wird der Cache abgeschalten, die Batterie vollständig entladen, danach wieder voll geladen und der Cache wieder aktiviert. Anhand der Messung wieviel Strom die Batterie geliefert hat weiß man wie lange Sie bei einem Stromausfall ausreichen würde.

Der andere Weg (und diesen scheint unser Storage zu gehen) ist eine Mischung aus „Alter der Batterie in Tagen seit Einsetzen ins Storage“ (diesen Wert kann man zurücksetzen) und „Alter der Batterie seit Herstellung“.

Für mich interessant war das Alter der Batterie seit Herstellung. Die Batterie muss dieses ja irgendwo (zusammen mit der Seriennummer) auf ihrer Platine speichern. Und wo ein Speicher ist, da ist auch ein Weg ihn zu lesen (und vielleicht sogar zu schreiben!).

Das Inspizieren der Platine förderte neben der Lithium-Ionen Batterie und einem Hochlastwiderstand (zum Entladen der Batterie) tatsächlich einen Chip mit der Beschriftung „PCA9500“ zu Tage (neben einigem mehr an Hühnerfutter…).
Die Suche nach „PCA9500 Datasheet“ führe zum Datenblatt, und dem Datenblatt nach ist das ein 8-Bit I/O-Expander der ein 2-kbit-EEPROM beinhaltet – also eigentlich der perfekte Ort um ein paar kleinere Daten zu speichern!

Laut dem Datenblatt spricht der Chip I²C – ein beliebter Bus der nur 3 Leitungen benötigt. Details liefert gerne die Wikipedia.

Es galt nun also die Pins am Chip mit den Pins am Anschluss durchzupiepsen. Der Durchgangsprüfer des Multimeters hilft hier, und schnell waren die nötigen Kabel angelötet:

Wobei hier:
Blau = GND
Rot = VCC (3.3V)
Gelb: SCL (clock)
Grün: SDA (data)

Als nächstes wollte ich einen Arduino UNO anstecken um I²C mit dem Chip zu sprechen – aber (ausnahmsweise!) habe ich vorher ins Datenblatt geschaut:
Absolute Maximum Ratings Vdd: 3.6 V

Autsch! Die 5V des Arduino hätten hier wohl für etwas „Magic Smoke“ gesorgt. Zum Glück hatte der Kollege noch einen Raspberry Pi rumfliegen, der arbeitet mit 3.3V und hat auch I²C on-Board. Kann man bequem von der Linux-Shell aus ansteuern. Leider fand er sich nicht im Netzwerk 🙁

Das Netzwerkproblem löste sich dann noch mit einem USB-seriell Kabel (TTL Level) und schon konnte man per USB auf die Konsole des PIs.

Zuerst riefen wir i2cdetect auf und wir konnten den Chip tatsächlich finden!
Es zeigten sich die Adressen 0x20 und 0x50, wobei 0x20 der IO-Expander ist (0b00100000) und 0x50 das EEPROM (0b01010000). Die Adressen stehen freundlicherweise auch im Datenblatt (man muss hier wegen dem R/W-Bit um eines nach rechts shiften). Die Hardware Programmable Pins (das sind die Widerstände links oben) liegen alle auf GND.

Ein kurzes i2cdump später hatten wir endlich die Daten des Chips ausquetschen können:

Sieh einer an, Seriennummer, FRU-Nummer (39R6520) und ein Datum. Na das sollte man doch mit ic2set ändern können… oder auch nicht.

Der Chip lies sich nicht beschreiben 🙁
Doch auch hier half das Datenblatt weiter. Pin 13 ist der Write-Enable Pin. Solange er auch VCC liegt kann man keine Daten schreiben. Erst wenn man ihn auf GND zieht geht das.

Also mal schnell die Multimeter-Probes in den Strommessmodus (da sind sie quasi direkt verbunden) und das goldende Pad rechts oben (fast direkt neben Pin 13) mit einem der Pads links oben bei den Widerständen (diese liegen auf GND) verbunden, und schon lies er sich problemlos beschreiben, und das Herstelldatum von 2011 auf 2016 ändern:

Pin 13 ist dabei nicht auf den Connector rausgeführt – was auch Sinn macht da das Storage-System den Chip ja nur lesen und nicht beschreiben soll. Das große goldene Pad ist wahrscheinlich dafür da, damit in der Fabrik bequem der Schreibschutz beim erstmaligen Beschreiben deaktiviert werden kann.

So, und wenn man jetzt noch für unter 50 € ne neue Batterie reinbaut könnte man das Teil wieder nutzen und hätte 200 € gespart.

Leider wird das Storage bei uns produktiv genutzt und da will ich ungern etwas zusammengehacktes zum Testen einbauen. Lustig wars trotzdem 🙂


Beitrag veröffentlicht

in

,

von

Schlagwörter:

Kommentare

Eine Antwort zu „Reverse Engineering einer IBM DS3400 Storage Batterie“

  1. Fabian

    Sehr, sehr cooler Zeitvertreib.
    Schön verständlich und ausführlich geschrieben und vom Ergebnis bin ich auch begeistert 😀

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert