Heisst, damit kann man einen oberen Grenzwert für das normale Core Performance Boost setzen ?
[Übersicht] Ultimative AM4 UEFI/BIOS/AGESA Übersicht
- Ersteller Reous
- Erstellt am
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!)
@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!)
Scoty
Urgestein
Welches Mod BIOS?@Reous
AGESA 1205 – Google Drive
drive.google.com
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.
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)
Ace - > https://cdn.discordapp.com/attachments/578340164187979796/916413943927427102/MEG_X570_ACE-1G5.zip
B550 Unify-X -> https://cdn.discordapp.com/attachments/578340164187979796/916409170360676402/B550UNIFY-XA45.zip
X570 Unify -> https://cdn.discordapp.com/attachments/578340164187979796/916410845972561950/X570UNIFYAB4.zip
B550 Unify-X -> https://cdn.discordapp.com/attachments/578340164187979796/916409170360676402/B550UNIFY-XA45.zip
X570 Unify -> https://cdn.discordapp.com/attachments/578340164187979796/916410845972561950/X570UNIFYAB4.zip
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)
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)
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:
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:
zrxGhost
Enthusiast
- Mitglied seit
- 12.04.2006
- Beiträge
- 279
I couldn't care less.
Ist hier ähnlich. Noch stabiler kann es nicht laufen.
Ich kann den RAM OC Discord nicht finden. Können Sie einen Freigabelink bereitstellen?
@KedarWolf
discord.com
Discord - Group Chat That’s All Fun & Games
Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
@KedarWolf
Discord - Group Chat That’s All Fun & Games
Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
Dankeschön.
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?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
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
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
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
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:
Thanks for dropping so much wisdom, do you mind if this finds it‘s way into the whea 19 discussion thread on overclock.net?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
Gigabyte hat wegen der Sicherheitslücke und Win11 auch bei deren 300er Chipsets neue BIOSe veröffentlicht.
www.gigabyte.com
zB F51c für das GA-AB350N WiFi
www.gigabyte.com
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.
Leider keine neuere AGESA dabei.
Infos zu der Sicherheitslücke
AMD Socket AM4 | Motherboard - GIGABYTE Global
Lasting Quality from GIGABYTE.GIGABYTE Ultra Durable™ motherboards bring together a unique blend of features and technologies that offer users the absolute ...
zB F51c für das GA-AB350N WiFi
GA-AB350N-Gaming WIFI (rev. 1.0) Support | Motherboard - GIGABYTE Global
Lasting Quality from GIGABYTE.GIGABYTE Ultra Durable™ motherboards bring together a unique blend of features and technologies that offer users the absolute ...
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.
- Change default status of AMD PSP fTPM to Enabled for addressing basic Windows 11 requirements
Leider keine neuere AGESA dabei.
Infos zu der Sicherheitslücke
Zuletzt bearbeitet:
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
As demand to allowing targets via userspace to excecute and rewrite ROMSome people think having unrestricted writes to SPI flash is OK:
AGESA FW stack patched bioses for 3rd gen
www.overclock.net
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
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 🤭
I'm already crosslinking forums on important updates. Don't worry
So far it's not important enough, to copy-paste it through threads
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:
^ 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
Zuletzt bearbeitet:
S
shoux
Guest
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
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 ?
ich verfolge diesen Thread jetzt schon ein Paar Jahre und wollte mich jetzt auch mal zu Wort melden, genauergesagt eher eine Frage stellen
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 ?
Strikeeagle1977
Enthusiast
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:
S
shoux
Guest
Okay danke schonmal dafür.
Dann kann ich ja erstmal auf dieser Version bleiben, bis ich mir einen neuen Ryzen hole
Wenn es für Zen1 neue SMU Versionen gibt sollten die Optimierungen auch da greifen.
Gamer1969
Enthusiast
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:
Da ist wohl was schief gelaufen oder die sind am Umstellen.
Da ist wohl was schief gelaufen oder die sind am Umstellen.
Kann ich so bestätigen.
Strikeeagle1977
Enthusiast
da will doch nicht jdm die Leute zwingen übers Dragon Center zu gehen?
Gamer1969
Enthusiast
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.
www.n-tv.de
Das hat doch nicht vielleicht mit dieser Meldung zu tun?
Nicht das jetzt vor den Feiertagen da Böse Buben böses planen.
Software-Sicherheitslücke alarmiert Bundesamt
Die meisten Internetnutzer bekommen nicht mit, dass sich derzeit im Hintergrund ein Wettrennen abspielt. Es geht um eine frisch entdeckte Software-Sicherheitslücke, die viele Server bedrohen soll. Online-Kriminelle suchen nach dem Einfallstor, IT-Experten nach der Lösung.
www.n-tv.de
MSI Rolls Out AMD AGESA 1.2.0.5 BETA BIOS Firmware To X570 & B550 Motherboards
MSI Rolls Out AMD AGESA 1.2.0.5 BETA BIOS Update For X570 & B550 Motherboards
MSI has started rolling out the first X570 & B550 motherboard BIOS based on the latest AMD AGESA 1.2.0.5 BETA Firmware.
wccftech.com
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
