Friday, April 19th 2024

ASUS AMD 600 Series Motherboards Now Support Next-Gen Ryzen Processors

ASUS today announced BIOS updates enabling support for next-gen AMD Ryzen processors on ASUS AM5 X670, B650 and A620 motherboards, as well as support for existing Ryzen 7000 and 8000 series processors. These updates are necessary to enable compatibility with these processors. BIOS updates for ASUS AM5 motherboards also add support for existing Ryzen 7000 and 8000 series processor.

The updates can be accessed on the ASUS BIOS update page for the models listed below.
  • ROG ROG CROSSHAIR X670E EXTREME
  • ROG CROSSHAIR X670E HERO
  • ROG CROSSHAIR X670E GENE
  • ROG STRIX ROG STRIX X670E-E GAMING WIFI
  • ROG STRIX X670E-F GAMING WIFI
  • ROG STRIX X670E-A GAMING WIFI
  • ROG STRIX X670E-I GAMING WIFI
  • ROG STRIX B650E-E GAMING WIFI
  • ROG STRIX B650E-F GAMING WIFI
  • ROG STRIX B650-A GAMING WIFI
  • ROG STRIX B650E-I GAMING WIFI
  • TUF GAMING TUF GAMING X670E-PLUS WIFI
  • TUF GAMING X670E-PLUS
  • TUF GAMING B650-PLUS WIFI
  • TUF GAMING B650-PLUS
  • TUF GAMING B650-E WIFI
  • TUF GAMING B650M-PLUS WIFI
  • TUF GAMING B650M-PLUS
  • TUF GAMING B650M-E WIFI
  • TUF GAMING B650M-E
  • TUF GAMING A620-PRO WIFI
  • TUF GAMING A620M-PLUS WIFI
  • TUF GAMING A620M-PLUS
  • ProArt ProArt X670E-CREATOR WIFI
  • ProArt B650-CREATOR
  • PRIME PRIME X670E-PRO WIFI
  • PRIME X670-P WIFI
  • PRIME X670-P
  • PRIME B650-PLUS
  • PRIME B650M-A WIFI II
  • PRIME B650M-A WIFI
  • PRIME B650M-A II
  • PRIME B650M-A
  • PRIME B650M-A AX II
  • PRIME B650M-A AX6
  • PRIME B650M-A AX
  • PRIME B650M-K
  • PRIME B650M-R
  • PRIME A620-PLUS WIFI
  • PRIME A620M-A
  • PRIME A620M-E
  • PRIME A620M-K
  • EX EX-B650M-V7
  • AYW A620M-AYW WIFI
Source: ASUS
Add your own comment

22 Comments on ASUS AMD 600 Series Motherboards Now Support Next-Gen Ryzen Processors

#1
bobsled
For those who dare :laugh:
Posted on Reply
#2
AsRock
TPU addict
bobsledFor those who dare :laugh:
?
Posted on Reply
#3
bobsled
AsRock?
This is the stupid tagline that Asus plastered on the Crosshair Hero board, and then had the huge PR issue due to severely overvolting the CPUs when DOCP/XMP was enabled as a standard profile option. It also failed to turn off the system when a CPU was killed, leaving you with a fire or cooked motherboard as well.

The recommended option was to flash a beta BIOS, which then wasn’t supported under warranty. Absolute dumpster fire of incident response.
Posted on Reply
#4
AsRock
TPU addict
bobsledThis is the stupid tagline that Asus plastered on the Crosshair Hero board, and then had the huge PR issue due to severely overvolting the CPUs when DOCP/XMP was enabled as a standard profile option. It also failed to turn off the system when a CPU was killed, leaving you with a fire or cooked motherboard as well.

The recommended option was to flash a beta BIOS, which then wasn’t supported under warranty. Absolute dumpster fire of incident response.
:(

Well you should of said. ASUS changed beta bios limitation soon after they did it.
Posted on Reply
#5
Dr. Dro
bobsledThis is the stupid tagline that Asus plastered on the Crosshair Hero board, and then had the huge PR issue due to severely overvolting the CPUs when DOCP/XMP was enabled as a standard profile option. It also failed to turn off the system when a CPU was killed, leaving you with a fire or cooked motherboard as well.

The recommended option was to flash a beta BIOS, which then wasn’t supported under warranty. Absolute dumpster fire of incident response.
That's been the ROG tagline for years. CPUs cooking were largely AMD's fault too. And ASUS ultimately owned up to that mistake. No harm done, great to see timely updates IMO
Posted on Reply
#6
Hxx
Dr. DroThat's been the ROG tagline for years. CPUs cooking were largely AMD's fault too. And ASUS ultimately owned up to that mistake. No harm done, great to see timely updates IMO
It was largely the board makers fault not AMD. There was no fault in the chips design. Board makers need to spend more than 1/10 of a second testing bios versions but they don’t they let you the consumer do the job for them . Simple as that
Posted on Reply
#7
Dr. Dro
HxxIt was largely the board makers fault not AMD. There was no fault in the chips design. Board makers need to spend more than 1/10 of a second testing bios versions but they don’t they let you the consumer do the job for them . Simple as that
No fault in the chip design, however, the AGESA code was faulty - and that was exclusively an AMD problem. "Simple as that".
Posted on Reply
#8
Hxx
Dr. DroNo fault in the chip design, however, the AGESA code was faulty - and that was exclusively an AMD problem. "Simple as that".
First off agesa is part of your bios not the entire bios . Second these chips were getting cooked with default settings on certain boards not all so clearly there was no testing done by certain AIBs. Sure AMD release an updated agesa code to permanently fix this issue but saying it’s largely AMDs fault is like blaming AMD or Intel for bad overclocking results . Simply put it was not largely AMDs fault.
Posted on Reply
#9
Dr. Dro
HxxFirst off agesa is part of your bios not the entire bios . Second these chips were getting cooked with default settings on certain boards not all so clearly there was no testing done by certain AIBs. Sure AMD release an updated agesa code to permanently fix this issue but saying it’s largely AMDs fault is like blaming AMD or Intel for bad overclocking results . Simply put it was not largely AMDs fault.
You've got it wrong, AGESA is part of BIOS, but a part that only AMD has the source code to. It's identical in every implementation because it's a closed-source blob. This is the low-level firmware code responsible for the initialization of the processor and many of its low-level functions, including the emulation of certain instructions that are not natively present in the hardware. It's been an achilles heel for them for some time, and they're aware of it, which is why it'll be open sourced beginning with the next platform (it'll become AMD openSIL, look it up).

AMD has released fixed AGESA code and all motherboard manufacturers have issued it, sure it's no longer a problem, but simply put, it was AMD's fault, they actually owned up to that and accepted RMA's for all chips that burned and there's no excuse for it - this thing of giving AMD passes and dismissing everything they screw up as a minor incident has gotta go from the hardware communities, they're not some small mom n pop underdog who needs help. They didn't deserve this help when they languished with FX, and they don't need this help now that they're successful.
Posted on Reply
#10
kapone32
Dr. DroYou've got it wrong, AGESA is part of BIOS, but a part that only AMD has the source code to. It's identical in every implementation because it's a closed-source blob. This is the low-level firmware code responsible for the initialization of the processor and many of its low-level functions, including the emulation of certain instructions that are not natively present in the hardware. It's been an achilles heel for them for some time, and they're aware of it, which is why it'll be open sourced beginning with the next platform (it'll become AMD openSIL, look it up).

AMD has released fixed AGESA code and all motherboard manufacturers have issued it, sure it's no longer a problem, but simply put, it was AMD's fault, they actually owned up to that and accepted RMA's for all chips that burned and there's no excuse for it - this thing of giving AMD passes and dismissing everything they screw up as a minor incident has gotta go from the hardware communities, they're not some small mom n pop underdog who needs help. They didn't deserve this help when they languished with FX, and they don't need this help now that they're successful.
So explain to me how my CPU did not cook itself. Even though I have been using AMD on Asus from the beginning. What you are not admitting is that the MB vendors offered BIOS updates way before the first AGESA update from AMD came down. As much as you may want to feel your opinion is correct it is not. AGESA is not a weakness on AMD just because it is not made for Intel chips.

At least there is no threat of instability on AM5 CPUs like the CPU you own. With summer coming you should worry about that rather than spending time giving your opinion on the voracity of AGESA updates on AM5.
Posted on Reply
#11
Dr. Dro
kapone32So explain to me how my CPU did not cook itself. Even though I have been using AMD on Asus from the beginning. What you are not admitting is that the MB vendors offered BIOS updates way before the first AGESA update from AMD came down. As much as you may want to feel your opinion is correct it is not. AGESA is not a weakness on AMD just because it is not made for Intel chips.

At least there is no threat of instability on AM5 CPUs like the CPU you own. With summer coming you should worry about that rather than spending time giving your opinion on the voracity of AGESA updates on AM5.
Because you're special, it looked at your wholehearted devotion to AMD and decided not to burn?

Obviously because not every CPU malfunctioned. Very few did, and the problem was solved swiftly. It still happened, though, so there's no denying that.

AGESA is a weakness because it's buggy and AMD doesn't share its source code. Intel CPU microcodes share the same weakness, except that Intel's got a better track record with their maintenance. OpenSIL will resolve this problem, any fixes will be available much faster because interested parties will be able to find and fix problems themselves.
Posted on Reply
#12
kapone32
Dr. DroBecause you're special, it looked at your wholehearted devotion to AMD and decided not to burn?

Obviously because not every CPU malfunctioned. Very few did, and the problem was solved swiftly. It still happened, though, so there's no denying that.

AGESA is a weakness because it's buggy and AMD doesn't share its source code. Intel CPU microcodes share the same weakness, except that Intel's got a better track record with their maintenance. OpenSIL will resolve this problem, any fixes will be available much faster because interested parties will be able to find and fix problems themselves.
Yep that is why this issue is always discussed in the Ryzen owners Garden.....not. You are making a mountain of a mole hill. AGESA updates have been a part of Ryzen since the beginning. You act like in the years since the launch of Ryzen AGESA has not improved the chips. That shows that you don't know what it is as AGESA updates are improvements or refinements for the operation your Processor.

I do not want anyone having root access to my CPU. Making GPU performance open source is one thing but a CPU is so much more that I am quite happy with AMD keeping it in house and only sharing it with board partners.
Posted on Reply
#13
Dr. Dro
kapone32Yep that is why this issue is always discussed in the Ryzen owners Garden.....not. You are making a mountain of a mole hill. AGESA updates have been a part of Ryzen since the beginning. You act like in the years since the launch of Ryzen AGESA has not improved the chips. That shows that you don't know what it is as AGESA updates are improvements or refinements for the operation your Processor.

I do not want anyone having root access to my CPU. Making GPU performance open source is one thing but a CPU is so much more that I am quite happy with AMD keeping it in house and only sharing it with board partners.
No, I am not. It's as much of a molehill as the "Raptor Lake crashing problems", except that there's actually AMD's involvement and hardware *did* get damaged.

You got it all wrong. Currently, AMD PSP has root access to your processor, and it cannot be disabled. OpenSIL will benefit everyone. Being able to exclude parts like the PSP would actually be what would ensure that only you have root access to your CPU.

This is why you don't defend a company blindly, unless of course, AMD (and people who have the credentials to claim to be AMD) having root access to your processor is a-OK with you.
Posted on Reply
#14
kapone32
Dr. DroNo, I am not. It's as much of a molehill as the "Raptor Lake crashing problems", except that there's actually AMD's involvement and hardware *did* get damaged.

You got it all wrong. Currently, AMD PSP has root access to your processor, and it cannot be disabled. OpenSIL will benefit everyone. Being able to exclude parts like the PSP would actually be what would ensure that only you have root access to your CPU.

This is why you don't defend a company blindly, unless of course, AMD (and people who have the credentials to claim to be AMD) having root access to your processor is a-OK with you.
Show me a post that shows what you are talking about with someone that actually owns a AMD Ryzen CPU that complains about AGESA updates to the level you are talking about. You are defending Intel with that statement and then making it seem that the way those CPUs are released are not a result of AM5 and before that AM4 performance. It doesn't matter though because based on the rumours I will enjoy updating my 7900X3D with the next 12 core X3D, call it 9900X3D. Yep and it will be soon as well as that is every AM5 board that Asus sells. It is now April so I expect Computex to have the debut.

I really do not care if you call me an AMD fan boy either. I will freely admit that when I started buidling a modern PC, that I chose AMD with the 965BE. That was replaced with a 1090T and yes those extra 2 cores made ripping DVDs that much faster to appreciate it (I found a place that rented Anime). After that I went to FX8120 and OC that chip to 4.7 Ghz with no voltage increase. That was repalced with the 1700X and yes even you will agree that it was much faster. The next chip was a 2600 but buy that time I was making systems so I was able to grab a Asus X399 Extreme for $250 from Earth Dog and get a 1900X. That was replaced with the 2920X and the board was the MSI X399 Ace that I got as a display unit from Canada Computers for $125 as it had no box. That was me until AMD 5000 but I built systems with every single chip from AMD. The 3300X was one of my favourite CPUs but once I felt the butter smoothness of the 5900X I came back down to AM4. I even used a 5950X and that feels like the PC knows what you want before you hit the key. I even got a 5800X3D and it was great at Gaming but meh in day to day vs the 59 series CPUs. Reviews confirm what I am saying.

Then AM5 (which this post is about) was announced and I knew I was going to get it. I thought about the 7700X and 7900X but when I heard that the 7900X3D was a thing I ordered one as soon as they were available and sold my 5800X3D for a cool $250 in 1 hour. Where I see the 7900X3D in Gaming is that it feeds my GPU between 3-5 Gb/s more to the VRAM buffer vs the 5800X3D. There are a few of you here that tell me that what I am experiancing is not real and that is fine but now the reality of AM5 has just made the argument moot. I am willing to bet that the next 12 core will be faster than my chip that I plan to do the exact same thing. I have never used reviews to buy AMD CPUs.

I will probably buy another MB too but not anyhting new. I will get a A620 board and put my 7900X3D in that to add to my Mining array. I know I will need RAM so I will probaly splurge on some Fast tight RAM as the next chip should have an improved memory contorller making that a smart choice.

Just look at the sheer number of boards that have been released for AM5 from Asus and understand that I am not alone in my position.
Posted on Reply
#16
mkppo
Dr. DroNo, I am not. It's as much of a molehill as the "Raptor Lake crashing problems", except that there's actually AMD's involvement and hardware *did* get damaged.

You got it all wrong. Currently, AMD PSP has root access to your processor, and it cannot be disabled. OpenSIL will benefit everyone. Being able to exclude parts like the PSP would actually be what would ensure that only you have root access to your CPU.

This is why you don't defend a company blindly, unless of course, AMD (and people who have the credentials to claim to be AMD) having root access to your processor is a-OK with you.
Hmm, your posts seem to conflict with pretty much every reputed reviewer out there. In short, the board makers were largely at fault because they pushed certain volts way beyond what was recommended, thinking it wouldn't be an issue. Sure AMD should've set hard limits on those voltages like they have now and that's their fault, but they couldn't have predicted the board makers would do it and the end result would be this.

You make it sound like AMD set those voltages in the AGESA code and the chips blew up. That's certainly not what happened.

Look up the review Steve made at GN if you're a bit confused by what actually happened or don't have much recollection. Also, Intel is as much involved with the recent issue as AMD was, just heard the PCWorld podcast and even gordon is semi blasting Intel because their tactics are obvious, but i'm not going to go there and derail the thread.

Ohhh the thread! So are these for the Zen 5 CPU's or some new APU's they are about to launch?
Posted on Reply
#17
Dr. Dro
mkppoHmm, your posts seem to conflict with pretty much every reputed reviewer out there. In short, the board makers were largely at fault because they pushed certain volts way beyond what was recommended, thinking it wouldn't be an issue. Sure AMD should've set hard limits on those voltages like they have now and that's their fault, but they couldn't have predicted the board makers would do it and the end result would be this.

You make it sound like AMD set those voltages in the AGESA code and the chips blew up. That's certainly not what happened.

Look up the review Steve made at GN if you're a bit confused by what actually happened or don't have much recollection. Also, Intel is as much involved with the recent issue as AMD was, just heard the PCWorld podcast and even gordon is semi blasting Intel because their tactics are obvious, but i'm not going to go there and derail the thread.

Ohhh the thread! So are these for the Zen 5 CPU's or some new APU's they are about to launch?
Distinct, compounded issues; the critical problem is that the failsafes weren't working. This wasn't restricted to one brand, and an AGESA update was required to resolve the problem. Thus, an AMD issue.

As for "motherboard makers being irresponsible", as long as the voltages set by motherboard manufacturers were within AMD's specification (which to the best of my knowledge, the maximum should be somewhere around 1.4 V, need to look up the whitepaper, just pulled an all-nighter here, feel free to look it up if you're interested), the processor should not fail, and most certainly, not as catastrophically as they did. Realistically speaking, even if voltages were actually quite unsafe, the processor shouldn't smoke as the CPUs that failed did, with extreme temperatures and very localized malfunctions (same junction, same pins charred). That indicates that the current limit control was quite literally not working/present in earlier AGESA versions.
Posted on Reply
#18
kapone32
Dr. DroDistinct, compounded issues; the critical problem is that the failsafes weren't working. This wasn't restricted to one brand, and an AGESA update was required to resolve the problem. Thus, an AMD issue.

As for "motherboard makers being irresponsible", as long as the voltages set by motherboard manufacturers were within AMD's specification (which to the best of my knowledge, the maximum should be somewhere around 1.4 V, need to look up the whitepaper, just pulled an all-nighter here, feel free to look it up if you're interested), the processor should not fail, and most certainly, not as catastrophically as they did. Realistically speaking, even if voltages were actually quite unsafe, the processor shouldn't smoke as the CPUs that failed did, with extreme temperatures and very localized malfunctions (same junction, same pins charred). That indicates that the current limit control was quite literally not working/present in earlier AGESA versions.
You do realize that since you made the statement that people are making the 13&14th Gen I9 chips unstable are not the issue that they seem to be that even more information is coming forward. If I were you I would spend my time trying to see if you will be effected in the summer than waxing on your lamentation of AGESA. I guess you have no idea how ridiculous this looks in a thread about BIOS updates for AMD's next generation of CPUs while Youtube is awash with videos about the instability of your chip.
Posted on Reply
#19
Dr. Dro
kapone32You do realize that since you made the statement that people are making the 13&14th Gen I9 chips unstable are not the issue that they seem to be that even more information is coming forward. If I were you I would spend my time trying to see if you will be effected in the summer than waxing on your lamentation of AGESA. I guess you have no idea how ridiculous this looks in a thread about BIOS updates for AMD's next generation of CPUs while Youtube is awash with videos about the instability of your chip.
Yeah, it's a similar problem. However, there are no reports that any 13th or 14th Gen Intel CPU went up in smoke. Failsafes and tolerances are in working order.

You're the one who brought all of this up, don't spin this on me.
Posted on Reply
#20
kapone32
Dr. DroYeah, it's a similar problem. However, there are no reports that any 13th or 14th Gen Intel CPU went up in smoke. Failsafes and tolerances are in working order.

You're the one who brought all of this up, don't spin this on me.



Call it spin now.
Posted on Reply
#21
Dr. Dro
kapone32



Call it spin now.
You're still not showing me where any of them had an actual hardware failure and caught fire as a result, let alone a consistently reproducible problem as happened with Ryzen. Why do you think it's an us vs. them situation? It's not. None of these corporations care about us.

The new microcode that supports IA CEP disable improved stability plenty on my end, and i'm sure Intel is working diligently to solve any issues that arose, just like AMD did.
Posted on Reply
#22
mkppo
Dr. DroDistinct, compounded issues; the critical problem is that the failsafes weren't working. This wasn't restricted to one brand, and an AGESA update was required to resolve the problem. Thus, an AMD issue.

As for "motherboard makers being irresponsible", as long as the voltages set by motherboard manufacturers were within AMD's specification (which to the best of my knowledge, the maximum should be somewhere around 1.4 V, need to look up the whitepaper, just pulled an all-nighter here, feel free to look it up if you're interested), the processor should not fail, and most certainly, not as catastrophically as they did. Realistically speaking, even if voltages were actually quite unsafe, the processor shouldn't smoke as the CPUs that failed did, with extreme temperatures and very localized malfunctions (same junction, same pins charred). That indicates that the current limit control was quite literally not working/present in earlier AGESA versions.
I vaguely recollect from the analysis done by reviewers at the time that they weren't within AMD specification. So AMD later on just went the hard limit approach to limit the secondary voltages and the motherboard manufacturers have no way around it but to actually get the timings right and set a proper EXPO profile without pumping unnecessary voltages.

Failsafe not working is on AMD, sure. The chips shouldn't have failed the way they did. In fact, they had amazing failsafes in every other way - including tests done without a cooler by multiple outlets where no damage occured to the chips. But that volgate pump sure did the trick.

Intel on the other hand didn't bat an eyelid when they knew full well what the motherboard manufacturers were up to and did nothing about it only to point the finger at them when it's clearly their fault. Atleast AMD didn't stoop that low

edit: to clarify, I know that's not intel's only fault, I was just pointing to one
Posted on Reply
Add your own comment
Nov 23rd, 2024 03:09 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts