[Sammelthread] Gigabyte MC12-LE0 (AM4, B550, servertauglich: IPMI, Dual Lan, ECC)

Vorvorwort:
Danke an @pumuckel für das ursprüngliche Erstellen des Threads. Ich habe mich bereit erklärt den Thread zur Pflege zu übernehmen und um neue Inhalte zu ergänzen. Der ursprüngliche starter bleibt vorerst als Spoiler im letzten Abschnitt angehängt, damit keine Inhalte verloren gehen.

Vorwort:
Erstmalig in Erscheinung ist das Gigabyte MC12-LE0 kurz vor Weihnachten 2023 auf mydealz getreten. Mit einem Preis von 50€ Neuware war (ist) es ein no-brainer um noch einen günstigen Server auf AM4-Basis zusammen zu stellen. Aktuell (21.10.2024) liegt der Preis bei ~60€, wobei es in der Vergangenheit zwischen 80 und 30 € für Neuware geschwankt hat. Ähnliche Boards (AsRock Rack) und auch der Nachfolger MC13 liegen meist bei >300 €.

Von Gigabyte ist es als mATX Enterprise-Workstation-Motherboard eingestuft und eignet sich insbesondere wegen IPMI/BMC auch für den Servereinbau.

Eine nett gemeinter Hinweis vorweg: Wenn du neu bist wärst du nicht der erste, welcher mit dem Updateprozess (BMC & BIOS) und der Hardwareauswahl (Kompatibilität) Probleme hättest. Lies gerne den Starter, bevor du mit Planung und Umsetzung startest.

Viele Dinge werden auch im Thread diskutiert, es ist jedoch mein Bestreben die wichtigsten Dinge im Starter als zentrales Nachschlagewerk zu sammeln und würde dich bitten zunächst einmal dort nach deinem Problem zu suchen oder auch die Suchfunktion des Threads nach ähnlichen Beiträgen zu nutzen. Ich bin über jeden Hinweis zu fehlenden Inhalten im Starter dankbar und ergänze dieser gerne.



Inhaltsverzeichnis​

  1. Das Angebot
  2. Technische Daten
  3. Prozessor Support
  4. Anleitungen & Guides
    1. BIOS und BMC Update
    2. Reset BMC Passwort
  5. Bekannte Probleme
  6. FAQs
  7. Verbrauchswerte
  8. Linksammlung
  9. Vorheriger Starter


1. Das Angebot Nach oben

Das Board ist alleine oder oft für wenige Euro mehr mit einem kleinen Gelid Kühler erhältlich. Erster Händler, welcher es zu einem sehr günstigen Preis angeboten hat war piospartslab über ebay bzw. den eigenen Onlineshop. In beiden Fällen konnte man in Kombination mit Gutscheincodes nochmals günstigere Preise erreichen. Die meiste Zeit ist/war dieser Händler auf einem der Verkaufswege am günstigsten und ist nicht bei geizhals gelistet.
Wenn einem das Board zusagt, jedoch weniger Leistung braucht oder noch weniger ausgeben möchte und bastelwillig ist kann ein Blick auf das Nachbarboard mit SoC quadcore Epyc MJ11-EC1 lohnen.

In der Vergangeheit gab es sowohl bei eBay al sauch Piospartslab immer mal wieder Rabattgutscheine.
Erste Erwähnung im Luxx:


2. Technische DatenNach oben


880-png.960381
mc12-le0_blockdiagram-1027390689-png.1035466

  • mATX B550 AM4 Board für 3000-5000 AMD Ryzen (Achtung: keine 3000er Zen+ Picasso!)
  • bis zu 128 GB unbuffered (UDIMM) ECC oder non ECC (DDR4 2133-3200) (Achtung: KEIN registred/RDMM und KEIN LRDIMM!)
  • 2 x 1GbE LAN ports (Intel® I210-AT)
  • 1 x 10/100/1000 dedizierter management LAN port
  • Integrated in Aspeed® AST2500
    • "mini" onboard GPU zur Administation
    • 2D Video Graphic Adapter with PCIe bus interface
      1920x1200@60Hz 32bpp
  • Erweiterungsslots
    • 1 x PCIe 4.0 x16 (Gen4 x16 bus)slot from CPU
      • CPUs: Bitfuraction 8/8, 8/4/4 und 4/4/4/4 möglich
      • APUs: Bitfuraction nur 8/8 und 8/4/4 bzw 4/4/8 möglich
    • 1 x PCIe 4.0 x4 (Gen4 x4 bus)slot from CPU
      • (im Gegensatz zu anderen Boards direkt von der CPU = weniger Latenz und Probleme) ... die meisten Boards nutzen die Anbindung für die NVMe [@pumucke]
    • M.2 slot (über Chipsatz angebunden):
      • M-key
      • PCIe 3.0 x1 (max brutto 0,97 GByte/s)
  • Aspeed® AST2500 management controller
    GIGABYTE Management Console (AMI MegaRAC SP-X) web interface
    • Dashboard
    • HTML5 KVM
    • Sensor Monitor (Voltage, RPM, Temperature, CPU Status …etc.)
    • Sensor Reading History Data
    • FRU Information
    • SEL Log in Linear Storage / Circular Storage Policy
    • Hardware Inventory
    • Fan Profile
    • System Firewall
    • Power Consumption
    • Power Control
    • LDAP / AD / RADIUS Support
    • Backup & Restore Configuration
    • Remote BIOS/BMC/CPLD Update
    • Event Log Filter
    • User Management
    • Media Redirection Settings
    • PAM Order Settings
    • SSL Settings
    • SMTP Settings
  • nur bedingt für normale Desktop Systeme zu empfehlen
    • sehr wenig I/O-Ports (2x USB 3.1)
    • VGA nur für onboard Grafik, keine Bildausgabe einer APU
    • kein onboard Sound


3. Prozessor SupportNach oben

  • [Herstellerseite] Download: QVL Liste (mehr aber nicht alle CPUs aus der Tabelle unten)
  • Bei den 3000er Picasso APUs könnte man wegen der Namensgebung vermuten, dass sie laufen. Tun sie aber nicht (Zen+)
ACHTUNG: Die Tabelle vertauscht immer wieder die Spalten APU und ECC! Ich arbeite an der Fehlersuche.

CPUPassmark
multicore
Passmark
singlecore
Support?APUECC (+/Nein)iGPU
Intel N10055041943Nein
i5-850095812452Nein
3100115982420QVL-+
4650G Pro161662653QVLAPU++
3600177482567QVL-+
3600x189192652QVL-+
i5-12400193633519Nein
E5-2690v4194702074Nein
5500 (kein ECC)193983058APUAPUNeinN
5600G (kein ECC)198743190APUAPUNein+
5650G Pro207713252yAPU++
5600215763258y-+
5600x218883361QVL-+
3700x225422660QVL-Nein
5700 (kein ECC)242683250?APUNeinN
5700x266583382y-+
i5-13500318543884Nein
3900x326202706y-+
5950x455993468QVL, *Kühlung beachten-+

Grafischer Vergleich (danke @Haldi):
1730624072696.png


*Beim 5950X und teilweise auch anderen "großem" CPUs mit vielen Kernen wurde von Instabilitäten berichtet, da die Spannungsversorgung wohl realativ knapp bemessen ist. Unterschiedliche Nutzer haben die CPU mit unterschiedlichen Methoden stabil bekommen:
  • Wasserkühlung
  • Top-Blower (Thermalright baut große, leise)
  • Undervolting
  • Begrenzung der Leistungsaufnahme (PBO?)
  • hoher Airflow im Gehäuse
  • die Spannungswandler sind beim silbernen Kühlkörper links unter dem CPU Sockel (stimmt das?)


4. Anleitungen / GuideNach oben

4.1 UpdatesNach oben

Treiber, BIOS/UEFI und Firmware Updates gibt es auf der Herstellerseite.
Es gibt zwei Möglichkeiten das BIOS und die BMC Firmware zu upgraden: per UEFI oder BMC. Ich habe nur letzteres verwendet, andere finden das Update per UEFI einfacher.

per BMC:
  • eine unterstütze CPU einsetzen (bei mir ging es auch mit einem 5650G, welcher nicht auf der QVL steht)
  • einen Ramstick in Slot A1
  • Managment Lan mit Router verbinden
  • Board Starten (es muss laufen für den Update Prozess)
  • IP des Managment Interfaces Herausfinden (z. B. über ein fritzbox Menü)
  • mit der IP mit einem anderen Recher im gleichen Netzwerk verbinden
  • die Zugangsdaten stehen auf dem Karton und auf dem x16 PCIe Slot
  • die Flashvorgänge können bis zu 15 Minuten dauern, in der Zeit auf keinen Fall vom Strom trennen!
  • bei mir war nach erfolgreichem BIOS Update ein komplett stromlos machen des Boards für mehrere Minuten erforderlich
  • wenn man nur eine CPU hat, welche erst ab einerhöheren BIOS-Version unterstützt wird wäre meine Präferenz zuerst das BIOS zu updaten (wegen möglichem "BMC Passwort Brick")
  • BIOS Update
  • BMC Update
per UEFI (von @pumuckel):
  • eine CPU die auf der QVL ist einsetzen (aber die meisten 3er und 5er non -APUs klappen)
  • einen Ramstick in Slot A1 (hier sind 2133er wohl problemfreier als 3200er)
  • Tast/Maus/mon anschließen
  • System starten und abwarten (erster Start dauert etwas)
  • Achtung: der Browser sollte keinen Popup/script Schutz haben (notfalls einfach kurz ausmachen)
  • dann entweder per BMC oder per UEFI den BMC updaten (kann locker > 15 Min dauern, achtet auf die grüne "Heartbeat LED") - Full Flash
  • dann (wenn nötig) kurz restarten
  • dann das Bios entweder per BMC oder per UEFI updaten
  • dann runterfahren
  • Power trennen vom Board für 1-2 Minuten (aka das Netzteil abziehen)
  • nach 1-2 Minuten wieder anstecken und Spass haben

4.2 Reset BMC PasswortNach oben

Bei mir konnte ich mich bei einem von drei Boards nach einem BMC Update nicht mehr einloggen. Andere berichten von ähnlichen vorfällen. Ein Rücksetzen des BMC-Passwortes brachte abhilfe.

Ich habe gerade keine Zeit einen ganzen Guide zu machen, aber dir PDF dort sollte helfen:

to-DO:


5. Problembehandlung Nach oben

  • Reset BMC-PW
  • 5950X Abstürze


6. FAQsNach oben

  • Lüfterprofil
  • Stromverbrauch zu hoch (im BIOS gemessen, Systeamatisches Abklemmen von Komponenten, Minimalkonfiguration, 30W Thread)
  • KVM-Konsole öffnen
  • Web-BIOS aufrufen


7. VerbrauchswerteNach oben

  • 5600x Idle: 22W
  • 5650G Idle: 16W
  • die Liste soll später ergänzt werden, evtl. auch als Tabelle oder Online Sheet
Low Power Fetischisten könnten im folgenden Link Inspiration suchen. Wie man an den beiden Messwerten erkennen kann ist das MC12 bisher eher durch einen erhöhten Verbrauch (wegen dem BMC und u. A. den chiplet CPUs) aufgefallen.


8. LinksammlungNach oben



9. Früherer StartbeitragNach oben

Danke an @pumuckel für das ursprüngliche Erstellen des Threads. Ich habe mich bereit erklärt den Thread zur Pflege zu übernehmen und um neue Inhalte zu ergänzen. Der ursprüngliche Starter bleibt hier vorerst (oder auch für immer) angehängt, damit keine Inhalte verloren gehen.
------------- Vorwort, Credits und Angebote

Vorwort:


Wer mir ein vergleichbares NEUWARE Mainboard zu dem Preis mit den Features nennen kann, der darf dies gern tun.... bisher fand ich keines unter 200-400€
hingewiesen darauf hat @sch4kal zuerst im Marktplatz Link Thread

Vergleichbare MBs (ab 390€ mit PCIe 4.0):





Unterstützte CPUs: AMD 3000er und 5000er (und mit F15 wohl auch APUs mit intern - aka für VMs nutzbarer aber nicht extern - nutzbarer IGP)

Bestpreise lagen um die 35€ für das Board (ultra low war mal 27€ bei 4 Stück inkl kühler)


mit low profile Kühler:


ohne low profile Kühler

(hier die Gutscheine beachten!)



im Webshop von Pio (Ergänzung auf Userwunsch):

(hier die Widerrufsbelehrung beachten!)





------------- Zur Hardware

Gigabyte Mainboard MC12-LE0​


880.png


MC12-LE0_BlockDiagram-1027390689.png



mAtx B550 Am4 Board für 3000-5000er AMD CPUs
bis zu 128GB unbuffered ECC oder non ECC (DDR4 2133-3200) (ACHTUNG: KEIN REGISTERED ECC sondern unbuffered ECC)

2 x 1GbE LAN ports (Intel® I210-AT)
1 x 10/100/1000 management LAN

Integrated in Aspeed® AST2500
2D Video Graphic Adapter with PCIe bus interface
1920x1200@60Hz 32bpp


Expansion Slots

1 x PCIe x16 (Gen4 x16 bus) slot from CPU (Bifurcation 4/4/4/4 fähig mit NON -APUs)

Kommentar: setzt hier also normale CPUs ein . der 5600 (non x) ist imho hier ein sweetspot oder auch ein gebrauchter 3600x/3700x/3900x ...
generell würde ich bei 65W CPUs bleiben oder entsprechend die CPU limitieren (cTPU)

APUs können keine 4/4/4/4 bifurcation

1 x PCIe x4 (Gen4 x4 bus) slot from CPU (im Gegensatz zu anderen Boards direkt von der CPU = weniger Latenz und Probleme)
... die meisten Boards nutzen die Anbindung für die NVMe


1 x M.2 slot (über Chipsatz angebunden): (imho gut für ne kleine 128/256GB M2 SSD fürs OS - sowas bekommt ja nachgeworfen aus EDU stores und viele davon haben oft eh nur 2x PCIe 3.0)
- M-key
- PCIe Gen3 x1 (max brutto 0,97 GByte/s)
- Supports NGFF-2242/2280 cards




Board Management

Aspeed® AST2500 management controller
GIGABYTE Management Console (AMI MegaRAC SP-X) web interface


  • Dashboard
  • HTML5 KVM
  • Sensor Monitor (Voltage, RPM, Temperature, CPU Status …etc.)
  • Sensor Reading History Data
  • FRU Information
  • SEL Log in Linear Storage / Circular Storage Policy
  • Hardware Inventory
  • Fan Profile
  • System Firewall
  • Power Consumption
  • Power Control
  • LDAP / AD / RADIUS Support
  • Backup & Restore Configuration
  • Remote BIOS/BMC/CPLD Update
  • Event Log Filter
  • User Management
  • Media Redirection Settings
  • PAM Order Settings
  • SSL Settings
  • SMTP Settings

------------- Kühlerempfehlung

Top Blow der die Spawas links unter dem CPU Sockel abdeckt (Thermalright baut nette)
.. damit ist der silberne Kühlkörper links unter dem CPU Sockel gemeint

------------- Bios, BMC Firmware, Treiber

offizielle:

BMC: 12.61.21
Bios: F15


hier: https://www.gigabyte.com/de/Enterprise/Server-Motherboard/MC12-LE0-rev-1x#Support



die einfachste Weise das Board auf den aktuellen Stand zu bringen:

eine CPU die auf der QVL ist einsetzen (aber die meisten 3er und 5er non -APUs klappen)
einen Ramstick in Slot A1 (hier sind 2133er wohl problemfreier als 3200er)
Tast/Maus/mon anschließen
System starten und abwarten (erster Start dauert etwas)

Achtung: der Browser sollte keinen Popup/script Schutz haben (notfalls einfach kurz ausmachen)

dann entweder per BMC oder per UEFI den BMC updaten (kann locker > 15 Min dauern, achtet auf die grüne "Heartbeat LED") - Full Flash
dann (wenn nötig) kurz restarten
dann das Bios entweder per BMC oder per UEFI updaten
dann runterfahren
Power trennen vom Board für 1-2 Minuten (aka das Netzteil abziehen)
nach 1-2 Minuten wieder anstecken und Spass haben



es geht auch komplett per BMC aber für viele ist das schwieriger als es rein mit CPU und Ram gleich zu machen
ich z.B. hab grad 2 Boards von F06 (Auslieferungszustand) direkt auf aktuelle BMC und BIOS F15 per BMC (mit CPU/Ram eingesetzt) ohne Probleme geupdated (21-9-2024)


------------- Reset des BMC Passwort



... hier das PDF beachten


------------- Q&A


Passmark Scores ausgewählter CPUs zum Vergleich :

i5-8500: 9581 (6 Core S1151)
3600: 17776 (Zen2)
3600x: 18227 (Zen2)
i5-12400: 19557
E5-2690v4 : 19619 (S2011-3)
5600: 21592 <------ P/L

5600x: 21926
3700x: 22598 (Zen2)
5700x: 26738
i5-13500: 32250
3900x: 32678 (Zen2)
5950x: 45633 (hier muss aber wohl manuell die Spannung begrenzt werden (glaube unter 1,4V)) - aber gute Performance/W/€


------------- Links zu anderen Forendiskussionen


STH: https://forums.servethehome.com/ind...oard-mc12-le0-re1-0-amd-b550-am4-ryzen.42579/
L1T: https://forum.level1techs.com/t/gigabyte-mc12-le0/183692/21



------------- User Anmerkungen (selbst nicht geprüft)

@BobbyD:
  • Das BMC Passwort steht auf dem (Anmerkung: brauner Außenkarton an der Seite) Karton
  • Fürs BMC-Update über das BMC ist folgende Datei auszuwählen: "rom.ima_enc" Mode:BMC
  • Fürs BIOS-Update über das BMC ist folgende Datei auszuwählen: "image.RBU" Mode:Bios
#
#
 
Zuletzt bearbeitet:
Mehr Sorgen würde ich mir machen, dass die allermeisten SATA-SSDs noch mit alter, nicht ganz so langlebiger Speichertechnik arbeiten, von daher dürften sie nicht so lange halten. Und sie sind insofern einfach sehr teuer im Vergleich.

Wenn es geht, würde ich NVMe bevorzugen.

Danke euch zwei. Dann wäre das auch eine Option auf dem Board.
Ja bei ZFS in einem Mirror hab ich schon Erfahrung mit Consumer SSDs.
Wegen den Sync-Writes war das am Ende eine Katastrophe.
Hier gibt es für mich nur noch hochwertige Enterprise mit PLP.
Beitrag automatisch zusammengeführt:

Ob es durch die heute viele schnelleren Consumer SSDs besser ist weiß ich nicht. Test ist gut 3 Jahre her.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe jetzt gestern Mal die weiteren Teile für meinen neuen Server in einer Tabelle erfasst.
Erschreckend war, dass RAM, CPU doch ordentlich zu Buche schlagen für eine „alte“ Plattform.

Hat sich jemand ggf. auch überlegt gleich auf AM5 mit z.B. dem Asus Pro B650M-CT-CSM zu gehen.
ECC RAM ist nicht viel teuere und CPUs (APU) mit mehr als 6 Kernen viel günstiger.
Sind hier am Ende mehr Nachteile als nur kein IPMI?
 
Hat sich jemand ggf. auch überlegt gleich auf AM5 mit z.B. dem Asus Pro B650M-CT-CSM zu gehen.
Ja, das Board hatte ich auch schon angeschaut. Finde ich auch eine spannende Variante, muss ich sagen.
 
Wie kommst Du auf so was, einfach mal ausgedacht?
Natürlich nicht. Natürlich bekommt man auch halbwegs aktuelle Technik, da schrieb ich ja: "relativ teuer".

Modelle wie die MX500 haben bereits 7-8 Jahre auf dem Buckel. Ja, ich weiß, davon hat es auch ein refreshtes 4TB-Modell im Programm. Kostet aber wie eine 990 Pro mit 4TB knapp 300 Euro. IOPS ist der relevanteste Aspekt - ich kenne kein SATA-Produkt, was konkurrenzfähig zur guten NVMe-Palette wäre.

Man muss auch bedenken: Kontext dieses Threads ist ein Board für knapp 40 Euro inkl. Versand. Von daher habe ich auch industrial SATA-SSDs nicht betrachtet.
 
Zuletzt bearbeitet:
Ja, das Board hatte ich auch schon angeschaut. Finde ich auch eine spannende Variante, muss ich sagen.
Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?
 
Hat hier jemand seinen Storage für die VMs aus SATA-SSDs realisiert und kann was zur Performance sagen.
Die maximale Datenrate im Vergleich zu NVME ist natürlich viel schlechter, aber in der Praxis kleine Dateien sollten genauso schnell sein. Somit als VM Storage ggf. in Ordnung.
Richtig oder seht ihr das anders und für VM Storage nur NVME?
"VM" ist ein dehnbarer Begriff.
Du solltest deine Frage schon geanuer formulieren, sonst bekommst auch entsprechend ungenaue Antworten.

Meine ungenaue Antwort: SATA wird allemal reichen.
 
Du hast dich am Ende dann für AM4 entschieden, weil du wahrscheinlich noch alte HW hattest die du weiterverwenden konntest?
Hast wahrscheinlich nicht alles neu gekauft, wie wahrscheinlich die meisten hier?
Nein, weder noch.
Für mich ist das sinnigste, das Gigabyte MJ11-EC1 zu verwenden, denn da habe ich alles da - inklusive sehr günstigem RAM und passendes Gehäuse. Einzig was mich etwas ärgert sind die geringen Erweiterungsmöglichkeiten. Ein AM5-System wäre da sehr reizvoll, aber realistisch eher in der Kategorie "Spielerei" für mich zu sehen.
Ende des Jahres steht ein Umzug an und vielleicht auch eine Erweiterung des HomeServers, vielleicht wird's dann nochmal spannend :xmas:
 
Neues BIOS F15:
1) Updated to AGESA 1.2.0.Ca.
2) Fixed LogoFAIL Vulnerability.
3) Fixed PixieFAIL Vulnerability.
Edit: Hab den Eindruck, dass unter Windows SecureBoot nicht mehr funktioniert. Vielleicht habe ich es auch nur nicht hart genug versucht. 😉
 
Zuletzt bearbeitet:
Neues BIOS F15:

Edit: Hab den Eindruck, dass unter Windows SecureBoot nicht mehr funktioniert. Vielleicht habe ich es auch nur nicht hart genug versucht. 😉
Ich fühle mich schon wie ein Fanboy, so wie ich mich freue :LOL:

Haben dadurch die APUs nun "offiziellen" Support?
Laut den Releasenotes war da schon etwas seit F8, aber ob das gleichzusetzen mit "offzieller Support" ist? Nach Lesart würde ich eigentlich sagen, dass ja. Wie denkt ihr dazu?
1724248592936.png
 
IPMI und OOB-Management via BMC ist halt doch nochmal deutlich mehr als iKVM.
Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?

Verbrauch wäre interessant.
0.2A bei 5V via USB... Also 1W oder weniger.
Sag ich dir wenn ich ihn hab :) USB Power Meter ist bereits vorhanden.
 
Ich hab ja gerade mal das dritte MC12-LE0-System mit nem 5600G zusammen gestöpselt und liege da im idle bei insgesamt 18W (430W ATX Power Supply, eine SATA-SSD, ein Ram-Riegel - sonst nüschts drin&dran). OS ist allerdings Windows 11.
 
Joa... Aber benötigt der HomeUser hier der sich ein Board für 35-100€ kauft das unbedingt? Welche Features sind denn da so wichtig?
Ist das nicht eher Enterprise level für 500-700€ baords?
Was einem wichtig ist, ist glaube ich ziemlich individuell ;) Ich wollte nur das Gleichsetzen von iKVM und IPMI torpedieren, weil das "ich kann den PC bedienen, als wuerde ich gerade vor ihm sitzen"-Feature vielleicht fuer viele Leute den obersten, offensichtlichsten Nutzen von OOB-Management via IPMI darstellt, aber es damit halt nicht getan ist. Ich finde es z. B. sehr Hilfreich ein System Event Log (SEL) zu haben, das mir unabhaengig vom Host-OS ein Tagebuch ueber ggf. bedenkliche Ereignisse (Komponenten-Fehler im Betrieb, unerwartete Reboots/Power Cuts, etc.) bietet. Auch dass ich die gesamte Sensorik des Hosts via IPMI auslesen kann, das Host-BIOS-ROM flashen, die Host-POST-Codes interpretieren... das sind alles Features, die schnell einmal wichtig (oder zumindest sehr praktisch) werden koennen, die man mit so einer PiKVM-artigen Dranstoepsel-Loesung prinzipbedingt kaum kriegen kann.
 
Muss mal von F14 auf F15 updaten
Ich habe es noch nicht einmal auf F14 geschafft :ROFLMAO:

Auf F14 soll das mit der APU/iGPU ja angeblich bereits besser laufen. Falls jemand das nochmal auf F15 testet:
Gerne berichten!
 
Ach cool, F15 ist ja sogar eine offizielle Version (vom 20. August 2024).
 
Die Optionen dafür sind auf jeden Fall noch da, konnte es aber wegen mangelnder iGPU nicht testen.
 
Wie testet man denn überhaupt die Funktion? Bildausgabe bekommste ja eh nur über die AST-Grafik.
 
Gerade F15 installiert:

iGPU meines 4650G wird unter Linux (TrueNAS Scale) erkannt (UMA AUTO unter GFX configuration)
ansonsten nicht wirklich Neues im BIOS gefunden
 
Gerade drüber gestolpert: Da verkauft einer neben RDIMM auch UDIMM ECC (2666) für 20€/16GB, ich denke ganz akzeptabler Preis aktuell:

Keine Garantie! Das Risiko ob das ein zuverlässiger Verkäufer ist muss jeder selbst wissen! Ich habe das in der Vergangenheit immer so gehandhabt meist "zu PayPalen" und nachgefragt ob die einen Memtest laufen lassen können. Und wenn nicht, wie es aussieht wenn bei meinem Test Fehler auftauchen.
 
Heute muss ich mir mal ein bisschen Frust von der Seele tippen hier :')


Wie sich manche erinnern, arbeite ich ja (ja, immer noch! bzw. in den letzten Tagen mit wiedererstarktem Eifer :)) am Port von OpenBMC auf dieses Board. Die letzten paar Abende waren eigentlich gepraegt von schoenen Fortschritten. Ich hab mich auf die DeviceTree-/Kernel-Seite der OpenBMC-Firmware konzentriert und Userspace-Sachen (d. h. die Integration der Kernel-seitigen Features in das, was man via IPMI, Webinterace etc. ansprechen und so via OpenBMC als "User" bzw. Admin nutzen kann) auf die lange Bank geschoben. Das hat zu einigen kleinen Durchbruechen gefuehrt: Die I2C-Configs sind jetzt ofenbar soweit korrekt, dass ich fuer die Spannungs- und Temperatursensoren am Board nun (bei manchen mehr, bei manchen aber auch weniger ;)) sinnvolle Werte auslesen kann. Ich kann die PWM-Werte aller Fan-Header am Board via sysfs regeln. Ich kann die ID-LED des Board per sysfs an- und ausschalten. Alles notwendige Vorarbeit, um OpenBMC-Userspace so konfigurieren zu koennen, dass eine funktionstuechtige OpenBMC-Distro entstehen kann.


Dabei hat mich immer wieder geaergert, dass ich die Ethernet-Konfiguration weder in u-boot, noch in Linux 100% korrekt hinbekommen hatte - das hatte nervige Auswirkungen auf meinen Arbeitskomfort, weil die Bandbreite des Ethernet-Links durch irgendeine Unstimmigkeit in der Initialisierung des MII (oder vielleicht auch von NCSI - ich verstehe das alles leider nur zu ~10-20% ) ziemlich im Eimer - effektiv bei wenigen zig KByte/s - war. Also wollte ich das durch Trial und Error (mangels Board Schematics kenne ich keinen anderen Weg) fixen, und hab begonnen, unterschiedliche denkbare Kombinationen durchzuprobieren. Das hatte u. a. mal den Effekt, dass ich sowohl dem BMC als auch dem Host saemliches Ethernet-Schnittstellen permanent deaktiviert hatte - und mich lernen lassen, wie ich via XMODEM (den Namen/das Protokoll kannte ich zuvor nur aus Heldengeschichten von mir bekannten BBS-Altvorderen ;)) fette BLOBs mit viel Geduld ueber meine Debug-Konsole auf das BMC-Filesystem bekomme :d


Die letzte Kombination aus PHY-Configs, die ich gerade vorhin probiert habe, hat mich und meinen armen BMC aber leider in ein neues Gefaengnis gestubst, aus dem wir offenbar nicht mehr rauskommen koennen... u-boot initialisiert jetzt den AST2500 bis zum ersten Netzwerkinterface, und dann haengt sich die CPU in einem busy loop auf. Sieht so aus:


Code:
U-Boot 2019.04 (Jul 26 2024 - 07:18:46 +0000)

SOC : AST2500-A2
RST : WDT3 - Boot
RST : Power On
LPC Mode : SIO:Enable : SuperIO-2e
Eth : MAC0: RMII/NCSI, , MAC1: RGMII,
Model: Gigabyte MC12-LE0 u-boot
DRAM:  496 MiB (capacity:512 MiB, VGA:16 MiB, ECC:off)
MMC:
Loading Environment from SPI Flash... SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@1e784000
Net:   ftgmac100_probe - NCSI detected

Dort haengt der BMC also ewig und tut nix mehr. Bloederweise ist das, NACHDEM u-boot die Mitigations fuer die Schwachstellen in der Host-BMC-Kommunikation durchgefuehrt hat - was bedeutet, dass ich den Chip mit der BMC-Firmware auch nicht via Host flashen kann.

Bleibt mir wohl nichts anderes uebrig, als zu versuchen, den n25q512ax3 mit der BMC-Firmware drauf per Flash-Programmer zu wipen (davon kann ich recovern, das hatte ich ja schon mal versehentlich geschafft :fresse2:) bzw. den Chip gleich mit einem nicht-brickenden Image neu zu flashen.

Tja... und jetzt bin ich hier, und starre auf das Datenblatt des Chips, meine Debug-Klemme fuer den 16-Pin-Sockel, und male mir aus, was beim Rettungsversuch noch alles schiefgehen koennte. Sollte das alles nicht zu einem toedlichen Zimmerbrand fuehren, lest ihr vielleicht mal, wie (oder ob) es ausgegangen ist! :d
 
HAHAHAHA LEUTE, I SURE WAS DOWN, BUT I WAS NOT OUT!!!! :d :d :d

Kurzmoral von der Geschicht: Rumweinen bei Paul hilft, er hat einfach immer die besten Ideen :d

Langfassung: Stellt sich raus dass dem n25q512ax3 man durch Shorten der Pins #10 (VSS/Ground) und #15 (DQ0) verhindern kann, dass der Inhalt durch den BMC gelesen werden kann. Das hab ich nach ein bisschen Ratlosigkeit im Umgang mit der 16er-Klemme recht schnell geschaft gehabt, was dazu gefuehrt hat, dass der UART-Debug-Port trotz Power still geblieben ist. Das ist gut, weil so kann der AST2500 nicht die Instruktionen aus dem Flash lesen, die ihn unverwundbar gegenueber Angriff aus dem Hostsystem machen. Ein paar Minuten spaeter verliert der Host die Geduld beim Warten auf den BMC (das ist auch bei voellig zerstoertem Flash-Inhalt, also ohne BMC-Firmware, so der Fall) und faehrt auch hoch.

Leider hat sich schnell gezeigt, dass der BMC periodisch immer wieder versucht, vom Flash seine Firmware zu laden und zu booten - es war also nicht damit getan, ihn ein Mal am Beginn der Uptime am Booten zu hindern, sondern ich musste die Klemme mit den geshorteten Pins dranlassen.

In meinem so am Host gebooteten grml konnte ich aber immerhin mit culvert taetig werden. Ohne die Mitigations, die u-boot mitbringt, kann man da viel anstellen - mit `culvert probe` war klar, dass der AST2500 am Leben (und offen wie ein Scheunentor) ist:

Code:
root@grml /tmp # ./culvert probe
[*] failed to initialise devmem bridge: -1
[*] Accessing the BMC's AHB via the p2a bridge
debug:  Permissive
        Debug UART port: UART5
xdma:   Restricted
        BMC: Disabled
        VGA: Enabled
        XDMA on VGA: Enabled
        XDMA is constrained: Yes
p2a:    Permissive
        BMC: Disabled
        VGA: Enabled
        MMIO on VGA: Enabled
        [0x00000000 - 0x0fffffff]   Firmware: Writable
        [0x10000000 - 0x1fffffff]     SoC IO: Writable
        [0x20000000 - 0x2fffffff]  BMC Flash: Writable
        [0x30000000 - 0x3fffffff] Host Flash: Writable
        [0x40000000 - 0x5fffffff]   Reserved: Writable
        [0x60000000 - 0x7fffffff]   LPC Host: Writable
        [0x80000000 - 0xffffffff]       DRAM: Writable
ilpc:   Permissive
        SuperIO address: 0x2e

... aber das Flashen eines korrigierten OpenBMC-Images sollte (wegen des Pin-Short-Tricks, mit dem ich den Zugriff auf den Flash verhindert hatte) ein Problem darstellen. In diesem Zustand konnte die von culvert verwendete libflash nicht einmal ermitteln, welcher Baustein da am SPI sitzt und gelesen oder beschrieben werden koennte.

Die Theorie war nun, dass ich mit einem schnellen Loop aus `culvert firmware write < myimagefile` vielleicht nach Abziehen der Bruecke ueber die Pins eine vermutete Race Condition zwischen dem AST2500-Reboot-Timer und dem Beschreiben des Flashs gewinnen koennte. Und... naja, fast:

Code:
# while :; do ./culvert write firmware < /tmp/image-bmc && break; done
[*] Accessing the BMC's AHB via the p2a bridge
[*] Preventing system reset
[*] Gating ARM clock
[*] Configuring VUART for host Tx discard
[*] Initialising flash subsystem
[*] Writing firmware image
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000
.
................................................................................................................................................................................................................................................................
[*] LIBFLASH: Miscompare at 0x00020000

Da war culvert nach ein paar Bytes die Luft ausgegangen. Aber ich witterte dennoch Morgenluft, denn die geschrieben Bloecke haben ausgereicht, um den Bootloader im Flash effektiv zu zerstoeren, und den BMC schon etwas VOR dem frueheren Stillstandszeitpunkt zu bricken. Sah so aus:

Code:
[...picocom init...]
Type [C-a] [C-h] to see available commands
Terminal ready

DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)

Ende Gelaende. Quasi der selbe Zustand, wie wenn ALLES im Flash kaputtgeschlagen wurde. Ihr seht vielleicht schon, wohin das fuehrt :banana: u-boot versucht in diesem Zustand nicht mehr, weiter Daten vom Flash zu laden - ich spare mir also den Clamp-Trick. Das bedeutet auch, dass ich den BMC in diesen kaputten Zustand booten lassen kann, waehrend ich ueber AHB via culvert aus dem Host ganz bequem und ungestoert alle Operationen durchfuehren kann - auch das bereits erprobte `firmware write`. Und tatsaechlich, einen Power Cut (mit einem geeigneten OpenBMC-Image am Host paratgelegt) spaeter:

Code:
root@grml /tmp # ./culvert write firmware < /tmp/image-bmc
[...]
................................................................................................................................................................................................................................................................
................................................................................................................................................................................................................................................................
[*] Performing SoC reset
./culvert write firmware < /tmp/image-bmc  405.86s user 0.88s system 98% cpu 6:52.77 total

... der BMC so:

Code:
DRAM Init-V12-DDR4
0abc1-4Gb-Done
Read margin-DL:0.3784/DH:0.3823 CK (min:0.30)


U-Boot 2019.04 (Jul 26 2024 - 07:18:46 +0000)

SOC : AST2500-A2
RST : WDT2 - 2nd Boot
default boot
RST : WDT3 - Boot
RST : Power On
LPC Mode : SIO:Enable : SuperIO-2e
Eth : MAC0: RMII/NCSI, , MAC1: RGMII,
Model: Gigabyte MC12-LE0 u-boot
DRAM:  496 MiB (capacity:512 MiB, VGA:16 MiB, ECC:off)
MMC: 
Loading Environment from SPI Flash... SF: Detected n25q512ax3 with page size 256 Bytes, erase size 4 KiB, total 64 MiB
*** Warning - bad CRC, using default environment

In:    serial@1e784000
Out:   serial@1e784000
Err:   serial@1e784000
Net:   Invalid PHY interface '<NULL>'
eth-1: ethernet@1e660000Invalid PHY interface '<NULL>'
, eth-1: ethernet@1e680000
Hit any key to stop autoboot:  0
## Loading kernel from FIT Image at 20100000 ...
   Using 'conf-gigabyte-mc12-le0.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x20100118
     Data Size:    3279824 Bytes = 3.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80001000
     Entry Point:  0x80001000
     Hash algo:    sha256
     Hash value:   ac104186382035da31caec0dd5b32fc612acf419ae5bcfa15226f7d15556c5d0
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 20100000 ...

BOOM!!! Back. In. The. Game!! :angel:


Danke fuers Lesen, und vielleicht auch Mitfiebern :d Was fuer ein Abend! Ich liebe diesen Sche*ß! :wut::bigok:
 
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