I think I'm the only one here that's running Flare X RAM... I've been stable since I got them with no issues from F4 BIOS and up... Running XMP Profile @3200 C14-14-14-34-48 CR1... Although I am running into Voltage issues on F22 ... CPU Core up to 1.448V and SoC at 1.248V on AUTO in BIOS... Also I don't get the UEFI Boot Screen after F4 BIOS... From what I can tell my ASUS DUAL OC RX-580 O4G doesn't play well with any Firmware after F5a... F10 is a mess on my K5...

Here are some screenshots...

@JSebastian ok great. Have you tried all of the firmwares Gigabyte have released? Which one works the best for you? Whichever revision works the best for you is the one I'll model a modified version around. Establishing some sort of stable platform for everyone to start from isn't an exact science but it's better than stumbling around blind without any idea where to start from. The only thing I know with certainty is that any firmware from F10 onwards is garbage. F22 for all that it gets right also gets just as many things wrong, 5 steps forward, 5 steps back at the same time, as it were. Theres a danger F23/24 should we ever see it might actually be half decent though. Assuming GB listen to the bug reports that is.

Hello ket and fellow Gigabyte ... victims? Thanks for all of the work involved in this. I really like problem crunching so I decided to join the fun.


I fell for the AX370 K7 after seeing Buildzoid's videos (also mentioned elsewhere in this thread). I decided to spoil myself to something high-end (lol@me) AND it was on sale. Honestly, it looks the part too, so what's not to like if it's a decent overclocking board?


I went all-in with Corsair's RGB RAM (2x8GB 3466 cl16, Samsung B-die) and the first thing the board did was to corrupt the BIOS (F6) after applying the XMP-profile. We're talking first attempt after installing all drivers, no CPU OC. Since the Ryzen platform has a reputation of being picky with both BIOS and RAM, I let my saltiness go. I booted from the backup BIOS, flipped the switch to the main BIOS, flashed to F10 and went up from there. Still, I'm running single BIOS-setting with F6 as the backup as I KNOW it will boot with standard settings from that BIOS. So no, I do not trust this board.


I've played around with the newer BIOS (F10, F20, F21, F22b and F22) and F21 seems to be my best bet with the R5 1600X@4000Mhz and (now) 4x8GB@3400Mhz CL16 with 1.35V (reads 1.368V in Windows)

F22 wouldn't let me run RAM faster than 3200Mhz CL20 without errors. F22b was basically working as well as F21 except RGB Fusion was not functional, so I went back to F21.
Applying my F21 settings to the F22 BIOS made my RAM very unstable.
F22 would make HW Monitor and HWiNFO and Thaiphoon Burner lose track of DIMM3; it wasn't registered but dual channel was active. Really weird.
The modified F10 BIOS decided to set VID to 1.55V out of the blue - as far as I know this is what the CPU is "asking for" but I had a fixed VCore@1.3125 so nothing happened. I have no idea whether something would or not. It may have been something random or perhaps I'd tinkered with something. I panicked calmly and went back to F21 which in turn gave me back the 34.00 RAM multiplier.


Here's the deal:

F21 works best for me, so far.
3466 XMP-profile doesn't work. 1.45V with 20-20-20-20-40 primaries makes no difference; both pairs of DIMMs have been tested seperately in either pair of slots.
XMP@3400 16-18-18-18-36 and 1.35V (1.368V) works perfectly (memtest@200%+ error-free as of now) with 4x8GB DIMMs installed.
I've run the CPU at 4040Mhz and RAM at 3434Mhz CL16 BCLK 101.00Mhz perfectly stable.
RGB Fusion has lost the connection with my Corsair RAM; two are red with a pink-ish tone, the other pair is red with an orange tone.


Honestly, the RGB deal SHOULD be a selling point of this board but it doesn't work and should instead be a reason to NOT buy the board. The stuff lights up and does whatever it wants and to call the software "buggy" is being too kind. I'd likely chosen a version without the RGB had there been one. Instead I went all-in with RGB RAM, simply because I might as well. Especially after I found the CMR16GX4M2C3466C16 on the QVL (well, as 3400-3466Mhz to be fair) and they are advertised as "RGB Fusion compliant". Selecting the RAM under "advanced" in the software turns the motherboard LEDs a dimm, constant light blue. When I then choose the motherboard LEDs the RAM RGB turn the same colour and the motherboard now turns red and stays there, no matter which options I choose. That is, until I press "reset" in the software and then everything reverts to what the in-BIOS RGB Fusion settings are.

As far as RGB functionality goes, I'd describe my K7 as "NOPE!"


Considering many other Ryzen-stories I propably should not complain about neither my 32GB RAM OC nor the fact that I've pulled 4141Mhz on my CPU on air-cooling (I dialed it back down because 78-80C* generates too much noise from my fans and I don't like mixing electronics and water).
Whether I can complain or not, my experience might be of value to this thread.

@hansen_DK welcome to our little slice of Gigabyte hell :p Honestly the GB boards are the biggest trash I've used and I've reviewed 5 different X370 boards. You can check those reviews out here on win-raid. The best X370 boards to buy are the Asrock Taichi or Gaming X, Asus X370-F or Crosshair, or if you need something cheaper the Asus Prime Pro or MSI X370 SLI Plus.

I'm going to copy/paste something I've been trying to send GB for the last couple days but I'm constantly getting "System is busy, try again later" crap. If others want to try and submit this thats would be great the more GB are harassed the more chance there is of something actually being done.

Hello,

Due to an incredibly high complaint rate from my customers regarding the AX370 Gaming 5 I took one from my stock to diagnose, confirm and troubleshoot my customers problems (as well as finding additional problems in my own testing). To say that I am astounded by the poor quality firmware is a colossal understatement the amount of bugs and issues I have found is by far and away not befitting of such a company as Gigabyte someone needs to give a very strong talking to the BIOS R&D department, my customers complaints are not unfounded in the slightest. To be clear the hardware I used when testing the Gaming 5 I also tested on multiple other X370 boards from other manufacturers to ensure there were no issues with the test hardware. None of the other boards from other manufacturers had any problems with the test hardware so these bugs are squarely to be laid at the feet of Gigabyte BIOS R&D. Below is the list of bugs I found with firmware F22. I also compared F22 to the beta F9c firmware which can be found here; http://forum.gigabyte.us/thread/1542/ori...s-thread

1, F22: No POST when XMP is enabled and a memory divider is selected (lower or higher) other than the XMP speed. Memory overclocking is significantly inferior to F9c at 3333MHz.*

F9c: 2400 and 2666 memory dividers do not work when XMP is enabled. All other memory dividers work fine, and memory overclocking is significantly superior at 3600MHz, CLDO_VDDP set to 700.*

*These are the results obtained with a kit of Samsung B-Die G.Skill RipjawsV F4-3200C15D-16GVK.

2, F22: Half or more of the advanced memory timings do not display default SPD \ manually entered values next to them.

F9c: Same results as the test with F22.

I've attached an image of this bug to better illustrate it.

3, F22: When HPET is disabled a 0d POST code system hang occurs when trying to restart from Windows. In short, you broke the High Precision Event Timer. Something which AMD recommend disabling for Ryzen as standard procedure.

F9c: No 0d POST code error when disabling HPET.

4, F22: High vcore SoC voltage when left at "Auto" when CPU overclocking, 1.248v to be exact. This is extremely excessive, to say the least.

F9c: Also sets extremely excessive SoC voltage when left at "Auto" when CPU overclocking.

5, F22: P-State overclocking appears to be broken, POST code 85 with +200MHz OC. I tested with both a R5 1600 and R7 1700 with the same result. Both chips I have verified 100% capable of 3.9GHz so a +200MHz over stock speed is nothing for them at all.

F9c: Can't test. Theres no P-State overclocking options.

6, F22: USB keyboard fails to wake from sleep mode if allowed to enter the sleep state while in the UEFI. As someone with a programming background I can tell you for a fact if USB MSI is disabled this problem will go away.

F9c: Same results as the test with F22.

7, F22: Some LED preset colours (orange particularly) are not the colour they are supposed to be with the orange preset actually being more of a summer yellow colour. Again, as someone with a programming background I can tell you for a fact this is an easily corrected bug all you have to do is change the Hex colour value the LED preset is using.

F9c: Same results as the test with F22.

8, F22: CLDO_VDDP, BankGroupSwap, BankGroupSwapAlt, Channel Interleaving and Rank Interleaving options are all missing.

F9c: All of the above options except for BankGroupSwapAlt are there.

Coming from a programming background I also noted such options as Spread Spectrum, Timer Tick Tracking, and Clock Interrupt Tag are missing. The latter two options particularly could prove very useful as they are for pre-emptive multitasking and therefore can potentially resolve SMT anomalies in certain scenarios. I'm perplexed as to why you have not included them.

When will Gigabyte be addressing these issues? Most of these issues are extremely obvious and should have been caught and rectified with internal testing.

Heres the image to save and attach to the ticket

[[File:20180323_165628.jpg|none|auto]]@ket thank for the feedback... I've retested all the available firmware from F3 on up to the latest... I've determined that for my particular K5 board & setup... Firmware version F4 is the most stable all around and mainly it's the only version that maintains a 1.104V SoC... as well as a more stable VCORE offset at the BIOS at 1.296V max... I really hope that GB gets back on the ball with their firmware development and finally get it right... The bad part seems to be the priority given to the K7 and 5 boards... Leaving the K5 at low priority and the last to be updated compared to the other boards in the line... If I may offer my professional opinion and request... I think you should base your modified UEFI Firmware around the F4 UEFI... Anything after F4 cranks up the voltage too much for stock settings on AUTO... Too many variables GB didn't seem to factor in... Adding support for Pinnacle, Raven and Bristol AM4 cpus by combining their respective settings into AUTO all over the place wasn't the way to go Here are a few screenshots running F4 Firmware...

At least we can conclude one thing so far it seems.. that is GB apparently stopped giving even a quarter of a shit somewhere between AGESA 1.0.0.4 and 1.0.0.6 depending which model of board you have. Your Flare X kit should work the best with anyfirmware with AGESA 1.0.0.6 onwards too so its a bit odd it works the best with something as old as F4.

@ket

Now you mention it I noticed the high SOC voltage in all the BIOS I tried out. I found it weird as the BIOS itself stated 1.100V as the manual value so I started searching the web for its significance. As a consequence it didn't take long before I punched in 1.100V myself after each flash. It reminds me of my old GA-Z68-something where the BCLK was 101.xx when set on Auto OR manually set to 100.00 - this was a problem for my wifi-adaptor which would lead to bootloops and random BSoD when BCLK was over 100.4Mhz so I punched in 100.01Mhz and all was great for years. I suppose the high BCLK was to inflate performance figures. This motherboard also had a tendency to go all out "Gigabyte" and corrupt the BIOS for no reason. During a cold boot it would just reflash from the backup BIOS. I really learnt every single value by effin' heart and finally found something stable in the end. I excused Gigabyte by telling myself the Z68 wasn't around for long enough to do stuff right, lol.

LED-orange has been off in every instance, AFAIK.

I didn't experience the problem with the memory divider@XMP, though. (Neither with F22 nor any other BIOS).

I noticed that tRFC, tRFC2 and tRFC4 go all over the place when playing with the divider. It would be very nice to see the auto-values.


I've now deleted RGB Fusion. Again. With Corsair Link I've managed to re-sync the RAM LEDs and HWinfo now reads and recognises all four DIMMs.

Still on F21 and memtesting 3400@16-16-16-16-36

I managed to forget my point with the Z68-story:

Perhaps someone got the idea that maxing out SOC voltage would aid in OCing or help with overall stability.

It seems that at some point the voltages have been cranked up to max on Auto.
With only a mild BCLK OC and everything on Auto, my CPU would run at 4.2Ghz on two cores but VCore was hovering in the 1.44-1.48V range under heavy loads,

Zitat von hansen_DK im Beitrag #487

---

@ket

Now you mention it I noticed the high SOC voltage in all the BIOS I tried out. I found it weird as the BIOS itself stated 1.100V as the manual value so I started searching the web for its significance. As a consequence it didn't take long before I punched in 1.100V myself after each flash. It reminds me of my old GA-Z68-something where the BCLK was 101.xx when set on Auto OR manually set to 100.00 - this was a problem for my wifi-adaptor which would lead to bootloops and random BSoD when BCLK was over 100.4Mhz so I punched in 100.01Mhz and all was great for years. I suppose the high BCLK was to inflate performance figures. This motherboard also had a tendency to go all out "Gigabyte" and corrupt the BIOS for no reason. During a cold boot it would just reflash from the backup BIOS. I really learnt every single value by effin' heart and finally found something stable in the end. I excused Gigabyte by telling myself the Z68 wasn't around for long enough to do stuff right, lol.

LED-orange has been off in every instance, AFAIK.

I didn't experience the problem with the memory divider@XMP, though. (Neither with F22 nor any other BIOS).

I noticed that tRFC, tRFC2 and tRFC4 go all over the place when playing with the divider. It would be very nice to see the auto-values.


I've now deleted RGB Fusion. Again. With Corsair Link I've managed to re-sync the RAM LEDs and HWinfo now reads and recognises all four DIMMs.

Still on F21 and memtesting 3400@16-16-16-16-36

---

I agree completely!!! It's really really odd that I have to back to F4 Firmware... Ryzen Master works a hell of a lot better in the latest firmware as well as the Flare X in slots 2+4 for F21... *BUT* my ASUS DUAL OC RX-580 does not... And I have absolutely no fucking clue as to why... No UEFI Post screen... Windows studders a bit... What I can't seem too fathom is as to GB total incopitance in R&D way ahead of them launching all these motherboards for Ryzen and Threadripper... Complete lack of any sense of what the idea was supposed to actually be with the AND launch... They've been playing catchup ever since... And yeah... They supported giving a shit as of AGESA 1.0.0.6... Hence the reason why they just slapped on an "a" after the 6... Lol... Also... From Firmware F10 and above... I get the overvolted VCORE & SoC...I mean those higher volts... etc... Go past the specs for my Ryzen 5 1600 and the K5... If I had the latter Cpus like Raven Bridge or whatever that do run at those specs then no problem... But since I didn't... Where's the logic in their complete disregard for 1st Gen Ryzen 5 users??? And thanks to GB I can't lower the voltage for VCORE in the UEFI so I have to manually set it with Ryzen Master... The issue keeps coming back too my GPU and Voltage with the latest firmware... I can't get a decent OC either on F21... unless I set it above 1 4V and keep the SOC at 1.246V... I do however get the ADVANTAGE of overclocking my RAM up to 3466 on F21... Even though the board goes haywire after a while... It's coming down to a trade-off basically due to GB incopitance... I will however keep testing with your firmware along with GB's just for reference... Hopefully I can go back up to F21 at lower voltages and switch all GB *AUTO* stock values to what they're supposed to actually be from the start...

You're GPU problem is most likely a related result of GB breaking something in the firmware that meant the GOP on GTX10 series cards didn't work making CSM necessary and Secure Boot unattainable. I've also recently been informed that theres a lot of complaints of GBs twitter feed so you can go complain at GB there too.

I flashed back F7a (with AGESA: SummitPI-AM4 1.0.0.6) on my K7 board

- HPET OFF works fine
- Fast Boot works as intended, with HiberBoot enabled.
- UEFI GOP works correctly (not falling back and having UI elements streched while Windows is booting)

Windows 10 options aren't exposed from F10 and onwards. I believe "Other OS" gets defaulted and Fast Boot cannot work properly.

About LEDs, I have three RGB fans from Coolermaster (Air Balance) and colors from onboard LEDs and fans are mostly in sync. I don't have much to complain regarding this one.

About voltages, SoC voltage was always overvolting if left on Auto. Gigabyte says it's normal, but it's actually pretty abusive, and 1.1v should be more than sufficient for 3.9Ghz CPU and 3200Mhz DDR4 CL16.

Looks like AMD published a new AGESA, so let's hope with a grain of salt that Gigabyte will attempt to fix these obvious issues.

Zitat von AndreDVJ im Beitrag #492

---

I flashed back F7a (with AGESA: SummitPI-AM4 1.0.0.6) on my K7 board

- HPET OFF works fine
- Fast Boot works as intended, with HiberBoot enabled.
- UEFI GOP works correctly (not falling back and having UI elements streched while Windows is booting)

Windows 10 options aren't exposed from F10 and onwards. I believe "Other OS" gets defaulted and Fast Boot cannot work properly.

About LEDs, I have three RGB fans from Coolermaster (Air Balance) and colors from onboard LEDs and fans are mostly in sync. I don't have much to complain regarding this one.

About voltages, SoC voltage was always overvolting if left on Auto. Gigabyte says it's normal, but it's actually pretty abusive, and 1.1v should be more than sufficient for 3.9Ghz CPU and 3200Mhz DDR4 CL16.

Looks like AMD published a new AGESA, so let's hope with a grain of salt that Gigabyte will attempt to fix these obvious issues.

---

Yes indeed as you know my view on gigashite, theyre the biggest pieces of crap ever in the computer sector, not just am4 intel are massively affected as well, even if the gaming5 or k7 didnt have sharp edges i still wouldnt wipe my ass with them. yes indeed forum readers they REALLY are that bad, although it took me only and hour with my scope and multimeter to find various hardware faults across the chipset, these are indeed now discontinued by major stores, sorry to piss in your bucket but i strongly recommend you get rid of them right now and buy either an asrock taichi or msi gaming titanium. There is no software fix that will cure the problems these boards have im afraid you will get close but you will never get either of these boards working right im afraid, the bios corruption occurs due to in-stable voltages and one or two parts wrongly specced, this is also the main reason for tthe bios bricking issues, switching to "single" bios mode will make no difference whatsoever, so you have been warned. i did all these tests as i wanted to find out why this board destroyed one of my r7 1700 non x cpus.

The voltage and ripple readings i got on my scope were bloody terrible affecting the LED circuitry and power delivery, if i get time later ill do some images and upload them here, ive done these tests on my asrock taichi, that board is not even in the same league as these pieces of shit, also unless the memory controller built into your r7 1700 cpu can accept and run xmp 3466 fully stable with memtest dont blame the memory or the board for that issue, its a cpu limitation, however i will note running your ram at 3333mhz with tight timing yields the fastest results on the r7 1700 or x variant cpus. Also bear in mind the gaming 5 has no clock generator IC chip thus you cannot fine tune your system even if these boards were working properly, all i can do is warn people whether or not they listen to me is on their hands.

As I said before, I don't deny the firmware randomly corrupting itself but from my testing switching to single ROM mode has stopped it completely. Most of the problems with these boards are indeed due to sloppy firmware from Gigabyte. My R7 1700 is also has a strong IMC, its capable of 3600MHz+ but with the newer firmwares (F10 onward) the Gaming 5 test board I have can only do 3333MHz switch back to F9f or similar and 3600MHz is easy to get without insane volts or crappy timings. Gaming 5 may not have a clock gen but you really don't need one as it pushes the PCI-E bus out of whack as well as another bus or two which I can't remember off the top of my head so chances are you wouldn't get beyond a BCLK of around 103MHz anyway before something in the system decides its going to become unstable on the higher bus. I'd be interested to look at those scope images to see if they match with the unstable voltage readings I get.