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

[pipin]

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]

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.

 

[deoroller]

Beim A320 ist es nicht tragisch. Das Mainboard wird wohl keiner für einen Highend PC verbaut haben.

 

[Inxession]

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]

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.

 

[cruger]

Aber wie dem so ist ... mit dem Erfolg wächst auch die Gier.

inwiefern? erklär mal.

 

[Oi!Olli]

Giagbyte hat schon neue Updates. Asrock noch nicht.

 

[Helle53]

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:

;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]

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]

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]

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:

;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.

 

[Cross-Flow]

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]

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]

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

Asrock braucht zwar lange, dafür sind die Updates aber ziemlich verbuggt.

 

[Casi030]

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.