Gigabyte Mainboard MC12-LE0 AM4, IPMI, Dual Intel GB Lan ECC fähig

@c0l0 Congrats, das ließt sich doch sehr gut. Ich mag diese Storys sehr, denn man bekommt in etwa eine Vorstellung, wie viele graue Haare sowas ggf nach sich ziehen kann. 😅 Gerne mehr von diesen geschichten (und weniger graue Haare ;-) ).
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@c0l0
Meinen Respekt für den ganzen Einsatz den du zeigst für das Projekt.
Ich hab weder das KnowHow noch das durchhalte vermögen so intensiv an dieser Art von Problemstellung zu arbeiten.
 
@c0l0 solltest du zum Experimentieren noch ein paar Bauteile oder ein ganzes Board brauchen, könnte ich dir meins mit dem abgeknickten Powerstage schicken.
 
Vielen Dank fuer euren Support - sowohl moralisch als auch wie angeboten materiell! :wink:

Inzwischen hab ich recht viel Erfahrung sammeln koennen mit dem Kopf-aus-der-Schlinge-ziehen, weil ich glaube, dass ich BMC und/oder Board schon vier Mal auf den ersten Blick "bricked" hatte - und es dann doch noch einen Weg gab, das eine mit dem anderen zu retten. Und dann hab ich ja noch zwei Boards als Spares auf Lager :xmas: Die werde ich HOFFENTLICH nicht alle durchheizen in den kommenden Experimenten... wo mir doch schon das eine erste hier so lange treue Dienste leistet, und saemtliche Miss- und Behandlungen geduldig ertraegt.

Wobei ich es offenbar doch erstmalig geschafft habe, etwas am Board nachhaltig zu ruinieren: Am I2C-Bus #4 war auf Adresse 0x28 immer ein Sensor zu finden (ein NCT7802), und der ist seit einigen Tagen einfach... "weg". Meldet sich nimmer. Ich kann nur vermuten, dass er irgendeine meiner Aktivitaeten am Bus nicht gut vertragen hat. Ich -> :shot: <- NCT7802

Sad! Aber die Reise geht weiter! ;) Heute mache ich wohl wieder GPIO-Schabernack und hoffe, dass meine Frau mir irgendwann fuer das alles vergeben wird :hail:
 
cramfs-root/etc/devmaps/... für die I2C Sensor-Adressen ist bereits bekannt?
Ja klar, die Teilmenge aus den Informationen im XML-Dokument, die tatsaechlich korrekt zu sein scheint, habe ich schon in meinem DTS :) Was ich noch irgendwann erledigen muss ist ein Abgleich der Datei bzw. Informationen daraus zwischen all den Stock-Firmware-Releases, die man so auftreiben kann. Ich hab bisher auf Basis der Version "1619109933" gearbeitet, wo afaict leider auch relativ viel Bloedsinn, der auf dem Board einfach nicht vorhanden ist, konfiguriert ist.

Ich hab eben mal beim Gigabyte-Support hoeflich nach den Schematics gefragt - vielleicht ist ja dort jemand gewillt, diese undankbare Arbeit zu beschleunigen :coffee2:
 
Hat jemand Erfahrung mit dem F15 BIOS sammeln können ?
derzeit nicht, aber da es offiziell ist ist es unter der Garantie/Gewährleistung ... daher hab ich es auch in den 1. Post aufgenommen als es @BobbyD postete (BTW lieben dank dir dafür)

... das war auch der Grund warum ich nie das F14 verlinkt hab
 
Falls jemand von euch auf das Board im Betrieb mit der BMC-Stock-FW mit aktivem SSH-Zugriff (ich hab hier leider nur Platz fuer eine einzige "Testbench", und das Board mit all den Debug-Klemmen und Verbindungen darauf zu wechseln ist besch...eiden komfortabel :d) auf die BMC-Shell parat hat - kann mir da jemand bitte die Ausgabe der Kommandos

Code:
/usr/local/bin/skuparser -X /tmp/SKU.xml -x //BoardInfo/Main/ID

und

Code:
/usr/local/bin/pcbid

und

Code:
/usr/local/bin/skuparser -X /tmp/SKU.xml -x //BoardInfo/Main/Platform

posten? Danke!

Ich bereite mich derweilen mal mental drauf vor, das Host-BIOS via OpenBMC zu flashen :coolblue:
 
Nein.
Hat SSH ein Separates Passwort vom Web Interface?
Finde keinerlei Einstellungen dazu...
Screenshot_20240825_120643_Firefox.jpg
Code:
Starting a new connection to: "192.168.1.8" port "22"
⚙️ Starting address resolution of "192.168.1.8"
⚙️ Address resolution finished
⚙️ Connecting to "192.168.1.8" port "22"
👤 Connection to "192.168.1.8" established
⚙️ Starting SSH session
⚙️ Remote server: SSH-2.0-OpenSSH_7.9p1 Debian-8
⚙️ Agreed KEX algorithm: ecdh-sha2-nistp256
⚙️ Agreed Host Key algorithm: ssh-rsa
⚙️ Agreed server-to-client cipher: aes128-ctr MAC: hmac-sha2-256
⚙️ Agreed client-to-server cipher: aes128-ctr MAC: hmac-sha2-256
⚙️ Agreed client-to-server compression: none
⚙️ Agreed server-to-client compression: none
⚙️ Handshake finished
👤 Checking host key: 42:ef:ba:83:28:00:ee:e2:a6:c1:30:22:4b:9d:c0:7b
👤 Host "192.168.1.8":"22" is known and matches
👤 Authenticating to "192.168.1.8":"22" as "admin"
⚙️ Available client authentication methods: publickey,password,keyboard-interactive
⚙️ Authentication that can continue: publickey,password
👤 Authenticating using publickey method
❗ Authentication failed (publickey)
⚙️ Partial success: no
⚙️ Authentication that can continue: publickey,password
👤 Authenticating using password method
❗ Authentication failed (password)
⚙️ Partial success: no
⚙️ Authentication that can continue: publickey,password
👤 Authenticating using password method
❗ Authentication failed (password)
⚙️ Partial success: no
⚙️ Authentication that can continue: publickey,password
👤 Authenticating using password method
❗ Authentication failed (password)
⚙️ Partial success: no
⚙️ Authentication that can continue: publickey,password
😨 No more authentication methods to try
 
Kommt auf die BMC-Firmware-Release an. Zumindest das erste Release hatte hardcoded "sysadmin:superuser", in spaeteren Releases muss man zuerst ueber HTTP-API/Webinterface den Zugang via SSH einstellen, bzw. das Passwort dafuer festlegen.

Btw, ich hab wohl offenbar gerade wirklich beim Aufzeichnen von GPIO-Daten den BMC-Firmware-Flashbaustein auf meinem Board gegrillt... :-[ :(
 
12.61.19 ist die aktuelle BMC Firmware oder? sysadmin:superuser läuft jedenfalls nicht.
Ich hab im User Management nur den SSH key, Der nicht funktioniert.
In den Services->ssh steht nix von Passwort drin.
 

Anhänge

  • Screenshot_20240825_123201_Firefox.jpg
    Screenshot_20240825_123201_Firefox.jpg
    139,2 KB · Aufrufe: 29
  • Screenshot_20240825_123304_Firefox.jpg
    Screenshot_20240825_123304_Firefox.jpg
    102,4 KB · Aufrufe: 30
Da steht upload SSH Key. Gib im Terminal
Code:
ssh-keygen
ein. Der Schlüssel sollte dann in .\.ssh\id_rsa.pub liegen.
 
Ich hab leider gerade keine Stock-FW auf einem lauffaehigen herumflitzen, um nachzusehen, wo genau ich diese Option damals gefunden habe... reiche ich nach! Ich glaube, die Information, die ich weiter oben gesucht hab, inzwischen schon aus einem Dump der Stock-Firmware extrahiert zu haben. Waere aber dennoch dankbar, wenn sie jemand hier als Bestaetigung posten koennte irgendwann! :)

@Andi bz: Das Hochladen eines SSH-Pubkeys an der Stelle bringt afair nichts, weil das Feature in der Stock-Firmware kaputt ist (das war der initiale Motivator fuer mich, diesen OpenBMC-Marathon zu beginnen :fresse2:).


Ich konnte den Flash auf meinem Board gestern uebrigens doch noch retten. Der AST2500 war so tot wie noch nie (kein Mucks am UART, culvert konnte den Chip zwar proben und auch RAM dumpen, aber via SPI nichts vom Flash lesen und diesen auch nicht beschreiben), aber gigaflash (das Gigabyte-gebrandete socflash-Utility) konnte trotzdem ein Stock-ROM-Image aufspielen. Bloederweise hat der AST2500 daraufhin auch nicht funktioniert (selbes Verhalten wie vor dem Flashen, hat mir echt Sorgen gemacht :d) - ABER das erfolgreiche Beschreiben mit gigaflash hat auch culvert in die Lage versetzt, wieder eines meiner OpenBMC-Images aufzuspielen - und damit/davon hat der BMC dann wieder booten koennen. Verstehe ich das? Nah! Bin ich froh darueber? Sehr! :)
 
Code:
root [~]$ /usr/local/bin/skuparser -X /tmp/SKU.xml -x //BoardInfo/Main/ID
0x100f
root [~]$ /usr/local/bin/pcbid
12
root [~]$ /usr/local/bin/skuparser -X /tmp/SKU.xml -x //BoardInfo/Main/Platform
AMD
 
Ich finde das BMC-Interface ehrlich gesagt zum teil unbrauchbar . Besonders die CD-Upload-Funktion der Live-Konsole. Der Upload ist nicht nur extrem langsam, sondern bricht auch häufig einfach ab. Habe es bisher nur einmal geschafft, davon zu booten, die Installation von PVE ist dann aber einfach mittendrin eingefroren.

Ein weiteres nerviges Problem ist, dass sich das Mainboard beim Neustart häufig mit einer neuen MAC-Adresse meldet und dadurch eine andere IP-Adresse vom DHCP-Server zugewiesen bekommt. Manchmal hilft es, das System noch einmal neu zu starten, um die ursprüngliche MAC-Adresse wieder zu erhalten, aber das ist natürlich keine Lösung.

Im Vergleich dazu hatte ich mit den IPMI/BMC-Interfaces von Supermicro solche Probleme nicht. Ist das bei euch auch so, oder mache ich irgendwas falsch ?
 
Besonders die CD-Upload-Funktion der Live-Konsole. Der Upload ist nicht nur extrem langsam, sondern bricht auch häufig einfach ab.
Das Langsame hat mich auch schon gestört, ist das normal? Abbrüche hatte ich noch nicht und vermutlich annähernd zweistellige Boots darüber.

Probleme mit einer wechselnden MAC hatte ich auch noch nicht. Hast du das Board mit mehreren Kabeln mit dem Netzwerk verbunden? Vielleicht kommt es da zu einem Durcheinander.
 
Ich finde das BMC-Interface ehrlich gesagt zum teil unbrauchbar . Besonders die CD-Upload-Funktion der Live-Konsole. Der Upload ist nicht nur extrem langsam, sondern bricht auch häufig einfach ab. Habe es bisher nur einmal geschafft, davon zu booten, die Installation von PVE ist dann aber einfach mittendrin eingefroren.

Ein weiteres nerviges Problem ist, dass sich das Mainboard beim Neustart häufig mit einer neuen MAC-Adresse meldet und dadurch eine andere IP-Adresse vom DHCP-Server zugewiesen bekommt. Manchmal hilft es, das System noch einmal neu zu starten, um die ursprüngliche MAC-Adresse wieder zu erhalten, aber das ist natürlich keine Lösung.

Im Vergleich dazu hatte ich mit den IPMI/BMC-Interfaces von Supermicro solche Probleme nicht. Ist das bei euch auch so, oder mache ich irgendwas falsch ?
Ja, ISO-Upload war auch mir zu langsam, weshalb ich damals dann tatsächlich zum Serverlief und per USB-Stick arbeitete um TrueNas bzw später dann Proxmox zu installieren.

Das mit der wechselnden MAC kenne ich nicht, welches BMC-Version hast installiert?
(Halbwissen, an einer schwachen Batterie kann es nicht liegen oder?)
 
Ich finde das BMC-Interface ehrlich gesagt zum teil unbrauchbar . Besonders die CD-Upload-Funktion der Live-Konsole. Der Upload ist nicht nur extrem langsam, sondern bricht auch häufig einfach ab. Habe es bisher nur einmal geschafft, davon zu booten, die Installation von PVE ist dann aber einfach mittendrin eingefroren.

Ein weiteres nerviges Problem ist, dass sich das Mainboard beim Neustart häufig mit einer neuen MAC-Adresse meldet und dadurch eine andere IP-Adresse vom DHCP-Server zugewiesen bekommt. Manchmal hilft es, das System noch einmal neu zu starten, um die ursprüngliche MAC-Adresse wieder zu erhalten, aber das ist natürlich keine Lösung.

Im Vergleich dazu hatte ich mit den IPMI/BMC-Interfaces von Supermicro solche Probleme nicht. Ist das bei euch auch so, oder mache ich irgendwas falsch ?
Hast du im IPMI unter "Network Settings" -> "Network Bond Configuration" die Einstellung auf "Shared" oder "Failover" stehen? Wenn ja switch mal auf "Dedicated" um. Dann wird nur noch der dedizierte IPMI Port verwendet.
Eventuell ist es nötig die Netzwerkkonfig zu aktualisieren, je nachdem wie das IPMI sich verhält.

Solltest du zuhause mit verschiedenen Netzen oder VLANs arbeiten, pass auf das das entsprechend richtige Kabel auf dem IPMI Port steckt.
 
Ein weiteres nerviges Problem ist, dass sich das Mainboard beim Neustart häufig mit einer neuen MAC-Adresse meldet und dadurch eine andere IP-Adresse vom DHCP-Server zugewiesen bekommt. Manchmal hilft es, das System noch einmal neu zu starten, um die ursprüngliche MAC-Adresse wieder zu erhalten, aber das ist natürlich keine Lösung.
Ich kaempfe selber ein bisschen mit der Konfiguration der beiden NICs im OpenBMC-Kernel und habe den starken Verdacht, dass es den Gigabyte-/AMI-Leuten mit der Stock-FW nie anders ging :d Ich kann mit ziemlicher Sicherheit sagen, dass die eine "shared" NIC (wo Host und BMC darueber sprechen koennen) via NC-SI angebunden ist, und die andere, dedicated BMC NIC (der Realtek-PHY) via RGMII, und die BMC-Stock-FW bondet die beiden Links in der Default Config einfach via mii-Link-Status aktiv/passiv.

Dummerweise hab ich bisher nur einen Device Tree hinbekommen, der unter Linux afaict optimal funktioniert, nicht aber unter u-boot (dem Bootloader, der auch via DHCP/TFTP booten koennen soll, meinem Plan nach). Ich glaube auch, dass die Stock-FW einen Bug beim Reset des BMC hat, wo der PHY-Link des NC-SI-Interfaces einige Male unnoetigerweise resetted wird. Jedenfalls hab ich beim Testen der Stock-Firmware einige Problemchen mit der Ethernet-Konnektivitaet immer beim Rebooten des BMC gehabt, wenn mich die Erinnerung nicht truegt.

Wenn irgendwann mal alles gut geht (kann ich leider nicht versprechen, shit is hard), sollte das zumindest mit OpenBMC kein Problem mehr sein - und vielleicht koennen und wollen ja auch Gigabyte/AMI was aendern, falls ihnen jemand die Loesung/korrekte Konfiguration auf einem Silbertablett serviert? :wink:
 
Meine optimistisch-naive Anfrage an den Gigabyte-Support ist soeben beantwortet worden:

We are sorry such information is classified which we are not allowed to answer in this system. For product-related information to the public, we already posted it on our official product page. If you found other hardware issues, please provide us your product serial number and detailed information about the problem you faced and we will see how to support you 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

Schade - und das an meinem Geburtstag! :') :d
 
Schade - und das an meinem Geburtstag! :') :d
Erstmal alles gute ;-)
Ich kaempfe selber ein bisschen mit der Konfiguration der beiden NICs im OpenBMC-Kernel und habe den starken Verdacht, dass es den Gigabyte-/AMI-Leuten mit der Stock-FW nie anders ging :d
Also seitens Gigabyte-BMC scheint das auch teilweise einfach kaputt zu sein. Hab das ganze als dedicated Managementport mit statischer IP eingerichtet, aber IPv6 funktioniert einfach nicht. (Hat das hier jemand anderes eig. mal versucht?)
Und wenn wir schon bei IPv6 sind: Was zur Hölle ist bitte ein "IPv6 Index" :ROFLMAO: Gleichzeitig fehlt aber natürlich die Einstellungsmöglichkeit für eine IPv6-Gateway-Adresse...
 
Im Prinzip spiegelt das so ein bisschen meine Erfahrung mit Gigabyte im Consumerbereich wieder. Ich hatte bei den X570-Boards bei Gigabyte auch immer das Gefühl, die haben selbst keine Ahnung, was sie da tun. 🙈 Immer wenn ein BIOS mit irgendeinem Fix kam, ging was anderes nicht, was aber schon mal funktioniert hat. Kleinigkeiten, aber wahnsinnig lästig.

@c0l0
Wenn du ein lauffähiges OpenBMC hast, tust den Jungs bei Gigabyte sicher einen Gefallen. Können sie mal schauen, wie's richtig geht. 🤣 Hast du dein Projekt auch ind en englischsprachigen Foren veröffentlicht? Eventuell findest du dort jemanden mit Kontakt zu Gigabyte oder AMI. Andererseits, wenn die OpenBMC-Jungs und -Mädels da schon nichts wissen... Der einzige, der mir aktuell in den Sinn käme, wäre Patrick Kennedy von ServeTheHome.com

Ich mein, fragen kostet nichts, außer ein bisschen Zeit für eine Mail.
 
btw der 5600 liegt wieder unter 100€ (inkl Versand solo unter 102)

und wer auf ECC verzichten kann bekommt 32GB 3200er ab 53€


komplette non ecc 1,2V Liste für 16/32GB Module: https://geizhals.de/?cat=ramddr3&xf...15903_keinSO~15903_ohnepuff~2506_1.2~254_3200
 
Zuletzt bearbeitet:
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