[Übersicht] Ultimative AM4 UEFI/BIOS/AGESA Übersicht

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Boost Override (max Werte Positiv/Negativ)
unknown.png
unknown.png


Vddg
unknown.png
unknown.png
 
Mod Bios läuft auch soweit...

@talha777
Siehe Bilder von @Owner5566

Telemetry ist etwas angepasst worden (im direkten Vergleich zum 1201er um 10A)
Ergo von 240A runter auf 213A (anstatt 203A) dann sind es fast genau 100% bei mir.

Tests stehen noch aus, aber das was ich bislang getestet habe ist nahezu unverändert zu besagtem 1201, mit Ausnahme der Telemetry.

Ob es stable ist wird sich die Tage zeigen. (RAM OC geht jedenfalls auch wieder nicht über 3800 bei mir, Board sagt nein!)
 
@Reous


Hier sind alle Files enthalten, habse auch runtergeladen.

Owner hat es für das unify X schon drauf, gibt ein paar nette Änderungen.
Vddg für jedes ccd einstellbar z.B. oder ein negativen Offset auf max Boost beim Boost override (-1000mhz)

Ich flashe gerade für das x570 unify ein Mod BIOS.
Welches Mod BIOS?
 
wird durch den Mod Bios mehr Leistung frei,wenn das so wäre,dann gerne ansonsten aber nicht.Denn wenn das Mod Bios instabil läuft dann ist das auch nicht so prickelnd.
 
Mod BIOS ist aus dem RAM OC discord, gemodded durch Boris (Eder ist dort auch vertreten und modded auch oft)

Und ja, je nach Einstellung kann man noch das ein oder andere % Leistung herausholen, da die hidden Settings freigeschaltet werden. (Advanced -> AMD CBS -> L2 Prefetcher z.B.)

Instabil ist es bislang nicht (aber sicher ist halt noch nichts, da der Testzeitraum zu kurz ist)
 
Ah ok man kann ja wohl alles Übertakten auch Cache. Ist ja wie ein Ram beim Arbeitsspeicher.Also sollte man schon einges herausholen können.
 
Kurzes Update:

BIOS lief nun die Nacht über, RAM OC ist mit identischen Settings immer noch stabil. (Karhu)
CPU hat minimal Leistung verloren bei mir (1-3%) und mehr Takt beim if geht auch immer noch nicht. (war aber zu erwarten)

TPM ist auch im vollem Umfang einstellbar und wie oben bereits erwähnt ein paar Änderungen an der Boost Mechanik.

Macht jedenfalls einen soliden Eindruck, anders als die bisherigen Versionen wo mir Fehler direkt aufgefallen sind.

"Eder" modded heute oder Sonntag dann die restlichen BIOS Versionen, das als kleiner Hinweis. (Für alle experimentier freudigen)
 
Zuletzt bearbeitet:
@Veii

Thanks for the info.
Have you compared the temperatures of B0 to B2? I am especially interested in the max CCD temperatures. Run the b2 cooler?
Ok i got everything now
It's, too early to judge
And it's unfair to judge

I know now clearly what causes WHEA's and it's "unfixable" in the current state ~ and AMD likely will never fix it by the behavior their moderation team shows. An engineers mistake on the boost system , coming from Matisse days where they hardlocked dynamic SOC, MCLK, FCLK. They forgot to stop FCLK from beeing dynamic and overdriving itself for retail samples, resulting in potential#19 & #20 WHEA's @ & after 1800 FCLK, but not crashes (if one CCD is loaded too lightly by core affinity)
Also that B2 wasn't much different than B0
It remains speculation if substrate runs the same that XT will be on
But it is more powerefficient

Downside, it's far higher overvolted (in the sense that it takes what it wants correctly, but doesn't work well with current boosting system and allowed ranges)
Soo this results in a far hotter CPU, 220-250W with an Alphacool Pro @ 2500RPM & KPx pegs at 90c on y-cruncher AVX2 (stock PBoost)
Thermal density is tighter, but there is zero information if this is 7nm or smaller.

Just again, unfair to compare a Bronze vs Platin sample (both B2)
I wouldn't go out of my way to sell B0 anymore just to play silicon lottery again
Here you can either strongly lose or big times win, but both CCDs being Silver/Bronze and questionably "usable" in the current bios state. Too much efford

Thats my conclusion
PSP & Security Flaws could've been fixed on HW level
Potentially substrate is different , but it doesn't matter because:
A.) 1205 is not out till likely mid/end december
B.) AMD will 98% never fix their DPM issues and just have it fixed on the XT lineup (hopefully)

It goes tomorrow back to the client, i've had enough fun with it
With Hydra its fine, but current PBO is just not usable. It needs at absolute least -60 CO to balance it "on stock" , else it sits at barely 4.5-4.55Ghz by voltage throttle via FIT
Not to think about modifying CPPC by changing fMAX - then maybe the requirements are ~ -80 to -90 CO

Thermal throttle is at 90c, unchangeable so far
It runs hotter and feels denser packed
Nothing special in access latency, nothing special in memOC
AMD did hold their words, but potentially it can be good with 1205 ~ we'll see

EDIT:
Soo if you want to buy one
Be prepared to big times lose in silicon lottery and either lapp it , as it is hotter than a 5950X B0
Also be prepared to depend on OC tools like Project Hydra , as PBO is not much usable in the current state & most of the AMD OVERCLOCKING menu doesn't respond/isn't applied
Else i wish you best of silicon lottery luck. So far it has shown that either you win , or you lose big times :)
My personal advice is, to not sell away a "gold" rated B0 sample from an older batch & wait for the community to finally fix these DPM issues (potentially possible now with a clear target)
* well or just wait for XT :)
 
Zuletzt bearbeitet:
Mein B550 Gaming Edge Wifi läuft immer noch mit 1.2.0.3b.
Never change a running system.
 
Mod BIOS ist aus dem RAM OC discord, gemodded durch Boris (Eder ist dort auch vertreten und modded auch oft)

Und ja, je nach Einstellung kann man noch das ein oder andere % Leistung herausholen, da die hidden Settings freigeschaltet werden. (Advanced -> AMD CBS -> L2 Prefetcher z.B.)

Instabil ist es bislang nicht (aber sicher ist halt noch nichts, da der Testzeitraum zu kurz ist)

Ich kann den RAM OC Discord nicht finden. Können Sie einen Freigabelink bereitstellen?
 
Ok i got everything now
It's, too early to judge
And it's unfair to judge

I know now clearly what causes WHEA's and it's "unfixable" in the current state ~ and AMD likely will never fix it by the behavior their moderation team shows. An engineers mistake on the boost system , coming from Matisse days where they hardlocked dynamic SOC, MCLK, FCLK. They forgot to stop FCLK from beeing dynamic and overdriving itself for retail samples, resulting in potential#19 & #20 WHEA's @ & after 1800 FCLK, but not crashes (if one CCD is loaded too lightly by core affinity)
Also that B2 wasn't much different than B0
It remains speculation if substrate runs the same that XT will be on
But it is more powerefficient

Downside, it's far higher overvolted (in the sense that it takes what it wants correctly, but doesn't work well with current boosting system and allowed ranges)
Soo this results in a far hotter CPU, 220-250W with an Alphacool Pro @ 2500RPM & KPx pegs at 90c on y-cruncher AVX2 (stock PBoost)
Thermal density is tighter, but there is zero information if this is 7nm or smaller.

Just again, unfair to compare a Bronze vs Platin sample (both B2)
I wouldn't go out of my way to sell B0 anymore just to play silicon lottery again
Here you can either strongly lose or big times win, but both CCDs being Silver/Bronze and questionably "usable" in the current bios state. Too much efford

Thats my conclusion
PSP & Security Flaws could've been fixed on HW level
Potentially substrate is different , but it doesn't matter because:
A.) 1205 is not out till likely mid/end december
B.) AMD will 98% never fix their DPM issues and just have it fixed on the XT lineup (hopefully)

It goes tomorrow back to the client, i've had enough fun with it
With Hydra its fine, but current PBO is just not usable. It needs at absolute least -60 CO to balance it "on stock" , else it sits at barely 4.5-4.55Ghz by voltage throttle via FIT
Not to think about modifying CPPC by changing fMAX - then maybe the requirements are ~ -80 to -90 CO

Thermal throttle is at 90c, unchangeable so far
It runs hotter and feels denser packed
Nothing special in access latency, nothing special in memOC
AMD did hold their words, but potentially it can be good with 1205 ~ we'll see

EDIT:
Soo if you want to buy one
Be prepared to big times lose in silicon lottery and either lapp it , as it is hotter than a 5950X B0
Also be prepared to depend on OC tools like Project Hydra , as PBO is not much usable in the current state & most of the AMD OVERCLOCKING menu doesn't respond/isn't applied
Else i wish you best of silicon lottery luck. So far it has shown that either you win , or you lose big times :)
My personal advice is, to not sell away a "gold" rated B0 sample from an older batch & wait for the community to finally fix these DPM issues (potentially possible now with a clear target)
* well or just wait for XT :)
Interesting. But how come that the APUs don’t have them. The Specs are so similar I assume the just copy pasted the cores. If they fix it for them wouldn’t they have fixed it for b2 as well?

Can you give us some context how reliable that info is?
 
Interesting. But how come that the APUs don’t have them. The Specs are so similar I assume the just copy pasted the cores. If they fix it for them wouldn’t they have fixed it for b2 as well?

Can you give us some context how reliable that info is?
It's "sample research in progress" in this state
There is still digging in progress to figure out what this toggle is actually called
Soo to see if it can be SMU disabled or it's deeper than userspace

They are remaings from the ABPDIS functionality - which where left alone
I feel the PBO X1-X10 ranges are also slightly broken (globally) but that's another topic

About "reliability" ~ there is no fix, to call it a news
The target/reason just got found, but not links to what feature does it
Just the problem part of it which is visible
Sadly also ZenPTMonitor Tool dev XPEHOPE, did not publish/release his tool in his github yet
Soo people need to dig and use pre-alpha releases to confirm their sample is not affected (well or just read whea log)

If the correct SMU value is found (the name of it)
Then we can forcefully annoy AMD , to finally fix their mess
So far , it's just an error found, without a resolve. No pressure can be made on a found error.
But yes, it's reliable about what actually does trigger it, just not the connection to it what triggers this overdrive
* as some units don't have this and where last minute patched.

EDIT ~ Followup,
Soo issue for FCLK_EFF high readout (boost)
Is CSTATE_BOOST triggering on Idle. Overdriving beyond set null-point
This behavior depends on the OS Scheduler (the amount of behavior)
Win11 in specific.
Performance mode under Ryzen Powerplan does boost on mousemovement specific. Balanced does only boost on idle
Battery Saver boosts correctly like Win 10, and doesn't also increase DPM LCLK beyond 593mhz

DPM LCLK limits "have to be" 770mhz peak" , this goes for RX Cards too
MorePowerTool_90xFHS57b5.png

But their 619 ~ 310-619 LCLK strap, is "problematic" - fixing it to 619-619, or rather 593-593 , removes the LCLK_EFF back and forth shuffling
AMD CBS does only allow to set DPM 1 = 300mhz , DPM 2, = 600mhz , but not DPM 3 = 770mhz, yet PCIe 4.0 cards try to reach this 700+ mhz
opera_dZdHgeAXcq.png

This can be fixed by fully disabling DPM LCLK , but you lose PPT throttle (i don't think anything bad so far).
On "fixed samples" you also lose THM tracking together with procHot - on our retail you just lose PPT but prochot and THM remains active
* or via Mailbox on boot, but load-balance is still active
~ disabling DPM LCLK removes part of the big problem from the equation fully

Active issue remains still that CSTATE_BOOST on idle overdrives, soo takes FCLK_EFF with it
Meaning up to how you set your sheduler & powerplan to behave ~ you will get these WHEA's by different "types" / "methods"
On stock, you get them always on low idle, and nothing on load
On Perf-Mode, you get nothing on idle, but it can overdrive on load ~ and so on
More to follow, maybe in another thread

But as Bios update information
RX users (with only one NVMe) can fixate the DPM link of their cards to 593-593 or 613-613 with MorePowerTool
~ and Win11 users put powermode to balanced powerplan with energy efficient target. That's "normal" and without random overdrive spikes
(this all includes the overboost bug that reaches 5500mhz and higher)
Soo expect DPM lv 3 support (maybe) ,
~ and if not - might want to lower RX cards DPM level down to 593-593, or 319-593 , else 594-770 if DPM 3 get's allowed via SMU/Mailbox finally/again
 
Zuletzt bearbeitet:
It's "sample research in progress" in this state
There is still digging in progress to figure out what this toggle is actually called
Soo to see if it can be SMU disabled or it's deeper than userspace

They are remaings from the ABPDIS functionality - which where left alone
I feel the PBO X1-X10 ranges are also slightly broken (globally) but that's another topic

About "reliability" ~ there is no fix, to call it a news
The target/reason just got found, but not links to what feature does it
Just the problem part of it which is visible
Sadly also ZenPTMonitor Tool dev XPEHOPE, did not publish/release his tool in his github yet
Soo people need to dig and use pre-alpha releases to confirm their sample is not affected (well or just read whea log)

If the correct SMU value is found (the name of it)
Then we can forcefully annoy AMD , to finally fix their mess
So far , it's just an error found, without a resolve. No pressure can be made on a found error.
But yes, it's reliable about what actually does trigger it, just not the connection to it what triggers this overdrive
* as some units don't have this and where last minute patched.

EDIT ~ Followup,
Soo issue for FCLK_EFF high readout (boost)
Is CSTATE_BOOST triggering on Idle. Overdriving beyond set null-point
This behavior depends on the OS Scheduler (the amount of behavior)
Win11 in specific.
Performance mode under Ryzen Powerplan does boost on mousemovement specific. Balanced does only boost on idle
Battery Saver boosts correctly like Win 10, and doesn't also increase DPM LCLK beyond 593mhz

DPM LCLK limits "have to be" 770mhz peak" , this goes for RX Cards too
Anhang anzeigen 699644
But their 619 ~ 310-619 LCLK strap, is "problematic" - fixing it to 619-619, or rather 593-593 , removes the LCLK_EFF back and forth shuffling
AMD CBS does only allow to set DPM 1 = 300mhz , DPM 2, = 600mhz , but not DPM 3 = 770mhz, yet PCIe 4.0 cards try to reach this 700+ mhz
Anhang anzeigen 699643
This can be fixed by fully disabling DPM LCLK , but you lose PPT throttle (i don't think anything bad so far).
On "fixed samples" you also lose THM tracking together with procHot - on our retail you just lose PPT but prochot and THM remains active
* or via Mailbox on boot, but load-balance is still active
~ disabling DPM LCLK removes part of the big problem from the equation fully

Active issue remains still that CSTATE_BOOST on idle overdrives, soo takes FCLK_EFF with it
Meaning up to how you set your sheduler & powerplan to behave ~ you will get these WHEA's by different "types" / "methods"
On stock, you get them always on low idle, and nothing on load
On Perf-Mode, you get nothing on idle, but it can overdrive on load ~ and so on
More to follow, maybe in another thread

But as Bios update information
RX users (with only one NVMe) can fixate the DPM link of their cards to 593-593 or 613-613 with MorePowerTool
~ and Win11 users put powermode to balanced powerplan with energy efficient target. That's "normal" and without random overdrive spikes
(this all includes the overboost bug that reaches 5500mhz and higher)
Soo expect DPM lv 3 support (maybe) ,
~ and if not - might want to lower RX cards DPM level down to 593-593, or 319-593 , else 594-770 if DPM 3 get's allowed via SMU/Mailbox finally/again
Thanks for dropping so much wisdom, do you mind if this finds it‘s way into the whea 19 discussion thread on overclock.net?
 
Gigabyte hat wegen der Sicherheitslücke und Win11 auch bei deren 300er Chipsets neue BIOSe veröffentlicht.

zB F51c für das GA-AB350N WiFi

Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.
Credits to "Assaf Carlsbad and Itai Liba from SentinelOne"
• Introduce capsule BIOS support starting this version.
  1. Change default status of AMD PSP fTPM to Enabled for addressing basic Windows 11 requirements

Leider keine neuere AGESA dabei. :cry:



Infos zu der Sicherheitslücke

 
Zuletzt bearbeitet:
Major vulnerabilities updates, customers are strongly encouraged to update to this release at the earliest.
Credits to "Assaf Carlsbad and Itai Liba from SentinelOne"
• Introduce capsule BIOS support starting this version.
If security vulnerabilities would be fixed ~ in this case "SMU RACE" then it also introduced ROM ARMOR
I can not out of clear mind say, downgrade back would be possible after the flash / up to how gigabyte implemented default flags
But it' s a good step forward for security ~ up to on which side you stay
* ASRock allowed downgrade on the introduction of SPI ARMOR ✅, ASUS did not on boards without ext-flashback ❌

Sadly this side missunderstood
Some people think having unrestricted writes to SPI flash is OK:
As demand to allowing targets via userspace to excecute and rewrite ROM
While the target was not OS userspace, but also not being restricted fully without ability to unlock and with NDA requirement to even get the information for self repair or modification

Slight difference of viewpoints, but hard to title correct judgement ~ when there was no attempt of talkpoint. Easy to blame people over the net :)
Anyway ~ keep in mind this might lock SetupVar access, might lock downgrading ability (up to vendor) and can render crossflashed boards as soft-bricks by the nature of it.
Not that it was introduced with malicious attempts as here quoted
opera_OfbdTSl89l.png

But in the sense, that it very likely ~ can cause you modification "complications", away from any Vendors intentions
I do think that changelogs should state the introduction of SPI ARMOR, when "the cat has already left bag."

The only part i'm personally not happy with,
Is being "read only" after post ~ by Vendors supplying (AMD) decision, without the ability to rewrite it (in case you need to update/downgrade) & in such case "service" boards
And the 2nd sideeffect that ROM-Armor toggle is wiped from SB as option. Soo it indeed falls under "enforcement" and not "choice" as Mr. Pikhur states
It's not a choice we get ~ which is why i understand the reddit guy, but he phrased it wrongly (likely)

Corresponding Vendors are to blame, not the feature itself.
But the feature by AMD is used not as a "choice" option ~ and then "shut-up" the information about it, even when it's "supposed to be no security risk anymore"
I understand where The Stilt is coming from and we could talk nicely ~ but i don't think i can agree with both points. Neither the reddit guy, nor The Stilt's response on this thread
Comparing an issue for intel boards which can require user to go as far as short pins to follow an undocumented mode ~ "just to gain the ability to downgrade or service"
Vs actually having a choice to select it ~ as Mr. Pikhur & the SentinelOne Team probably had as intention.

There is a difference of enforcement here. Soo reddit user titling it "malicious" has some ground ~ but it's not "the feature/fix" that is the problem here.
It's the Vendors implementation and followups by it without being made aware, nor have the ability to talk about it or get a choice to toggle it
Very easy taken out of context 🤭
do you mind if this finds it‘s way into the whea 19 discussion thread on overclock.net?
I'm already crosslinking forums on important updates. Don't worry
So far it's not important enough, to copy-paste it through threads
I can not out of clear mind say, downgrade back would be possible after the flash
Please add this warning as * under the F51c file
* downgrade might be restricted after update

really up to which side Gigabyte choose to follow , enforcement or choice :)
ARMOR surely is "enforced" , but the ability to downgrade and service ~ will be an ODM made choice

EDIT:
GmdvgZbq66V4_opera_sC12MyOfMg.png

^ was patched for consumer after 1.1.0.0 Patch-D , on beta bioses that where taken down recently
Soo 1.1.8.X and higher already have this "patch" implemented, just wasn't on hardware level

Since end of March/April AMD should've known about DPM issues, and other issues & exploits. They should've also clearly known about WHEA #19,#20 errors , but it didn't make it into Rev.02 release ~2 months later
It's a silenced issue ~ don't try to ask about APBDIS and Dynamic FCLK, else the talking person in question will quit the talk with you
In general, don't mention ~anything dynamic~ since Matisse days. It's an unliked topic :geek:
 
Zuletzt bearbeitet:
Guten Abend zusammen,

ich verfolge diesen Thread jetzt schon ein Paar Jahre und wollte mich jetzt auch mal zu Wort melden, genauergesagt eher eine Frage stellen :LOL:

Es geht um die aktuelleren UEFI/BIOS Versionen und deren AGESA Codes meines ASUS C7H
Bisher fahre ich mit der AGESA ComboPI AM4 1.0.0.6 (UEFI Version 3103) ganz gut mit einem Ryzen 7 1700 auf 4GHz OC bei 1.375v.
Wie ich bisher beobachten konnte, kann die CPU bzw der RAM je nach UEFI Version mit mehr oder weniger Spannung/Taktraten laufen.
Geblieben bin ich jetzt erstmal bei der 3103.

Nun frage Ich in die Runde, ob jemand neuere UEFIs mit einer 1st Gen Ryzen CPU schon getestet hat und Vor - oder Nachteile feststellen konnte.
Ich habe bereits mit dem Ryzen SMU Checker die einzelnen SMUs der Nachfolge Versionen des BIOS einmal durchgecheckt und habe festgestellt, dass sich bei Summit Ridge nichts mehr tut.

Haben die neueren bzw zukünftigen UEFIs einen Vorteil, gar überhaupt einen Sinn auf Ryzen 1000 ?
 
Haben die neueren bzw zukünftigen UEFIs einen Vorteil, gar überhaupt einen Sinn auf Ryzen 1000 ?
Ich habe bereits mit dem Ryzen SMU Checker die einzelnen SMUs der Nachfolge Versionen des BIOS einmal durchgecheckt und habe festgestellt, dass sich bei Summit Ridge nichts mehr tut.
Bis auf allgemeine Fehlerkorrekturen wird sich da nix mehr tun. Warum sollte AMD an ZEN1 rumbasteln, wenn sich vorher schon keine großen Probleme mehr gezeigt haben.
Ein Bios Update ist keine Pflicht, nur eine Option zur Verbesserung bei großen Problemen.
Nur wenn du mal neuere CPUs einsetzen solltest, würde ich vorab nen Bios Update machen, denn sonst gerät man schnell in die Falle, wenn dann keine ältere CPU mehr vorhanden ist.

Wenn sich nicht irgendetwas wie Spectre, Meltdown o.ä. und eine gewisse Anfälligkeit bei Zen1 zeigt, wird AMD wohl nix mehr dort ändern.
Das wäre für mich der einzige Grund, den AMD noch für Änderungen hätte.
 
Zuletzt bearbeitet:
Bis auf allgemeine Fehlerkorrekturen wird sich da nix mehr tun. Warum sollte AMD an ZEN1 rumbasteln, wenn sich vorher schon keine großen Probleme mehr gezeigt haben.
Ein Bios Update ist keine Pflicht, nur eine Option zur Verbesserung bei großen Problemen.
Nur wenn du mal neuere CPUs einsetzen solltest, würde ich vorab nen Bios Update machen, denn sonst gerät man schnell in die Falle, wenn dann keine ältere CPU mehr vorhanden ist.

Wenn sich nicht irgendetwas wie Spectre, Meltdown o.ä. und eine gewisse Anfälligkeit bei Zen1 zeigt, wird AMD wohl nix mehr dort ändern.
Das wäre für mich der einzige Grund, den AMD noch für Änderungen hätte.
Okay danke schonmal dafür.
Dann kann ich ja erstmal auf dieser Version bleiben, bis ich mir einen neuen Ryzen hole
 
Bis auf allgemeine Fehlerkorrekturen wird sich da nix mehr tun. Warum sollte AMD an ZEN1 rumbasteln, wenn sich vorher schon keine großen Probleme mehr gezeigt haben.
Ein Bios Update ist keine Pflicht, nur eine Option zur Verbesserung bei großen Problemen.
Nur wenn du mal neuere CPUs einsetzen solltest, würde ich vorab nen Bios Update machen, denn sonst gerät man schnell in die Falle, wenn dann keine ältere CPU mehr vorhanden ist.

Wenn sich nicht irgendetwas wie Spectre, Meltdown o.ä. und eine gewisse Anfälligkeit bei Zen1 zeigt, wird AMD wohl nix mehr dort ändern.
Das wäre für mich der einzige Grund, den AMD noch für Änderungen hätte.
Wenn es für Zen1 neue SMU Versionen gibt sollten die Optimierungen auch da greifen.
 
Wollte gerade mal nach neuen BIOS Updates schauen und als ich die MSI Webseite aufgerufen habe, die englische und nicht die deutsche, kam dieses hier:

1639387259162.png


Da ist wohl was schief gelaufen oder die sind am Umstellen.
 
da will doch nicht jdm die Leute zwingen übers Dragon Center zu gehen? :unsure:
 
Also jetzt geht die Seite wieder aber sehr langsam und wie es aussieht nichts neues.
Das hat doch nicht vielleicht mit dieser Meldung zu tun?
Nicht das jetzt vor den Feiertagen da Böse Buben böses planen.

 

MSI Rolls Out AMD AGESA 1.2.0.5 BETA BIOS Firmware To X570 & B550 Motherboards


What's new:
1. Update to COMBOAM4v2PI 1.2.0.5
2. SMU firmware updated for AMD Vermeer, Cezanne, Picasso, Raven Ridge
3. TPM enabled by default


MSI-AMD-AGESA-1.2.0.5-BETA-BIOS-Firmware-For-X570-B550-Motherboards.png
 
Bin auf erste Erfahrungen gespannt obs stabiler läuft wie 1.2.0.4 A und wann da mal von Gigabyte was kommt.
 
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