Ok guys, I've sent @cpx a quick firmware fix for the bugged HPET which hopefully he can test for me. Pending his test results I'll know where to go from there.

Anyone want to do me a favour? (I'm tired of making new emails pestering Gigabyte) Can people post these issues in the Gigabyte forums and submit support tickets to try and get Gigabyte to fix them. Feel free to put things in your own words so its not an obvious copy / paste. Considering GB use the same firmware across all their X370 boards these issues are likely universal through the whole product stack so hit everyone.

Official UEFI F22 bugs:

1. 2400 and 2666 memory dividers do not work with G.Skill RipjawsV F4-3200C15D-16GVK (Samsung B-Die) When XMP is enabled.

2. Disabling Gear Down mode with XMP enabled causes a no POST.

3. With XMP disabled setting a command rate of 2T does not work. AIDA64, CPU-Z, etc still report 1T command rate.

4. Half or more of the advanced memory timings do not display default SPD \ UEFI values next to them

5. When HPET is disabled a 0d POST code system hang occurs when trying to restart the system

6. P-State overclocking is broken... again.

7. When overclocking the CPU vcore with constant voltage (likely applies when overclocking the CPU with offset voltage as well) VCORE SOC Voltage is set extremely high when left at the "Auto" setting (1.236v-1.248v).

8. Setting the Orange LED profile in RGB Fusion turns the LEDs yellow. Incorrect preset values. Should be Red: 255, Green: 19, Blue: 0.

9. Give users a key-in method for RGB Fusion.

My G.Skill TridentZ kit (Samsung D-Die 4x8G) works fine with XMP and Geardown Disabled.

Disabling HPET = System won't post past 78 state (ACPI Initialization?)

I'll post on Gigabyte forums about HPET. That's something basic to do these days, they really did a half-assed job on this one (and all others - I'm pretty sure Nvidia owners are having trouble with CSM disabled).

EDIT: I have the K7 board. Debug codes may be different across different boards.

Zitat von AndreDVJ im Beitrag #468

---

My G.Skill TridentZ kit (Samsung D-Die 4x8G) works fine with XMP and Geardown Disabled.

Disabling HPET = System won't post past 78 state (ACPI Initialization?)

I'll post on Gigabyte forums about HPET. That's something basic to do these days, they really did a half-assed job on this one (and all others - I'm pretty sure Nvidia owners are having trouble with CSM disabled).

EDIT: I have the K7 board. Debug codes may be different across different boards.

---

I'd stick with the latest microcode, as many users may reuse existing motherboard for the upcoming Ryzen 2700X. Up to you though.

I don't volunteer myself at the moment for any tests, because I don't think I'll recover from a brick, because my motherboard won't post if I switch to Single BIOS. With the Dual BIOS side, either Main or Backup firmware posts normally.

@AndreDVJ I'd very much like to use newer firmware but at this time that is just not possible for as many steps forward as the F22 firmware takes it also takes as many steps backwards. Have you tried switching to single BIOS mode, entering Q-Flash, then switching to the "bad" BIOS and flashing it? Sounds like your board has corrupted the hardware ID, checksum, bootblock, or something similar to that nature.

http://forum.gigabyte.us/thread/3503/ga-...aming-5-bricked

I'm not saying the G5 doesn't brick itself, I'm just saying that the G5 I use for making modded firmware hasn't bricked itself since one particular fateful firmware (a firmware based on the same AGESA code also bricked the GT7 I have so I chalk that up to something with that particular iteration of AGESA code) which subsequently prompted me to operate the board in single ROM mode only as an extra layer of safety and the board has never ever done it again so it's worth taking the same step I have as it does seem to be an effective mitigation measure.

New section is in the works, it will contain firmware that has shown itself to be the least buggy considering the continuous downward spiral of quality with Gigabytes firmware. I need people who can test vanilla firmware and report to me which is the least buggy for them for the AB350 Gaming and Gaming 3, as well as people who can test vanilla firmware for the X370 Gaming, Gaming K3, Gaming K5 and Gaming K7.

@ket I understand your concerns. If you feel F8 firmware codebase works better for the broader community, then I respect your decision.

By the way, the backup BIOS was corrupted. I flashed the backup BIOS and now Single BIOS works, and both are in sync.

For the K7, the least buggy versions were F6 and F7a, and for some F7b because of P-States unlocked (though I don't care about P-States). Any other version former or latter than F6/F7's are an utter half-baked joke.

ket you must have the patience of a saint, its been over a year now and gigashites intel boards are just as bad!, How comes brands like abit went bust but these jokers are still in business?

Zitat von POE_UK im Beitrag #476

---

ket you must have the patience of a saint, its been over a year now and gigashites intel boards are just as bad!, How comes brands like abit went bust but these jokers are still in business?

---

Zitat von AndreDVJ im Beitrag #475

---

@ket I understand your concerns. If you feel F8 firmware codebase works better for the broader community, then I respect your decision.

By the way, the backup BIOS was corrupted. I flashed the backup BIOS and now Single BIOS works, and both are in sync.

For the K7, the least buggy versions were F6 and F7a, and for some F7b because of P-States unlocked (though I don't care about P-States). Any other version former or latter than F6/F7's are an utter half-baked joke.

---

Zitat von ket im Beitrag #477

---

Good to know, I'll see if I can hunt down F7b. Now both chips on your board are functional I'd strongly recommend you flip the bottom dip switch so the board operates in single ROM mode that way you are only ever risking one firmware image at a time and it prevents the board from automatically trying to recover and bricking both firmware images.

---

Another small update, I'm pretty sure I've worked out how to bring AMD CBS and PBS options forward in to the main BIOS setup for easy editing in AMIBCP. It still alludes me as to where the LED preset colours are stored though.

@AndreDVJ, ok thanks I'll grab that a little later.

@ket Hello!!! I'm willing to help you test your vanilla firmware on my AX370 Gaming-K5...