- Nachdem auf einem Terramaster F2-221 NixOS installiert worden war und eine externe USB-SSD zum Hindernis wurde, wurde ein Backplane eigens gebaut, um intern eine NVMe-Boot-SSD unterzubringen
- Das vorhandene F2-221-Backplane war auf SATA- und Stromversorgungs-Schaltungen ausgelegt; durch die Analyse von Fotos des F5-422 wurde bestätigt, dass Terramaster die Bays mit zwei ASM1061-SATA-Controllern erweitert
- Die PCIe-Differenzialpaare wurden anhand von F5-422-Fotos, dem ASM1061-Datenblatt und den Positionen der Koppelkondensatoren nachverfolgt, einige Pins konnten jedoch bis zuletzt nicht bestätigt werden, und das PCIe2-Pinout wurde ebenfalls nicht verifiziert
- Das Prototyp-PCB verband einen M.2-NVMe-Slot direkt mit einer PCIe-x1-Gen-2-Leitung; im BIOS erschien
Patriot P300 128GB, und auch die Festplatten funktionierten normal
- Das finale F3 Backplane wurde vereinfacht, sodass die 3,3-V-Schiene direkt genutzt wird; nach mehreren Wochen fehlerfreiem Betrieb mit NVMe-Boot und btrfs scrub wurde das KiCad-Projekt auf GitHub veröffentlicht
Ausgangspunkt: die externe USB-SSD loswerden
- Das Terramaster F2-221 ist ein Standard-x86_64-NAS auf Basis des Intel J3355, daher war die Installation von NixOS anstelle des standardmäßigen TOS an sich unkompliziert
- Da beide SATA-Anschlüsse bereits von 4-TB-Festplatten belegt waren, musste als Betriebssystemlaufwerk eine externe USB-SSD angeschlossen werden
- Weil hinter dem Regal um das NAS herum Platz für die externe SSD geschaffen werden musste und beim Umräumen jedes Mal auf das Kabel zu achten war, wurde ein internes Speichermedium notwendig
- Auf dem Mainboard gab es zwar einen internen USB-Anschluss für den TOS-Bootstrap, dieser war jedoch nur USB 2.0 und damit als Boot-SSD ungeeignet
Vergleich der Backplanes von F2-221 und F5-422
- Auf dem Mainboard des F2-221 gab es einen Anschluss in Form eines PCIe-x4-Steckers für das Backplane-PCB, auf dem vorhandenen Backplane befand sich jedoch kein PCIe-zu-SATA-Wandler-IC
- Die SATA-Anschlüsse waren direkt auf den PCIe-Edge-Connector verdrahtet, und die tatsächliche Pinbelegung entsprach nicht dem Standard-PCIe, sondern einem nicht standardisierten Pinout
- Der Intel J3355 bietet zwei SATA-Ports und sechs PCIe-Gen-2-Lanes, daher lag die Vermutung nahe, dass Terramaster bei den 4-Bay- und 5-Bay-Modellen die SATA-Ports über PCIe-Lanes erweitert hat
- Auf hochauflösenden Fotos des Terramaster-F5-422-Reviews wurden zwei ASMedia-ASM1061-ICs identifiziert
- Der ASM1061 ist ein SATA-Controller auf Basis von PCIe Gen 2 x1 und stellt zwei SATA-Ports bereit
- Beim F5-422 war offenbar der erste ASM1061 mit den Ports 3 und 4 des Backplanes verbunden, der zweite mit Port 5
- Auch auf der Rückseite des F2-221-Mainboards ließ sich bestätigen, dass die Pins, die beim F5-422-Backplane wie PCIe-Signale aussahen, tatsächlich verdrahtet waren
Reverse Engineering der PCIe-Signale
- Auf Basis der Fotos des F5-422-Backplanes und des ASM1061-Datenblatts wurden die PCIe-Leitungen verfolgt, doch mehrere Differenzialpaare liefen über Vias in innere Layer, sodass
TX, RX und REFCLK nicht leicht zu unterscheiden waren
- Einer der erkennbaren Hinweise war, dass ein Pin des PCIe-Steckers mit
PERST# des ASM1061 verbunden war
- Zur Unterscheidung der Signalrichtung wurde genutzt, dass bei PCIe traditionell Koppelkondensatoren im
TX-Differenzialpaar sitzen
- Das mit
TX des ASM1061 verbundene Differenzialpaar musste daher die Koppelkondensatoren auf der Backplane-Seite haben
- Aus Sicht von CPU und Mainboard wird dieses Differenzialpaar damit zu
RX
- Beim mit
RX des ASM1061 verbundenen Differenzialpaar wurde die Position der Koppelkondensatoren auf der Mainboard-Seite angenommen
REFCLK wurde als das verbleibende Differenzialpaar vermutet, das jeweils am nächsten zu TX und RX der einzelnen PCIe-x1-Schnittstellen lag- Das Foto des F5-422-Backplanes wurde in KiCad importiert; durch Verfolgen der äußeren Leiterbahnen bis zu den Vias und den Vergleich möglicher innerer Layer-Routings konnte das Pinout von PCIe1 grob bestätigt werden
- Einige Pins waren auf dem vorhandenen F2-221-Backplane nicht verbunden oder liefen in innere Layer, sodass ihr Zweck nicht bestimmt werden konnte
- Das PCIe2-Pinout wurde nicht verifiziert
Rekonstruktion der Stromversorgungsschaltung
- Auf einer Seite des F2-221-Backplanes gab es keine ICs für PCIe-Signale, dafür aber viele Stromversorgungs-Schaltungen mit MOSFETs, Dioden, Widerständen und Kondensatoren
- Anhand von Nahaufnahmen wurden Bauteile und Leiterbahnen geprüft und der Schaltplan in KiCad neu erstellt
- Die Schaltung wurde als Struktur mit Soft-Start-Load-Switches erkannt, jeweils einer pro Versorgungsschiene jedes SATA-Ports
- Beim F2-221 sind das insgesamt 4 Stück: 2 SATA-Ports × 2 Versorgungsschienen
- Beim F5-422 sind es passend zu 5 Bays insgesamt 10 Stück
- Einer der Massepins des SATA-Steckers, P4, wurde beim Anschluss einer Festplatte auf Masse gezogen und diente offenbar wie ein Enable-Pin für den Load Switch
- Diese Struktur sollte wohl das Funken zwischen Stecker und Laufwerk reduzieren, das beim Hot-Plug von Festplatten durch hohe Einschaltströme entstehen kann
- Um nicht viele diskrete Bauteile löten zu müssen, wurde der integrierte Load-Switch-IC onsemi NCP45521-L mit eingebautem Soft-Starter gewählt
Warum NVMe statt SATA-SSD
- Zunächst wurde erwogen, mit einem ASM1061 zusätzliche SATA-Ports bereitzustellen und eine SATA-SSD im Gehäuse zu befestigen
- Für einen M.2-Anschluss war zwischen den Befestigungsschienen des Backplanes Platz vorhanden; der Einbau war möglich, auch wenn auf beiden Seiten weniger als 1 mm Spielraum blieb
- Für eine SATA-M.2-SSD wäre ein Controller nötig gewesen, der PCIe in SATA umwandelt
- Möglich wäre ein Ansatz wie beim F5-422 mit dem ASM1061 gewesen
- Allerdings war der ASM1061 als Einzelbauteil schwer zu beschaffen, sodass der IC von einer PCIe-Karte mit ASM1061 hätte ausgelötet werden müssen
- NVMe ist von Haus aus PCIe-basiert, daher konnten die PCIe-Leitungen ohne zusätzlichen Controller direkt mit einem M-Key-M.2-Slot verbunden werden
- NVMe-SSDs nutzen normalerweise vier Lanes mit PCIe Gen 3 oder höher, in diesem Design wurde jedoch nur eine PCIe-Gen-2-Lane verwendet, sodass keine höhere Geschwindigkeit als bei SATA erwartet wurde
- Trotzdem war NVMe für diesen Zweck besser geeignet, weil kein Controller benötigt wurde, das Routing einfacher war und die Auswahl an NVMe-SSDs größer ist
- Als tatsächliche SSD wurde vor Ort eine
Patriot P300 128GB für 14,90 € gekauft
- Da unklar war, ob das BIOS direkt von NVMe booten würde, wurde im schlimmsten Fall auch ein interner USB-2.0-Stick mit Boot-Partition in Betracht gezogen
Bau und Test des Prototyp-PCBs
- Das neue PCB musste zur Backplane-Halterung des Gehäuses passen, daher mussten die Positionen des PCIe-Edge-Connectors und der Schraublöcher exakt stimmen
- Da auch PCB-Größe und Einschränkungen des Luftstroms berücksichtigt werden mussten, war der Prototyp nicht nur für die elektrische Verifikation wichtig, sondern auch zur Prüfung der mechanischen Passform
- Das vorhandene PCB wurde mit Lineal und Messschieber vermessen, Frontfotos wurden entzerrt und dann in KiCad importiert, um Anschlüsse, Schraublöcher und Außenkontur abzugleichen
- Im Prototyp wurden unbestätigte Pins als Testpunkte herausgeführt; weil die 3,3-V-Schiene erst spät entdeckt wurde, wurde ein Buck-Converter eingebaut, der 5 V auf 3,3 V umsetzt
- Bei JLCPCB wurde ein 4-Layer-PCB bestellt und einige Wochen später geliefert
- Das Löten eines DFN-Gehäuses war Neuland, und die Bauteile waren sehr klein, aber es wurde auf Kurzschlüsse zwischen Versorgung und Masse geprüft und der Lötzustand mit Smartphone-Nahaufnahmen kontrolliert
- Nach dem Einstecken ins NAS und dem Booten erschien
Patriot P300 128GB in der Liste der BIOS-Bootoptionen, sodass direkt von NVMe gebootet werden konnte
- Die befürchtete
CLKREQ-Leitung wurde zwar nicht gefunden, schien aber irgendwo auf dem Mainboard dauerhaft auf Low gezogen zu sein, wodurch REFCLK funktionierte
CLKREQ wird normalerweise verwendet, damit die SSD bei Bedarf den Referenztakt anfordern kann- In diesem Design funktioniert ASPM nicht, aber da es sich um das Boot-Laufwerk eines ständig laufenden Servers handelt, wurde das nicht als großes Problem gesehen
- Auch die Festplatten funktionierten nach dem Anschluss normal
- Da der für Tests und Debugging gebaute Prototyp direkt einwandfrei lief, spielte der Zweck der unbestätigten Pins keine weitere Rolle mehr
Finale Version: F3 Backplane
- Der Prototyp funktionierte zwar, hatte aber noch Testpunkte und saß im Gehäuse leicht schief, daher wurde die finale Version V1.0 noch einmal neu gefertigt
- In der finalen Version wurde der Buck-Converter entfernt und der M.2-Anschluss direkt mit der 3,3-V-Schiene des PCIe-Steckers verbunden
- Die Position wurde leicht angepasst, um die Schieflage des Prototyps zu verringern; außerdem wurden die Testpunkte entfernt und ein Logo hinzugefügt
- Der Name F3 Backplane wurde gewählt, im Sinne von F2 plus eins
- Die erneut bei JLCPCB bestellte finale Platine funktionierte nach Erhalt ebenso einwandfrei wie der Prototyp
- Auf den Festplatten wurde ein vollständiger btrfs scrub ausgeführt, ohne dass Fehler auftraten
- Das System lief mehrere Wochen von der NVMe-SSD, ohne hiccup
- Das Löten der SATA-Anschlüsse war schwierig und wurde unsauber, weil in der inneren Massefläche kein Thermal Relief vorgesehen war; dieses Problem wurde jedoch im GitHub-Repository korrigiert
Leistung und veröffentlichte Unterlagen
- Das
hdparm-Ergebnis der NVMe-SSD lautet wie folgt
/dev/nvme0n1:
Timing cached reads: 4554 MB in 2.00 seconds = 2279.68 MB/sec
Timing buffered disk reads: 1222 MB in 3.00 seconds = 407.22 MB/sec
- Für eine NVMe-SSD ist das keine hohe Geschwindigkeit, was aufgrund der Nutzung von nur einer PCIe-Gen-2-Lane jedoch erwartet wurde
- Als Boot-Laufwerk ist die Leistung ausreichend
- Das KiCad-Projekt wurde auf GitHub veröffentlicht
1 Kommentare
Hacker-News-Kommentare
Als Methode, ein DFN-Package zu löten, ist das fast völlig verrückt, sieht aber unterhaltsam aus.
Es könnte auf seltsame Weise funktionieren, aber gleichbleibende Zuverlässigkeit würde ich nicht erwarten; für ein Einmalprojekt dürfte es reichen.
Zum Glück reichte das Boden-Pad des DFN-Packages bis an beide Kanten, dadurch war es möglich; bei QFN dürfte diese Methode wohl nicht funktionieren.
Ich habe Ähnliches mehrfach mit normalem Lot gemacht: auf jedes Pad etwas großzügig auftragen, aber nicht so viel, dass Kurzschlüsse entstehen.
Flux auftragen – wenn möglich ein kolophoniumbasiertes Flux, das auch beim nächsten Erhitzungsschritt länger durchhält –, dann den gesamten Footprint mit Heißluft erwärmen und den IC vorsichtig aufsetzen.
So muss man den IC nicht lange direkt mit Heißluft anblasen, nur um das Ganze auf Temperatur zu bringen.
Wenn man immer ein paar Vias im Thermal Pad vorsieht und auf der Gegenseite Kupfer freilegt, bleiben die Vias nicht durch Lötstoppmaske verschlossen und saugen überschüssiges Lot auf.
Bei sehr günstigen SMD-Arbeiten kann man das Thermal Pad auch von der Rückseite mit dem Lötkolben erhitzen.
Den Chip anzudrücken ist in Ordnung, aber man muss auf Pads und Ausrichtung achten.
Bei QFN habe ich außer großen Lotperlen an den Außenkanten kaum Lötbrücken gesehen.
Heutige Lotlegierungen und Lötstoppmasken verhindern Brücken ziemlich gut, und Lot haftet eher an Metall, als zwischen Package-Körper und Lötstoppmaske zu bleiben.
Ich würde mir mehr Standardisierung bei Consumer-NAS-Builds wünschen.
Ich habe ASUSTOR jahrelang gefragt, ob sie nicht ein Mini-ITX-kompatibles Backplane oder einen Adapter bauen wollen.
Es wäre schön, wenn man nach ein paar Jahren nur das Backplane austauschen oder ein SBC in einer Form wie Pico-ITX einsetzen könnte.
Ich mag nicht, dass sich ein NAS nach 5 oder 10 Jahren kaum sinnvoll upgraden lässt.
Wenn man nur das Mainboard tauschen könnte, ließen sich viele 1-Gbit/s-NAS auf 2,5 Gbit/s oder 10 Gbit/s bringen, und das Chassis könnte länger genutzt werden, statt auf der Deponie zu landen.
Es ist eine enorme Verschwendung, gleich NAS-Chassis und Backplane zu entsorgen, nur weil der Rechenteil veraltet ist.
Es könnte auch Synergien mit dem Mainboard des Laptop 13 geben, mit Notebook-TDP und vielleicht sogar ARM als Option.
Allerdings wirkt der Markt für NAS-Appliances nicht besonders groß – eher „Prosumer“ und kleine Unternehmen –, und die Differenzierung liegt eher in der Software als in der Hardware.
Leute kaufen Synology nicht wegen der Hardware, sondern wegen DSM.
Ich meine irgendwo gelesen zu haben, dass Framework keine Pläne für vertikale Integration hat; das ist schade.
Ein von Framework unterstütztes OS, bei dem Dinge wie Stromsparen oder das Touchpad-Gefühl direkt gut funktionieren, wäre schön.
So etwas würde ich einfach gern in einen normalen PC stecken, aber die Produkte, die ich gefunden habe, haben entweder nur 4 Ports oder sind viel zu teuer.
Die Antwort hast du dir damit im Grunde schon selbst gegeben.
Die Tiefe und der Aufwand, in die sich Leute freiwillig hineinarbeiten, beeindrucken mich immer wieder
Besonders bei Arbeiten wie Gitarren- oder Hardware-Mods, bei denen man echtes Geld verliert, wenn man etwas vermasselt
Ich glaube, bevor man sich direkt an solche Projekte wagt, sollte man an anderer Stelle Erfahrung mit Lötkolben oder Holzbearbeitungswerkzeug sammeln
Ich frage mich auch, warum der Markt für hackingfreundliche kleine Boxen, bei denen sich Hardware oder Software leichter anfassen lässt, nicht größer ist
Schön wäre ein NAS im Consumer-Preisbereich, bei dem man das Betriebssystem entfernen und durch ein normales OS oder einen Kernel ersetzen kann
Vielleicht habe ich aber auch einfach zu viel Angst davor, echte physische Gegenstände umzubauen
24 TB physische Platten, 16 TB nutzbare Kapazität (Raid Z2), läuft mit Ubuntu LTS Server, und die benötigten Container starte ich per Portainer in Docker
Es ist keine klickbare GUI, die für jeden leicht zu bedienen ist, und Dinge wie SMB-Mounts muss man direkt im Terminal anlegen, aber für den Betrieb ist es leicht genug zu warten
Die Hardware ist ein Asrock Rack C246 WSI Mini-ITX-Mainboard, 32 GB ECC-RAM, Intel i3-9100T, sechs IronWolf-4-TB-NAS-Laufwerke, ein 2U-Rackmount-Gehäuse mit geringer Tiefe und ein 1-TB-Samsung-850-Evo-Bootlaufwerk
Die Leerlaufleistung liegt bei 23 W, also niedrig genug, unter Last steigt sie auf 65 W
Die Platten lasse ich nach 10 Minuten Inaktivität herunterfahren, trotzdem komme ich auf etwa 10.000 Load/Unload-Zyklen pro Jahr; verglichen mit der Spezifikation von 600.000 ist das in Ordnung
Man kann die Laufwerke selbst bestücken und das gewünschte OS installieren
Ich habe ein Gerät mit 183 TB und TrueNAS (ZFS), das läuft großartig
Im Grunde ist es eine standardmäßige x86-Box mit vielen Laufwerksschächten, Backplane, SAS/SATA-Ports und reichlich Controller-Kapazität
Auch der Gebrauchtmarkt ist ziemlich aktiv
Allerdings richtet sich das eher an Leute, die mehr als 10 Laufwerke in einem Gehäuse unterbringen wollen, daher ist „Consumer“ etwas fraglich
Ich denke immer wieder darüber nach, mir ein NAS zu kaufen, möchte aber kein proprietäres Vendor-OS verwenden, das wegen nutzloser oder feindseliger Cloud-Integration möglicherweise meine Daten scannt
Die Möglichkeit, dass irgendwo noch eine Backdoor mit hartcodiertem Passwort steckt, gefällt mir ebenfalls nicht
Über die BIOS-Qualität weiß ich nichts, RAM ist nicht dabei, lässt sich aber auf bis zu 32 GB erweitern, und das OS bringt man selbst mit
Das Intel-Alder-Lake-N100-Modell kostet $189: https://aoostar.com/products/aoostar-r1-2bay-nas-intel-n100-...
Das Ryzen-5700-Modell kostet $299: https://aoostar.com/products/aoostar-r7-2-bay-nas-amd-ryzen-...
Manche nutzen einen Raspberry Pi als NAS; langsam, aber für günstige lokale Backups funktioniert es
Auch ältere integrierte NAS-Geräte wie das DNS-320 kann man rooten und darauf eine relativ aktuelle Debian-Variante mit Sicherheitsupdates laufen lassen
Allerdings sind CPU und RAM sehr schwach, man sollte also mit der Kommandozeile vertraut sein
Eine andere Möglichkeit ist, einen alten HP-Proliant-Server (etwa gen8) zu kaufen, vier 16-TB-Festplatten einzubauen und von einem fünften Laufwerk zu booten
Mich interessiert die Stelle „Dieser USB-Header ist nur USB 2.0 und daher für diesen Zweck keine Option“
Ich will das großartige Projekt nicht infrage stellen, aber ich würde gern wissen, warum USB 2.0 für das OS in einem NAS ungeeignet ist
Passiert da außer Lesen beim Booten und gelegentlichem Schreiben kleiner Datenmengen noch mehr?
Wenn man journalctl-Operationen über Logdateien von 6 Monaten ausführt, dauert das wegen der nicht optimalen Dateizugriffsmuster von journalctl 1 bis 2 Minuten
Natürlich will ich nicht bestreiten, dass der eigentliche Grund für den Bau einfach war, dass das Herumbasteln Spaß gemacht hat
Ich bin wohl ein schlechter Hacker
Ich hatte dasselbe Problem, ein externes Laufwerk an ein NAS anschließen zu müssen, und habe es einfach mit Klettband oben auf dem NAS befestigt
Das sieht viel besser aus als das „Custom“-Gehäuse aus Lego, das ich für mein selbstgebautes NAS gebaut habe
Ich habe vier USB-Festplatten an einen Hub angeschlossen und diesen Hub mit einem Nvidia Jetson verbunden
Ich wollte daraus eine Einheit machen, und Fake-Lego war so billig, dass man leicht experimentieren konnte
Es hat Spaß gemacht, aber das hier sieht viel professioneller aus, da werde ich etwas neidisch
Erstaunlich und elegant
Beeindruckend, dass man mit Vermutungen, etwas Trial-and-Error, Durchgangsprüfung der Schaltung und einer ziemlich einfachen Ersatzlösung für den Load-Switch-IC so weit kommen kann
Am Ende hat es aber funktioniert
Eine wirklich schöne Lösung
Ich nutze das 5-Bay-Modell desselben NAS und habe TrueNAS Scale auf einem Samsung-USB-Stick installiert, der intern eingesteckt ist
Ich habe ein Modell gewählt, das verbreitet für Tesla-Dashcams genutzt wird, also ging ich davon aus, dass es zumindest einigermaßen haltbar ist
Bisher bin ich zufrieden, aber die CPU-Leistung ist weiterhin deutlich zu schwach, daher plane ich ein Upgrade auf etwas Stärkeres
Ich habe auch darüber nachgedacht, das Mainboard gegen einen Custom-Carrier für ein ARM-Compute-Modul oder gegen das neue Lattepanda mu auszutauschen, aber erst einmal sollte ich wohl dieses neue Projekt nutzen, in das ich so viel Arbeit gesteckt habe
Gut gemacht, und ich mag solche Projekte, bei denen Menschen ihre eigene Hardware selbst kontrollieren.
Dass es öffentlich dokumentiert wurde, verdient noch einmal extra Lob.
Allerdings frage ich mich, ob es Probleme mit dem Luftstrom geben wird.
In der Mitte der ursprünglichen PCB und der modifizierten PCB befindet sich ein großes Loch, vermutlich dafür gedacht, Luft über die Laufwerke strömen zu lassen.
Das NVMe-Laufwerk verdeckt es jedoch.
Wahrscheinlich entweicht genug Luft um die Ränder der NVMe herum, sodass die normalen Laufwerke ausreichend gekühlt werden, und als Bonus bekommt man vielleicht die bestgekühlte NVMe der Welt.
Trotzdem wirkt der Platz sehr knapp.
Ich kenne mich mit Aerodynamik nicht besonders gut aus, daher kann ich es nicht mit Sicherheit sagen, aber ich denke, dass durch das Loch noch ein gewisser Luftstrom hindurchgeht.
Die Schraub-Standoffs für die SSD bis ganz an den linken Rand der PCB zu setzen, war ebenfalls dazu gedacht, rechts mehr Luft durchzulassen.
Zumindest habe ich bisher nicht bemerkt, dass die Kühlleistung schlechter geworden wäre.
Ich werde es zwar nicht direkt verwenden, bin aber trotzdem begeistert.
Es ist wirklich schön und inspirierend zu sehen, wie jemand so tief einsteigt, dazulernt und das Gelernte teilt.