[Guide] Gigabyte MZ32-AR0 rev 1.0 auf 3.0 flashen

sch4kal

Enthusiast
Thread Starter
Mitglied seit
18.07.2016
Beiträge
4.349
Moin,

falls sich jemand ein AMD Epyc Milan Homeserver Build zusammenstellen will, und vielleicht auch ein Auge auf das Gigabyte MZ32-AR0 geworfen hat:
- 2DPC Bestückung
- Mezzanine Port für günstige NIC-Erweiterungen (passende SFP+ NICs werden gerade samt Adapter auf PCIe auf Ebay und Co. verscherbelt)
- Ausreichend PCIe-Ports für fast alle Vorhaben oder Speichermonster
1669903852303.png

...wird sich bestimmt gewundert haben, das es auf der Gigabyte Website zwei PCB-Revisionen davon gibt. Revision 1.0 (und 2.0) unterstützen nur Naples und Rome, Revision 3.0 dagegen nur Rome und Milan.
Zumindest laut Website...
Wer sich jetzt denkt "Ja dann kauf ich mir eben einfach ein rev 3.0 Board" wird sich umschauen und schnell feststellen, das es das für Normalos in den üblichen Shops gar nicht zu kaufen gibt. Ich hatte vor 2 Monaten bei sämtlichen B2C Händlern nach Rev 3.0 angefragt und immer Absagen bekommen. Man bekommt nur rev 1.0. Also hab ich bei einem B2B Händler angefragt und explizit ein rev 3.0 Board bestellt. Gekommen ist jetzt jedoch ein rev 1.0 Board..."Na toll" dachte ich mir, also meinen Salesrep bei dem Laden angefragt, der wiederum hat bei seinem Vertriebskontakt von Gigabyte nachgefragt und eine Antwort aus der Technik bekommen:
1669904151524.png

Jackpot !
Das Howto von Gigabyte hab ich angehängt. Dazu war ein Link zu deren geschützten FTP Server mit Zugangsdaten. Diese werde ich hier jetzt nicht bereitstellen. Ich bin aber bereit, jedem Interessenten die Dateien zukommen zu lassen. (und nein, diese Dateien werden nicht auf der Gigabyte-Website angeboten).

Frohes Hochrevidieren !
 

Anhänge

  • How to update GBT server FW.pdf
    2,1 MB · Aufrufe: 418
  • 1669904375891.png
    1669904375891.png
    11,9 KB · Aufrufe: 258
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aber ist das Board denn dann presflashed, wenn es einigermaßen aktuell ist?
Oder kommt es als immer Rev 1.0 HW und FW stand und man muss dann 3.0 FW selber nachflashen?
 
Aber ist das Board denn dann presflashed, wenn es einigermaßen aktuell ist?
Oder kommt es als immer Rev 1.0 HW und FW stand und man muss dann 3.0 FW selber nachflashen?
Das kann ich dir noch nicht sagen, hab es noch nicht in Betrieb genommen.
Mein Supplier hat es aber direkt bei Gigabyte bestellen müssen, da keine Lagerware gewesen.
Ich guck mal ob ich irgendwo ein Manufacturing Date finde.
 
Also das Board kam bei mir mit Uralt-Versionen von 2021.
BMC ist jetzt auf Version 12.60.39 und BIOS ist das M13c drauf.
Die Versionen die mir der Support geschickt hat wollte das Board nicht flashen, die "Milan.RBU" war die richtige Datei, nicht die "image.RBU" aus dem Guide oben:
1673456778761.png


...ich sehe das Board gibt es teils unter 300 € gebraucht in der Bucht, also, zuschlagen, ich liefere die Dateien fürs Flashen auf Milan :bigok:
Beitrag automatisch zusammengeführt:

Ich guck mal ob ich irgendwo ein Manufacturing Date finde.
Konnte ich übrigens nirgends finden.
Beitrag automatisch zusammengeführt:

Ach sieh an, Gigabyte bietet jetzt sogar ein MZ32-AR1 exklusiv für Milan CPUs an:

...sieht allerdings genau gleich aus wie das MZ32-AR0, und bietet scheinbar auch die gleichen Features. Ich teste es mal die Tage, ob meine M.2 Slots auch mit PCIe 4.0 SSDs laufen.
 
Das Mainboard erkennt auch sauber alle Hardware:
Bifurcation auf x4x4x4x4 läuft wunderbar. Lässt sich auch auf allen PCIe Slots einstellen (außer dem Mezzanine Port, aber da steckt sowieso die CX4-lx drin.
1673461170054.png

1673461261375.png
 
Hello,
Sorry for necrobumping the post, and for speaking english, I really cannot speak Deutsch.
Coud someone provide the file(s) to upgrade for rev 1.0 to rev 3.0, or point me to the right direction to get them ?
Vielen Dank !
 
Hello,
Sorry for necrobumping the post, and for speaking english, I really cannot speak Deutsch.
Coud someone provide the file(s) to upgrade for rev 1.0 to rev 3.0, or point me to the right direction to get them ?
Vielen Dank !
Hi, send me a PM and i give you the links for the files.
 
Hello! Thank you for sharing this valuable information.

A colleague ordered the MR32-AR0 Rev 1.0 and a CPU from Epyc 7003 Series. So the system does not respond in any way.

Only the BMC Interface is working. What we did so far:
- Update the BMC Firmware to 12.60.39
- We got the Milan BIOS from this page: https://forums.servethehome.com/index.php?threads/mz32-ar0-rev-1-3.40433/
- Flash the Milan BIOS (Milan.RBU)

But still the BMC says that the BIOS Firmware is the same as before.
Also the machine does not show any form of output.


Screenshot 2023-07-13 173311.png


Did we miss any important step?

Thank you very much for your help.
 
Hi,

did you try flashing the BIOS without anything attached to the board ? I flashed my rev 1.0 board only with the atx power cable connected and the BMC LAN up (ie. no CPU installed, no NVMe, no RAM,…).
Rollo is also active here, dont know which Milan.RBU he gave to you, i can provide you the one i flashed mine with (Version M13c), if you want to try with that. Maybe i give the latest version from the Gigabyte Homepage a shot and see if it still works.
 
Hi!

Thank you for the hint. I removed everything from the Mainboard now so that there is just Power and LAN attached (No CPU, No RAM, No Disk, ...).
We retried the flashing procedure, but there was no different outcome.

The version from Rollo I downloaded is also M13c_R30b. But I would be very happy if you could send me your version maybe there is some difference. I would have written you a PM, but my account is too new to do so. I could also try to flash the official version from Gigabyte M16_R32, but I was not sure as this is already for the Rev 3 Board.

I assume, I could have the same Bug as this user describes with the newest BMC Firmware:

Upon BIOS flashing everything was "OK" = I could still access the server, see the screen and access the USB devices (keyboard) connected to the server.

Unfortunately for me after applying their firmware v.12.60.39, I could not access the vga or the USB of my board !

Needless to say that I am quite stuck. I am actually trying to find a firmware like 12.40… in order to try to roll back to the previous (hopefully working) state.

Below there is a comment about Clearing CMOS. I have seen there is a Jumper for that, but what is the correct procedure?
Flash -> Remove PowerSupply -> Set Jumpter to Clear CMOS -> Connect Power -> Remove Jumper -> Power On

We installed now also a small graphics card to see if there is any output. But also nothing.

My colleague contacted Gigabyte now. Maybe we try to buy a Epyc from the 7002 Series.
 
This is the answer we got from GigaByte. Does not sound so promising :(

Question: Dear Gigabyte support, I'm trying to use a MZ32-AR0 (rev. 1.0) with a Ryzen 7543p. Is it possible to update the motherboard from the rev 1.0 to the rev 3.0? Many thanks and best regards!

Answer: There are hardware (component differences) between rev 1.0 and rev 3.0. It cannot be changed by using the software/firmware update. If any furtyher help is needed, please provide us also the product serial number to check the detailed product spec accordingly. Feel free to contact us again anytime if you have any feedback or need any support from us. Cases without updates in 7 days will be closed until further information is received. Regards, GIGABYTE

Let's see what they tell us when, we send them the serial number. Perhaps there are some boards which can be upgraded and some which can not.
 
...sieht allerdings genau gleich aus wie das MZ32-AR0, und bietet scheinbar auch die gleichen Features. Ich teste es mal die Tage, ob meine M.2 Slots auch mit PCIe 4.0 SSDs laufen.

Gibt es ein Update bitte? Mein Romed6u hat sich verabschiedet (Überspannungsschaden vermutlich...) und ich habe mir das MZ32 bestellt. Geht PCIe4.0 mit den xxx2/xxx3 CPUs?
 
Auf den M.2 Slots kann ich es dir nicht sagen, die PCIe Slots funktionieren aufjedenfall mit PCIe 4.0. Nur den oberen Slot hab ich gar nicht zum Laufen überreden können.

Ich könnte es nächste Woche für dich testen, dann hänge ich melne Optane um und steck die PM9A3 dran via Adapterkabel.
 
Gibt es ein Update bitte? Mein Romed6u hat sich verabschiedet (Überspannungsschaden vermutlich...) und ich habe mir das MZ32 bestellt. Geht PCIe4.0 mit den xxx2/xxx3 CPUs?
1691656004301.png

Augenscheinlich läuft meine eine M.2 NVMe (Samsung PM9A1, 256 GB) auf PCIe Gen 4.0
Beitrag automatisch zusammengeführt:

This is the answer we got from GigaByte. Does not sound so promising :(



Let's see what they tell us when, we send them the serial number. Perhaps there are some boards which can be upgraded and some which can not.
Hi there, im answering your questions next week, but they gave you definitely the wrong answer, i run a Epyc 7443 Milan cpu in a rev 1.0 board.
 
Zuletzt bearbeitet:
Gestaltete sich überraschend schwierig, meinen 7302 darauf zum Laufen zu bekommen. Auch bei mir war der Firmware+BIOS-Stand uralt. F30 gibts nur über sth, die Homepage bietet F28. Ich brauchte ja gar nicht die Milan-Unterstützung, aber nur mit der rome-Firmware aus dem F30-Paket lief der Rechner.. wie auch immer.
 
Kannst du dann bitte mal schauen ob bei dir der PCIe Slot 7 (ganz oben) funktioniert ? Ich hab mir jetzt mal beim Chinesen ein SlimSAS 4i auf U.2 Kabel gekauft, um zu schauen ob die Ports wenigstens funktionieren.
 
Wie sind denn allgemein die Erfahrungen mit dem Board? Ich hab aktuell knapp 7 Systeme mit dem Supermicro H12 aber das bietet leider einfach zu wenig RAM slots.
 
Wie sind denn allgemein die Erfahrungen mit dem Board? Ich hab aktuell knapp 7 Systeme mit dem Supermicro H12 aber das bietet leider einfach zu wenig RAM slots.
Ich bin bislang sehr zufrieden, außer das bei mir der oberste PCIe Slot stromlos ist.
Bifurcation funktioniert überall, jede Hardware wird anstandslos erkannt und im BMC auch angezeigt, und man hat viele RAM Slots frei. Noch dazu unterstützt afaik nur Gigabyte aktuell DDR4-3200 mit 2DPC. Normalerweise gehts da runter auf DDR4-2933.
 
Kannst du dann bitte mal schauen ob bei dir der PCIe Slot 7 (ganz oben) funktioniert ? Ich hab mir jetzt mal beim Chinesen ein SlimSAS 4i auf U.2 Kabel gekauft, um zu schauen ob die Ports wenigstens funktionieren.
Hier kann ich möglicherweise Helfen. Der Slot7 hat keine PCIe lanes, die ihn mit der CPU verbinden. Er hat allerdings eine elektrische Verbindung zu den Slimline 4i headern die direkt über ihm verbaut sind. Um den Slot7 zu nutzen, musst du quasi lanes von deinen Slimline U.2 headern nutzen, die ganz unten rechts auf dem Board sind. Gigabyte bietet dazu einen Satz Slimline Kabel an, mit denen du dann quasi einzelne dieser Slimline Header mit den oberen von Slot7 verbinden kannst und darüber PCIe Lanes im 4er-Pack jeweils an den Slot7 weiter reichen. Du tauschst quasi U.2 gegen einen weiteren Slot. Je mehr U.2 du verbindest, desto mehr Lanes kannst du in Slot7 nutzen.

Falls du daran Interesse hast, kann ich dir die Teilenummer der Kabel heraussuchen, ich denke aber, dass jedes hochwertige Slimline SAS-Kabel funktionieren wird.
Beitrag automatisch zusammengeführt:

Ich bin bislang sehr zufrieden, außer das bei mir der oberste PCIe Slot stromlos ist.
Bifurcation funktioniert überall, jede Hardware wird anstandslos erkannt und im BMC auch angezeigt, und man hat viele RAM Slots frei. Noch dazu unterstützt afaik nur Gigabyte aktuell DDR4-3200 mit 2DPC. Normalerweise gehts da runter auf DDR4-2933.
Siehe meine Antwort zur Funktion von Slot7 im Post hier drüber ^
 
Jup. Hatte ich bislang nicht gelesen: Das Handbuch. Relevante Seite s. anbei.
Dämliche Ingenieurs-Lösung. Sinnvoller wäre gewesen, die Lanes an den Slot zu binden und eine x16->4xSlimline-Karte beizulegen. Aber wird schon einen finanziellen Grund gehabt haben... was ist teurer? 4xSlimline-Kabel oder so eine Karte? Fragen, die die Welt nicht braucht.
 

Anhänge

  • server_manual_MZ32-AR0_e_v10.pdf
    127,1 KB · Aufrufe: 90
Hier kann ich möglicherweise Helfen. Der Slot7 hat keine PCIe lanes, die ihn mit der CPU verbinden. Er hat allerdings eine elektrische Verbindung zu den Slimline 4i headern die direkt über ihm verbaut sind. Um den Slot7 zu nutzen, musst du quasi lanes von deinen Slimline U.2 headern nutzen, die ganz unten rechts auf dem Board sind. Gigabyte bietet dazu einen Satz Slimline Kabel an, mit denen du dann quasi einzelne dieser Slimline Header mit den oberen von Slot7 verbinden kannst und darüber PCIe Lanes im 4er-Pack jeweils an den Slot7 weiter reichen. Du tauschst quasi U.2 gegen einen weiteren Slot. Je mehr U.2 du verbindest, desto mehr Lanes kannst du in Slot7 nutzen.

Falls du daran Interesse hast, kann ich dir die Teilenummer der Kabel heraussuchen, ich denke aber, dass jedes hochwertige Slimline SAS-Kabel funktionieren wird.
Beitrag automatisch zusammengeführt:


Siehe meine Antwort zur Funktion von Slot7 im Post hier drüber ^
Bei genauerer Betrachtung des Blockschaltbildes auch logisch, bist du dir ganz sicher das es dazu Kabel braucht ? Das Board wird ja in 2 Servertypen von Gigabyte eingesetzt, da hab ich solche Kabel nie gesehen, die gehen alle nach vorne an die NVMe/SAS Backplane.

Das wäre ja dann ziemlich umständlich, das so zu lösen. Da würde ich die Ports rechts unten ja lieber direkt an eine Backplane oder U.2 SSDs anstecken.
 
Jup. Hatte ich bislang nicht gelesen: Das Handbuch. Relevante Seite s. anbei.
Dämliche Ingenieurs-Lösung. Sinnvoller wäre gewesen, die Lanes an den Slot zu binden und eine x16->4xSlimline-Karte beizulegen. Aber wird schon einen finanziellen Grund gehabt haben... was ist teurer? 4xSlimline-Kabel oder so eine Karte? Fragen, die die Welt nicht braucht.
Die Karte ist teurer, warum? Redriver! Da ist man sehr entspannt dreistellig, kann man sich gleich nen 2. MB für kaufen.

Wir sind bei PCIe in Bereichen angekommen, wo die Längen bzw. die Signalintegrität ein Problem sind.
Wenn man aber die Lanes direkt rauszieht, hat man ab da quasi die selbe Länge zum Slot oder zum PCIe-Device.
Würde man die Lanes erst zum Slot ziehen und da dann wieder raus um zum PCIe Device zu gehen sind mittlerweile Signalverstärker notwendig. Sprich das ist eine aktive Karte mit Technik drauf und das ist, im Moment, noch nicht ganz so günstig.

Das Spiel geht soweit, dass Dell beim R750 die Risercards hinten mit PCIe Kabel anfährt.
Oder auch HP muss, für ein 24 SFF U.2/3 System, Lanes von den Riser nach vorne schieben und braucht dafür zwingend redriver Karten,.

Also immer Vorsicht mit Aussagen "Dämliche Ingenieurs-Lösung". Das zeugt eher davon, dass man das Adjektiv sich redlich selber verdient hat...
Beitrag automatisch zusammengeführt:

Bei genauerer Betrachtung des Blockschaltbildes auch logisch, bist du dir ganz sicher das es dazu Kabel braucht ? Das Board wird ja in 2 Servertypen von Gigabyte eingesetzt, da hab ich solche Kabel nie gesehen, die gehen alle nach vorne an die NVMe/SAS Backplane.

Das wäre ja dann ziemlich umständlich, das so zu lösen. Da würde ich die Ports rechts unten ja lieber direkt an eine Backplane oder U.2 SSDs anstecken.
Welcher dieser Systeme, die du gesehn hast, hatten parallel zur SSD Anbindung noch den Slot 7 belegt?
Das ist die Lösung von GB um zum einen full PCIe Slots anzubieten aber eben auch den Direktanschluss von SSDs, wobei letzterer eben nur bedingt durch eine Adapterkarte zu realisieren ist.
Die andere Option wäre es gewesen, sich für das eine oder das andere zu entscheiden, bzw. eine 2. CPU zu spendieren, die dann nochmal PCIe Lanes mitbringt.

Kurzum, sicherlich unkonventionell, aber eben für die Marktausrichtung scheinbar notwendig.
 
Zuletzt bearbeitet:
4xSlimline SAS Kabel = >25€/St. Amazon, PCIEx16->4x Slimline SAS ist eine passive Bifurcation-Karte für 132€ bei Reichelt, kurze Suche ohne Vergleiche.
Insofern geht beides vermutlich billiger oder teurer und wirkt damit preislich eher gleichwertig.

Dass irgendwelche Verstärker von PCIE auf Slimline-Slots notwendig sind aber andersherum bei gleicher Strecke nicht (betroffenes Mainboard), erschließt sich meinem ingenieursfremden Geist nicht. Die genannte PCIe-Kartenlösung hat de facto auch kürzere Signalwege, da nicht vier SlimSAS Ports miteinander noch mit Kabel verbunden werden, um dann zu einem Slot geführt zu werden, sondern sich direkt auf der Karte anschließen lassen.
 
Dass irgendwelche Verstärker von PCIE auf Slimline-Slots notwendig sind aber andersherum bei gleicher Strecke nicht (betroffenes Mainboard), erschließt sich meinem ingenieursfremden Geist nicht.
Wo haben wir denn gleiche Strecken?
Dann fangen wir mal an, das Problem systematisch zu durchdenken.

Lösung 1 Slot direkt auf CPU:
1. Leiterbahnen von CPU zum Slot (keine Ideale Lösung, da Signalintegrität auf Mainboards ein echtes Problem ist, grundsätzliches Thema)
2. PCIe Slot inkl. durchkontaktierte Anbindung auf dem MB
3. M.2/SlimSAS Steckkarte in PCIe Slot, Kontakte haben schlechte Signalübertragung
4. SlimSAS (oder what ever) Stecker, Kontaktübergang am Stecker im Port
5. 50cm-100cm SlimSAS (oder what ever) Kabel, reizen allein schon die Signalreserven gut aus
6. Stecker vom SlimSAS (oder what ever) zur SSD


Lösung 2: Slot über SlimSAS Ports
1. Leiterbahnen von CPU zum Slot (keine Ideale Lösung, da Signalintegrität auf Mainboards ein echtes Problem ist, grundsätzliches Thema)
2. SlimSAS (oder what ever) Stecker,, wieder Kontaktübergang am Stecker in Port
3. 50cm-100cm SlimSAS (oder what ever) Kabel, reizen allein schon die Signalreserven gut aus
4. Stecker vom SlimSAS (oder what ever) zur SSD

Was ist der Unterschied?
2. PCIe Slot inkl. durchkontaktierte Anbindung auf dem MB
3. M.2/SlimSAS Steckkarte in PCIe Slot, Kontakte haben schlechte Signalübertragung
Was ist noch der Unterschied?
Der Weg von der SSD zum Anschluss auf der PCIe-Karte verlängert sich um die Strecke PCIe Slot zur den SlimSAS Port auf der anderen Seite des MBs.
Und diese Mehrlänge bzw. Kontaktschwierigkeiten machen an genau der Stelle den Redriver notwendig.

Und all das sorgt dafür, dass die Signalintegrität zwischen beiden Lösungen stark unterschiedlich ist. Und die Punkte 2+3 aus der Lösung 1 sind, besonders durch die Kontaktierungen, ein zusätzliches Problem, die deutlich an der Signalqualität und damit Leitungslänge knabbern.
Hinzukommt, dass in der Lösung die Leitungen vom SlimSAS zum PCIe-Slot nicht nur in ihrer Länge klar definiert sind, sondern viel mehr auch noch relativ kurz. Dementsprechend ist also folgendes gegeben:
1. Leiterbahnen von CPU zum Slot (keine Ideale Lösung, da Signalintegrität auf Mainboards ein echtes Problem ist, grundsätzliches Thema)
2. SlimSAS (oder what ever) Stecker, wieder Kontaktübergang am Stecker in Port
3. 30cm SlimSAS zum PCIe Slot
4. SlimSAS (oder what ever) Kontaktübergang am Stecker im Port
5. PCIe Slot inkl. durchkontaktierte Anbindung auf dem MB

Der Unterschied bei der Rückführung ist also:
1. kurzes Kabel
2. ein Kontaktübergang weniger

Das heißt also, dass die Verbindung direkt zur SSD etwas besser von den Signalen her ist, als die Verbindung zum PCIe Slot.
Beide Verbindungen sind aber um Welten besser als die Lanes übers MB zu führen, um sie dann wieder auszuleiten und sie erst dann zur SSD zu führen.
Man macht den Aufriss also primär für die Direktanbindung der SSDs und hält sich dennoch die Möglichkeit offen die SSD Ports für einen weiteren PCIe Slot zu opfern. So kann man das also wahlweise bauen. Die andere Option wäre gewesen, den PCIe Slot einfach wegzulassen.

Und für diese Feststellung muss man weder Ingenieur sein, nen Doktor oder sonst was haben.
Es reicht ein Zettel und Stift wo man sich die Topologie inkl. Längen und Kontakten/Steckern aufmalen kann.
Daraus kann man ableiten, wo die Unterschiede in den Lösungen liegen.
Das Ingenieurswissen kommt erst dann zum Tragen, wenn man die Integrität wirklich bewerten will. Das muss man aber nicht. Es reicht aus, wenn man erkennt, dass dort einfach ein paar mehr Problemstellen sind, die einen erkennen lassen, dass man da wohl reagieren muss. Und die Reaktion sehen wir.
Und dann aus der eigenen Unfähigkeit heraus eine Lösung als dämlich zu betiteln, ist nicht unbedingt das, was man in der Position machen sollte. Ja, sie ist unkonventionell, kommt aber eben dem 7. PCIe Slot zur Gute, man hat also also Kunde also die Wahl. Ohne diese Lösung hätte man sie nicht. Jetzt gibt es natürlich über die sagen, mir reicht das eine oder das andere. Dafür hätte es aber zwei Boards gebaucht, so hat man eben eine Lösung für beides.

PS: Signale in Kabel führen ist für die Signalintegrität deutlich besser, als über das MB mit Leiterbahnen.
PPS: Diese Redriver werden wir noch öfter sehen. Sie sind sogar heute schon auf so einigen Consumerboards verbaut, weil die nämlich auch vor dem Problem stehen. Die Zeiten von "einfach mal ein paar PCI(e) hinklatschen" sind vorbei.
PPPS: Es gab doch hier einen User, der hat nen riesen Aufriss mit NVMe PCIe 4.0 SSDs gemacht, damit er sie aus den PCIe Slots rausziehen kann. Am Ende ist er glaube gescheitert. Und die gleichen Probleme hat auch Gigabyte und ihre Lösung sehen wir hier.
 
Zuletzt bearbeitet:
-seufz- ok. Dann mal meine kurze SIcht auf die meiner Meinung nach fehlerhafte Darstellung Deiner Lösung 1 + 2:

Du argumentierst - wie immer - fachlich über dem Niveau der meisten Leser hier, mich eingeschlossen. Jedoch m.E. unter unvollständiger Betrachtung der Sachlage, weil Du das Board-Layout nicht richtig darstellst.

Gigabyte hat umgesetzt:
(1: Nutzung SlimSAS)
- SoC -> 4x Slim-SAS an das unterste Ende des Mainboards, also Leiterbahn auf Platine >30cm auf ähnliche Entfernung wie der unterste Slot (1).
- Dort 4x Kontakt SlimSAS mit Kabel zu den Endgeräten.
Für die Verbindung von NVMe-Laufwerken/U2 also eine maximal lange Verbindung auf dem Mainboard, aber vergleichsweise "direkt" von der CPU zur SlimSAS-Buchse.

Sollte man PCIe nutzen wollen, kommt jetzt hinzu:
(2: Stattdessen Nutzung PCIex16)
- Kontakt SlimSAS
- 25cm Kabel.
- Kontakt SlimSAS
- Leiterbahn onboard 5cm
- Slot

Meiner Sicht nach besser:
- 10 (?)cm Leiterbahn vom SoC -> Slot 7
- Slot

Für Nutzung (1) gegenüber Gigabyte
+ >=20cm weniger Leiterbahn auf der Platine
- Kontakt Slot zu Erweiterungskarte
- dann noch 2-4cm Leiterbahn auf der Erweiterungskarte
Klingt für mich nach einer Nullrechnung. Aber natürlich ohne elektrisches Fachwissen. Kann man bestimmt durchrechnen, sehe ich als unnötig an: Die Nutzung für SSDs ist in beiden Fällen in vernünftigen/üblichen Leitungslängen.

Für Nutzung (2) gegenüber Gigabyte
+ ca. 50cm (!) weniger Leiterbahn onboard oder via Kabel
+ 2 Kontaktpunkte SlimSAS weniger
kein (-)

Die Nutzung für eine PCIe-Karte wäre insbesondere (!) unter Deinen Ausführungen der kritischen Leitungslängen damit wesentlich sinnvoller gelöst, bei etwa gleicher Qualität für direkte SSD-Nutzung.

Noch besser: Verbindung zwischen den oberen SlimSAS und dem Slot via Switch. Der hätte die kürzeste PCIe-Anbindung auf der Platine vom SoC zu oberhalb Slot 7, nach oben und unten 2-3cm Leitungsbahn und Bios (oder Brücke) entscheidet über Nutzung.
Meine Herrn. 4 Kabel zur Verbindung von 2x4 Onboard-Buchsen. Ich bin mir nicht sicher, ob ich größeren Unsinn beim Mainboard-Design bislang gesehen habe. Asus mit seinem special SAS-1068/1078-Zeug, Asus mit MIO-Soundslots, ... es gab schon viel Unsinn.
Aber alleine die Tatsache, dass eine PCIe-SLimSAS-Karte in den nächsten PC mitgenommen werden kann und die 4x25cm nach dem Mainboard für nichts mehr zu gebrauchen sind.
Nein, underclocker, komm mir nicht mit solchen Erklärungen. Ich habe die Entfernungen nicht nachgemessen. Aber runter zum Ende des Boards und zurück zum Slot die gleiche Strecke ist... dämlich. Deine Erklärung hat mich durch die Betonung der - mir bereits bewussten - kritischen Längen bei PCIe nicht vom Gegenteil überzeugt.
 
-seufz- ok. Dann mal meine kurze SIcht auf die meiner Meinung nach fehlerhafte Darstellung Deiner Lösung 1 + 2:

Du argumentierst - wie immer - fachlich über dem Niveau der meisten Leser hier, mich eingeschlossen. Jedoch m.E. unter unvollständiger Betrachtung der Sachlage, weil Du das Board-Layout nicht richtig darstellst.
Hast du dir das Board mal angeschaut? Die SlimSAS sind vom SoC ca. gleich weit weg wie der obere PCIe Slot.
(der untere PCIe Slot ist deutlich weiter weg, weil der SoC nahezu auf selber Höhe der SlimSAS sitzt, allein schon daran zu erkennen, da SoC und SlimSAS auch der "rechten" Seite und PCIe Slots auf der "linken" Seite sind, Grob bilden die Schnapper der RAM Slots dir Trennlinie)
Das kommt auf das Routing an. Aber es sind nicht 10cm vs. 25cm oder sowas. (nimm dir ruhig mal ein Lineal zum Messen, einfach mal Luftlinie vom SoC Mittelpunkt, das Board als ganzes hat gerade mal ne Gesamtkantenlänge von 30cm)
Das heißt grob, hat man an/vor dem PCIe Slot (wenn direkt angebunden) die selbe Signalqualität wie auf den SlimSAS Slots.
(hier kommen dann die Verluste des Slots zum Tragen)

Und dann hat man die ganzen Probleme, wenn man aus dem PCIe Slot SSD Ports machen will, + dass man nochmal über das gesamte Board muss, um quasi zum Rand zu kommen. In einer Serverplattform sitzen die SSDs vor dem Board. Damit ist der Weg vom SlimSAS deutlich kürzer als vom PCIe-Slot. Und erst recht, wenn man den PCIe Slot direkt anbindet. Man würde nämlich erstmal via Leiterbahnen von den SSDs weggehen, geht dann über mehrere Kontaktstellen (PCIe-Slot durchkontaktierte Lötstellen, Slot selber, SlimSAS) und muss den ganzen Weg via Kabel zum SoC zurück, dann noch weiter, und ist dann erst auf Höhe vom SlimSAS.

Klar kann man auch nen PCIe Switch einbauen. Aber warum macht das keiner? (gibt es nämlich auch nicht bei den ganzen anderen großen Herstellern (Dell und Co))
Kostet Geld, musst du erstmal unterbekommen (schau dir mal an, wie vollgepackt das Board ist) und dann hat man Kosten und vor allem auch ein Verfügbarkeitsproblem. Denn jedes Bauteil erhöht die Fehleranfälligkeit, geht damit auf die Verfügbarkeit und noch viel wichtiger, braucht ordentlich Strom und geht damit auf die CO2-Bilanz der RZ.
Hier sei der Hinweis erlaubt, dass es gesetzliche Anforderungen gibt, wie ein RZ beschaffen sein muss, ansonsten bindet man dir die Eier hoch. (.de Gesetz)

Nein, underclocker, komm mir nicht mit solchen Erklärungen. Ich habe die Entfernungen nicht nachgemessen. Aber runter zum Ende des Boards und zurück zum Slot die gleiche Strecke ist... dämlich. Deine Erklärung hat mich durch die Betonung der - mir bereits bewussten - kritischen Längen bei PCIe nicht vom Gegenteil überzeugt.
Ich habe nicht gesagt, dass SoC-SlimSAS-PCIe Slot die selbe Entfernung ist, sondern, dass dies klar schlechter ist (als eine Slot Direktanbindung), dies aber für den PCIe Slot noch ausreicht, da eben direkt nach dem Kabel schon der Slot kommt. Während aber gleichzeitig, die Slot Direktverbindung und von da zur NVMe Backplane eben bei weitem nicht mehr ausreicht, gepaart dem nächsten Punkt. Viel wichtiger ist aber, dass der PCIe Slot weitere Kontaktstellen und damit Signalstörstellen reinbringt, die der SlimSAS so nicht hat. Während also der SlimSAS nicht nur näher an der SSD ist (eben wegen sein physisch näheren Position zur SSD), sondern auch noch weniger und vor allem bessere Kontaktstellen hat, kommen bei der Slot Direktanbindung noch die Lötstellen des Slots, die Platinenkontakte der Karte im PCIe-Slot dazu sowie die Verbindung von der anderen Boardseite über das gesamte Board um an der Boardkante zu sein, die der SSD zugewandt ist. (wie gesagt, die gehst erstmal von der SSD weg(Leiterbahnen), baust Störstellen ein und musst dann wieder zurück (Kabel). Man treibt den Aufwand, um NVMe-Backplane ohne Zusatzbauteile akkurat anbinden zu können. Und da ist der PCIe Slot selten bis gar nicht zu gebrauchen, je nach Caselayout. Wie gesagt, schau dich mal am Markt um. Kein Serverhersteller bindet über solche Strecken (Standardlängen in einem Standard 2HE Server) SSDs über die PCIe Slots an.
Asrock hatte in einem ihrer Entry Server die SSDs über eine SlimSAS PCIe Bifu Karte angebunden. Der Unterschied ist, dass das ne ITX/Flex-ATX Lösung ist und die SSDs quasi direkt am Board sitzen und damit keine Kabelwege gegeben sind. Dort kann man relativ easy komplett ohne aktiver Signalaufbereitung auskommen, eben weil die Strecken kurz sind und man sich damit Reserven erkauft, die man auf dem PCIe Slot und der SlimSAS Karte wieder verbraten kann.
Hätte Asrock in dem Fall auch ein Standard Caselayout gehabt, wäre auch das nicht gegangen.

Mehr schreibe ich dazu aber auch nicht. Ich habe mehr als ausreichend dargelegt, wo das Problem liegt. Und eins kann man wohl glauben, dass die Gigabyte-Jungs nicht irgendwie die SlimSAS Ports aus dem Lager haben wollten, sondern dass es eine technische/kaufmännische/designtechnische Begründung gibt, dass sie sowas machen müssen. Wäre es einfacher gegangen, hätten sie es wohl gemacht, denn blöd sind die ja auch nicht. Ich habe die Gründe dargelegt, lebe damit oder glaube weiterhin, dass dir Kraft deiner Wassersuppe eine andere Bewertung der Umstände und damit der Lösung obliegt.

PS: Wie gesagt, Dell bindet aktuell nicht mal mehr die Riserslots über Boardsteckstellen an, sondern zieht selbst die mittlerweile über Kabel. Also genau das, was GB auf dem Board macht, nur nicht onboard sondern eben auf die Riser. Und auch da kann man wohl davon ausgehen, dass die nen groben Plan, also wirklich so ganz minimal, haben wie man PCIe auslegt.
 
Zuletzt bearbeitet:
Hey! Danke für diesen Guide ich könnte in China zwar die Rev 3.0 kaufen aber die 1.0 ist billiger. Geht das mit dem flashen noch und könntest du mir die Dateien senden?
 
Hey! Danke für diesen Guide ich könnte in China zwar die Rev 3.0 kaufen aber die 1.0 ist billiger. Geht das mit dem flashen noch und könntest du mir die Dateien senden?
Normal müsste das mit den Dateien auf der Gigabyte Website gehen. Falls nicht kann ich dir die Dateien gerne schicken
 
Moin, da hier gerade wieder Eigentümer posten: Ich habe die R34 aufgespielt und grds läuft das. Allerdings fehlt im BMC alles Sensor-relevantes: Keine Messewerte im Dashboard oder Sensor-Seite, und insbesondere zu meinem Leidwesen keine Fan-Control - hier fehlt sogar der im Handbuch genannte Menüpunkt...
Es ist auch die neueste BMC-Firmware drauf (.05).

Bin ich da alleine?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh