Update von 20N/28A erst auf 3EA, dann 3MA – Mehr Info im verlinkten Thread.

Zusammenfassung:

Hitachi 2TB 7K2000 (HDS722020ALA330), Model 0F10311

Current firmware: 3MA
Previous firmare: 3EA, 28A, 20N (newest to oldest)

Description:

This firmware applies to Hitachi HDS722020ALA330 2TB 7K2000 harddisks, model 0F10311. For other makes and models of drives you’ll need to contact Hitachi support. The following information is being provided since its very difficult to get these files from Hitachi support, as they understandably don’t want to create unnecessary RMA’s by the software being misused (applied to a wrong drive or with improper procedure).

Instructions:

The Hitachi firmware update utility JKDL_SP.EXE must be run in DOS mode, so place it on something like a Win98 bootdisk. Connect your disks to your motherboard SATA port(s), and make sure your SATA mode is set to “IDE/LEGACY” rather than AHCI. Repeat an AHCI mode SATA port will not work correctly in DOS mode. You will NOT lose any data on the harddisk, the update does not touch the disk surfaces – I’ve flashed over
60 of these drives without issue. Lastly, the type of firmware file is “BDX” which you can answer when prompted. Follow the prompts and reboot.

NOTE:

A drive with firmware version 20N or 28A must FIRST be upgraded to 3EA before it can be upgraded to 3MA. To verify your firmware version, run the JKDL_SP.EXE tool without any parameters. If flashing 28A and 20N drives to 3EA, you do not need to reboot to then apply the 3MA update. You can do them one after the next in the same session.

Momentan mit DD-WRT svn16785, die svn16994 hat die Kiste gleich gebrickt, die Recovery-Software (auch auf der Netgear-CD enthalten) läuft jedoch 1A… Wiki-Eintrag bei DD-WRT, Wiki-Eintrag bei OpenWRT, mit Antennen-Mod und Innereien.

cpuinfo:

system type             : Atheros AR7161 rev 2 (0xaa)
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 452.19
CPUClock                : 680
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ff8, 0x0ffc, 0x0ffb, 0x0ffb]
ASEs implemented        : mips16
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

/proc/meminfo nach ca. 30 Minuten Laufzeit:

        total:    used:    free:  shared: buffers:  cached:
Mem:  63336448 29548544 33787904        0  2785280  8392704
Swap:        0        0        0
MemTotal:          61852 kB
MemFree:           32996 kB
MemShared:             0 kB
Buffers:            2720 kB
Cached:             8196 kB
SwapCached:            0 kB
Active:             7456 kB
Inactive:           6024 kB
Active(anon):       2564 kB
Inactive(anon):        0 kB
Active(file):       4892 kB
Inactive(file):     6024 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          2572 kB
Mapped:             2116 kB
Shmem:                 0 kB
Slab:              12548 kB
SReclaimable:        688 kB
SUnreclaim:        11860 kB
KernelStack:         288 kB
PageTables:          252 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       30924 kB
Committed_AS:       6688 kB
VmallocTotal:    1048372 kB
VmallocUsed:         200 kB
VmallocChunk:    1009808 kB

uname -a:

Linux rooter 2.6.34.8-svn16695 #4821 Wed Apr 13 13:10:02 CEST 2011 mips unknown

Ein schneller Fix ist, neben den “Fixed DHCP Hosts” auf der Seite DHCP Server

alle Hosts noch einmal in den DNS Forwarder als “overrides” einzutragen:

Nicht schön, aber effektiv. Wenn ein Gerät 2 Netzwerk-Schnittstellen wie z.b. LAN und WLAN hat, auch nicht wirklich ein Ersatz für ein ordentliches “Auflösen” der bekannten Hosts per DNS, aber es funktioniert soweit:

WorksForMe™

Die “DDNS” – Einstellungen auf “Custom” seatzen, und folgendes auswählen:

DDNS Service: Custom
DYNDNS Server: members.dyndns.org
User name: Der DynDNS-Benutzername
Password: Das DynDNS-Passwort
Hostname: DynDNS-Hostname
URL: /nic/update?
Additional DDNS Options: --dyndns_system dyndns@dyndns.org --ip_server_name checkip.dyndns.org:8245 /

Bei statischem DNS nicht dyndns@dyndns.org sondern statdns@dyndns.org verwenden.

Die gebrauchte SSD hatte laut SMART zwar nur ~5 Betriebsstunden, aber leider noch die alte Firmware VBM18C1Q. Einige andere OCZ (Summit) und Samsung-SSDs verwenden anscheinend den selben Controller und die selbe Firmware.

Nach dem Flashen mit der aktuellen (aber auch alten) Firmware VBM19C1Q unterstützt die SSD TRIM und macht angeblich nach einiger Zeit im idle -Zustand auch selbständig Garbage Collection.

Eine Floppy mit dem Flasher und der neueren VBM19C1Q-Firmware ist schnell erstellt und gebootet – hier (updater_vbm19c1q.img.zip) zum Download, mit RawWrite oder dd auf Floppy schreiben.

Hier nochmal: Alle Daten auf der SSD gehen beim Update der Firmware verloren!

Nach dem Booten und 2 Sicherheits-Abfragen wird die Firmware unspektakulär innerhalb 10-15 Sekunden geflasht:

Fertig:

Die Daten (Per USB-Adapter angeschlossen, daher einiges nicht korrekt):

Das Flashen selbst geht wohl nur an einem SATA-Controller – Weder RAID-Controller noch USB-zu-SATA-Gehäuse bzw. -Adapter werden unterstützt. im Zweifelsfall also für das FW-Update die Platte des Notebooks/PCs abziehen und die Samsung SSD anstecken.

Eine frische 160GB Samsung-Platte (eine 1TB Seagate wird vom Buffalo-Board nicht erkannt, 6x rot Blinken der Fehler-LED) und die Anleitung geschappt und in 15 Minuten (incl. Download) ist die Kiste am Laufen: Debian-Installations-How-To verifiziert.

Da mein Pad (mit deaktivierter wow-Software) funktioniert, und ich keinen Bock habe, jede Woche aufs Neue zu basteln, werde ich mich nicht weiter darum kümmern. Eventuell steht mein Pad demnächst auch zum Verkauf, Interessenten vor!

Details Deutsch/english…

Durch diese Policy ist eine eventuell damit verteilte Firmen-Software nicht löschbar.

Möglichkeit 1 – Zuweisen einer leeren Policy

Dem Blackberry vor dem Nuken vom Enterprise Server aus eine neue (leere) IT-Richtlinie ohne Einstellungen zuweisen.

Darauf achten dass weder der User noch das Gerät andere Richtlinien zugewiesen haben. Warten bis zur Übernahme, dann den Blackberry erst bzw. erneut löschen/wipen.

Möglichkeit 2 – loader.exe aus der Blackberry Desktop Software

Auf einem PC Blackberry Desktop installieren, dann existiert auf dem PC unter C:\Programme\Gemeinsame Dateien\Research In Motion\AppLoader\ die Datei loader.exe, mit der Firmware-Updates und andere Tasks durchgeführt werden können.

Mit loader.exe /resettofactory kann das Gerät komplett zurückgesetzt werden. Alle IT-Richtlinien und Anwendungen, die von einer IT-Richtlinie referenziert wurden, und sich vorher nicht löschen liessen, können im Anschluss gelöscht werden. Unter MacOS wär’s ./bbdm resettofactory.

loader.exe-Referenz:

loader.exe /
 is one of
eventlog [
]
screenshot [active|primary|auxiliary] [
]
dir [
]
deviceinfo [
]
radio [on|off]
resettofactory
dump [
]

Siehe RIM KB-Artikel KB17215

Edit am 24.01.2011:

Das Konsolen-Kommando bringt aber auch beim drölfzigsten Mal Ausführen nichts, wenn der Blackberry auf dem Schreibtisch am Netzladegerät statt am USB des PCs hängt. Glückwunsch, Stefan…

Es könnte sein, dass die Datei recovery-rd.img in recovery_rd.img umbenannt werden muss. Könnte. Vielleicht. Eventuell. Möglicherweise.

Das Update sollte zuerst jemand probieren, dessen Pad sowieso hängt/gebrickt ist.