Nvm it was a setting all is good
Thats very odd theres no solid reason I can find at the moment to explain your problem, a couple rough very outside chance ideas but nothing more. As best as I know the 0d POST code is mostly triggered by a bad memory stick or memory incompatibility, can you try each stick one at a time in each DIMM slot?
@cpx I think Iām getting closer to sniffing out the problem, stay tuned. In the meantime ALL MODIFIED FIRMWARE I HAVE REMOVED!
EDIT: Problem found. The issue is in the High Precision Event Timer. In the modified firmware itās under Chipset > Chipset Options > Chipset Configuration > Chipset settings. Enabling this will fix the 0d POST code error on restarts. I disabled HPET in the modified firmware as part of a set of performance tweaks it should not be causing a 0d POST code error. You should find if you disable HPET even in the vanilla F22 firmware (found under the āPowerā settings) it will do exactly the same thing and cause the system to not POST on restarts. If you can verify that for me Iāll know how to rejig the modded firmware.
ket,
yes i can confirm, disabling HPET generated the 0d error but only in F22 and not in F22b.
also p-states do not work ok in F22 ( i can overclock only 200 mhz and after that code 85).
@cpx ok Iāll see what I can do about those problems. I think Iāve seen a HPET module in the firmware so outright swapping the modules will probably fix the HPET problem. P-States I believe are all part of the CBS module so again swapping them for ones in F22b should fix the problem. Iāll have to have a look at the modules to verify my memory but assuming Iām remembering correctly both fixes should be straightforward.
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.
@AndreDVJ P-State overclocking is broken on the K7, meaning itās also broken on the Gaming 5 as well at least as both boards are identical with the exception of the Gaming 5 doesnāt have a clock generator chip. Somewhat counter intuitively Iām actually looking at making modified firmware based on the much older AGESA 1.0.0.6 looking at the structure of F8 revisions it looks to be the most competent firmware Gigabyte have released with anything after that point being a half arsed, half baked, cripplingly lazy cowboy job.
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.
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?
I have patience because I have to, not because I want to 
Sadly while the Gigabyte circus continues I have no choice but to stick with the Gaming 5 instead of using any number of far, far, FAR superior boards I have sitting in their respective boxes begging me to switch to any one of them instead. I think the only reason GB havenāt started to sink is simply because not enough people know how bad they really are.
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.
You may find F7b for K7 in the official AM4 thread at Gigabyte forums: http://forum.gigabyte.us/thread/1542/am4-beta-bios-thread
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.