News AMD AGESA Combo-AM4 1.0.0.3abb entfernt PCI-Express 4.0 Support für ältere Chipsätze

pipin

Administrator
Teammitglied
★ Themenstarter ★
Mitglied seit
16.10.2000
Beiträge
23.503
Renomée
9.222
Standort
East Fishkill, Minga, Xanten
  • SIMAP Race
  • QMC Race
  • RCN Russia
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2019
  • SETI@Home Intel-Race II
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
Was sich bereits im Vorfeld abgezeichnet hatte, wurde nun von AMD mittels des AGESA Combo-AM4 1.0.0.3abb umgesetzt. Ab diesem AGESA-Code wird laut Gigabyte der PCI-Express 4.0 Support auf älteren Chipsätzen entfernt. Entsprechende Einträge lassen sich bei neuen BIOS-Versionen von Gigabyte finden.
(…)

» Artikel lesen
 

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
5.043
Renomée
166
War abzusehen. Trotzdem schade, hätte gehofft, dass man die Entscheidung den MB Herstellern überlässt.

Mal schauen, evtl. kommt es irgendwann, wenn X570 "etabliert" ist, auch wieder zurück?
Unwahrscheinlich, aber nicht unmöglich.
 

Inxession

Commander
Mitglied seit
12.11.2013
Beiträge
192
Renomée
7
Wenn es im AGESA ist, wirds übergreifend alle Chipsätze treffen außer X570.

Schon möglich das man es im Nachhinein wieder zulässt.

Siehe Win7 Support bei Ryzen 2xxx oder den Unlock des Athlon 200
 

Linuxhippy

Lieutnant
Mitglied seit
31.07.2008
Beiträge
53
Renomée
3
Schade, derartiges Verhalten gegenüber Kunden bin ich bisher eigentlich nur von Intel gewohnt.
Aber wie dem so ist ... mit dem Erfolg wächst auch die Gier.
 

Oi!Olli

Grand Admiral Special
Mitglied seit
24.12.2006
Beiträge
16.172
Renomée
639
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2019
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
Giagbyte hat schon neue Updates. Asrock noch nicht.
 

Helle53

Lt. Commander
Mitglied seit
16.12.2011
Beiträge
122
Renomée
13
Was mich interessiert: Funktioniert denn nun damit RDRAND/RDSEED? Systemd sowie Programme/Spiele werden sicher vor Verwendung von RDRAND über CPUID die Verfügbarkeit testen. Das als negativ zu vermelden ist ja nun kein Problem...
Für Interessierte ein ASM-Test-Code:
Code:
;Für Windows 64-Bit!
;Von `flatassembler.net` die aktuelle Windows-Version herunterladen und entpacken (keine Installation erforderlich!).
;Für dieses Beispiel wurde auf Laufwerk C: dafür der Ordner FASM angelegt; ist aber beliebig.
;FASMW.EXE starten und diesen Code einfügen, den include-Pfad evtl. anpassen und über Run starten

format PE64 CONSOLE 4.0
entry start 

include 'C:\FASM\INCLUDE\WIN64A.INC'   ;Pfad anpassen, wenn woanders hinkopiert!

section '.code' code readable writeable executable
         ZufZahl dq  ?
         Zaehler dq  1
         Versuch dq  0
         string1 db '. gelieferte Zufalls-Zahl: ',0
         string2 db 'benoetigte Versuche: ',0
         string3 db 'CPUID: RDRAND nicht verfuegbar!',0
         szEnv1  db '%3u%s %21llu   %s %2u',13,10,0
         szEnv2  db '%s',13,10,0

start:
     mov eax,1
     cpuid
     test ecx,40000000h ;Bit30
     jnz @f             ;CPU kann RDRAND, also weiter
     invoke printf, szEnv2, string3
     jmp Ende
@@:
     xor rcx,rcx
@@:
     ;cmp rcx,XX         ;XX meinetwegen 10
     ;je Ende            ;oder sonstwas
     inc rcx
     rdrand rax
     ;rdseed rax         ;dann als ordentliches Kerlchen vorher CPUID drauf testen
     jnc @b             ;Carry-Flag=0: CPU meldet, keine gültige Zufalls-Zahl generiert -> nächster Versuch
     mov qword[ZufZahl],rax
     mov qword[Versuch],rcx
     invoke printf, szEnv1, qword[Zaehler], string1, qword[ZufZahl], string2, qword[Versuch]
     xor rcx,rcx
     inc [Zaehler]
     cmp [Zaehler],250  ;wegen begrenzter (Standard-) Konsolen-Anzeige (Win7), es sei denn, man legt Hand an
     jbe @b
Ende:
     invoke getchar     ;warten auf Tasten-Druck
     invoke ExitProcess,0 

section '.idata' import data readable
  library kernel32,'kernel32.dll',\
          msvcrt,'msvcrt.dll'   
  import kernel32,\
         ExitProcess,'ExitProcess'   
  import msvcrt,\
         getchar,'getchar',\   
         printf,'printf'
 

Stefan Payne

Grand Admiral Special
Mitglied seit
17.11.2001
Beiträge
5.551
Renomée
50
Mal schauen, evtl. kommt es irgendwann, wenn X570 "etabliert" ist, auch wieder zurück?
Unwahrscheinlich, aber nicht unmöglich.
Nein, schau dir mal die PCie 4.0 Support Tabellen an.

Wenn ein 250-300€ ASUS Board kein PCIe 4.0 unterstützt, die 60€ Klitsche aber schon, ist das schon richtig blöd.
Und genau darum wird man sich dagegen entschieden haben.
 

derDruide

Grand Admiral Special
Mitglied seit
09.08.2004
Beiträge
2.098
Renomée
132
Schade, derartiges Verhalten gegenüber Kunden bin ich bisher eigentlich nur von Intel gewohnt.
Aber wie dem so ist ... mit dem Erfolg wächst auch die Gier.

Ist ja total gierig, wenn man Probleme beim Kunden vermeidet und sich damit NICHT seinen Ruf versauen will. Solche Billig-Boards waren nie dafür gedacht.
 

Flodul

Commander
Mitglied seit
14.12.2016
Beiträge
164
Renomée
1
Was mich interessiert: Funktioniert denn nun damit RDRAND/RDSEED? Systemd sowie Programme/Spiele werden sicher vor Verwendung von RDRAND über CPUID die Verfügbarkeit testen. Das als negativ zu vermelden ist ja nun kein Problem...
Für Interessierte ein ASM-Test-Code:
Code:
;Für Windows 64-Bit!
;Von `flatassembler.net` die aktuelle Windows-Version herunterladen und entpacken (keine Installation erforderlich!).
;Für dieses Beispiel wurde auf Laufwerk C: dafür der Ordner FASM angelegt; ist aber beliebig.
;FASMW.EXE starten und diesen Code einfügen, den include-Pfad evtl. anpassen und über Run starten

format PE64 CONSOLE 4.0
entry start 

include 'C:\FASM\INCLUDE\WIN64A.INC'   ;Pfad anpassen, wenn woanders hinkopiert!

section '.code' code readable writeable executable
         ZufZahl dq  ?
         Zaehler dq  1
         Versuch dq  0
         string1 db '. gelieferte Zufalls-Zahl: ',0
         string2 db 'benoetigte Versuche: ',0
         string3 db 'CPUID: RDRAND nicht verfuegbar!',0
         szEnv1  db '%3u%s %21llu   %s %2u',13,10,0
         szEnv2  db '%s',13,10,0

start:
     mov eax,1
     cpuid
     test ecx,40000000h ;Bit30
     jnz @f             ;CPU kann RDRAND, also weiter
     invoke printf, szEnv2, string3
     jmp Ende
@@:
     xor rcx,rcx
@@:
     ;cmp rcx,XX         ;XX meinetwegen 10
     ;je Ende            ;oder sonstwas
     inc rcx
     rdrand rax
     ;rdseed rax         ;dann als ordentliches Kerlchen vorher CPUID drauf testen
     jnc @b             ;Carry-Flag=0: CPU meldet, keine gültige Zufalls-Zahl generiert -> nächster Versuch
     mov qword[ZufZahl],rax
     mov qword[Versuch],rcx
     invoke printf, szEnv1, qword[Zaehler], string1, qword[ZufZahl], string2, qword[Versuch]
     xor rcx,rcx
     inc [Zaehler]
     cmp [Zaehler],250  ;wegen begrenzter (Standard-) Konsolen-Anzeige (Win7), es sei denn, man legt Hand an
     jbe @b
Ende:
     invoke getchar     ;warten auf Tasten-Druck
     invoke ExitProcess,0 

section '.idata' import data readable
  library kernel32,'kernel32.dll',\
          msvcrt,'msvcrt.dll'   
  import kernel32,\
         ExitProcess,'ExitProcess'   
  import msvcrt,\
         getchar,'getchar',\   
         printf,'printf'

Naja, so einfach ist das nicht.
Die Sache ist, dass der 3xxx Ryzen ja bei RDRAND spackt wenn er aus irgendeinem Schlafmodus aufwacht. Und Du lässt ihn ja durchgehend rechnen, dass es erst gar nicht zu dieser Situation kommt.
Außerdem kann man das auch schmerzfreier in C mit Intrinsics implementieren (_rdrand64_step()).

Aber mal grundsätzlich zum Thema: PCIe 3.0 bringt schon ggü. PCIe 2.0 bei Grafikkarten kaum Gewinn. Und für Desktop-Nutzer gibt es sicher kaum Anwendungsfälle wo eine PCIe 4.0 SSD mit 7GB/s merkbar schneller ist als eine 3.0er. Von daher kann einem das egal sein.
 
Zuletzt bearbeitet:

Cross-Flow

Grand Admiral Special
Mitglied seit
31.10.2004
Beiträge
2.403
Renomée
24
Standort
29614
Ich finde das grade extrem geil was Gigabyte gemacht hat. Bei meinen Stichproben ist ja durch die Bank weg 1003ABB in den Biosen angekommen, egal welcher Chipsatz.

Dafür das viele am Anfang der AM4 Zeit Gigabyte so massiv auseiner genommen haben weil neue Bios Versionen auf sich warten ließen geben sie nun richtig gas! Sehr schön :)

Asus hinkt wie immer hinterher, ASRock dieses mal leider auch.
 

Yoshi 2k3

Admiral Special
Mitglied seit
18.01.2003
Beiträge
1.286
Renomée
154
Dafür das viele am Anfang der AM4 Zeit Gigabyte so massiv auseiner genommen haben weil neue Bios Versionen auf sich warten ließen geben sie nun richtig gas! Sehr schön :)
Das stimmt, ich habe Gigabyte ja auch kritisiert (und tue das bei der X399 Plattform noch immer!), aber aktuell gibt es nix zu meckern, auch für die älteren Boards nicht. Updates werden zeitnah umgesetzt. Aus diesem Grund hab ich mir tatsächlich ein X470 Aorus Gaming 7 zugelegt, als Basis für meinen 3700X. Das wäre, sagen wir vor einem Jahr, für mich undenkbar gewesen.
 

Oi!Olli

Grand Admiral Special
Mitglied seit
24.12.2006
Beiträge
16.172
Renomée
639
  • BOINC Pentathlon 2011
  • BOINC Pentathlon 2017
  • BOINC Pentathlon 2019
  • THOR Challenge 2020
  • BOINC Pentathlon 2021

Casi030

Grand Admiral Special
Mitglied seit
03.10.2012
Beiträge
8.942
Renomée
153
Ich finde das grade extrem geil was Gigabyte gemacht hat. Bei meinen Stichproben ist ja durch die Bank weg 1003ABB in den Biosen angekommen, egal welcher Chipsatz.



Asus hinkt wie immer hinterher....

Dafür läuft das 1002 beim ASUS sehr Sauber zu mindestens beim x370 und dem R5 3600.Ram laufen auch sehr gut,also leicht und schnell zu Optimieren....Warum also schnell schnell Müll raus hauen.....
Auch hab ich zwischen dem R5 1400 und dem R5 3600 im Idle nen Unterschied von rund 2-3Watt unter Win7 , leider mit höherem Idletakt.
 
Zuletzt bearbeitet:
Oben Unten