LEGACY/UEFI Boot BIOS settings

Ok. And in short, the modified BIOSes you gave are already at their “optimal” modified state and the steps done by the guy in overclock.net aren’t really applicable in my case, correct?

And is it possible that even the GOP driver is already in the BIOS of my 670’s, it is not enabled? I mean, is there a bit in the BIOS that could be an enable/disable switch?

@lorkdkag

I just flashed the new vBIOS you modified and the issue is still happening.

Would you be kind enough to check what GOP driver version is inside the two files that are inside the compressed file on the link below? They’re basically the ASUS, EVGA, and MSI GTX 670 variants hoping that those BIOSes can shed some light here.

https://www.dropbox.com/s/01qe37jalbv3fa…GA_MSI.zip?dl=0

There is no disable bit in VBIOS, it wouldn’t make sense. Either you add GOP or you don’t. If you want to disable it, there is CSM option or, like in your case, PCI ROM Priority.

From 121.rom

121.png



From Asus.GTX670.2048.130313.rom

Asus.png



From EVGA.GTX670.2048.121219.rom - No GOP!

As you can see, only old versions. Unlikely that you will see any newer versions than those offered by me. You should now write to Asus support, maybe they will report this to Nvidia and provide a test GOP. One last test would be to find someone with a newer UEFI board and ask him/her to boot from one of your Nvidia cards with CSM disabled. If it works, Asus and Nvidia need to fix this together, if not, maybe the newer GOPs don’t work on your card. But if old doesn’t work, newer doesn’t, write to Gigabyte support.

My 660Ti (GK104) has a 2013 GOP, after extracting it manually:

NVIDIA GOP: 0x1001F
Changelist: 15720600
Variant: 4
Date: May 3 2013

Although if the 2014 version did not work for you I don’t see how this could.



There’s a possibility that the latest GOP is not compatible with an older board and the included GOP in the official BIOS of my 670 (older than yours) is incompatible as well. Is it working in EFI boot for you?

Yes but I have a Z77 system which is fully UEFI compatible. As lordkag said the best thing to do is to test this specific graphics card of yours at a newer 7-series or later system with CSM disabled.



I’ll do that in my spare time, on my other system. For now, I’ll stick with legacy boot.

Thanks for all the help.

@kevindd992002

It was Asus all along. Check BIOS 4003 from P8Z68V_LX, or 3903 from P8Z68V_LE. It is unbelievable that they knew about the problem, they had a fix, but somehow missed to push this to other cards, at least those from P8Z68V series. It goes beyond laziness, it is zero interest towards the customer.

Since you always ask for more details, I’m sure you won’t mind some advices for contacting Asus support:
- try to put all in one message, not too long and not too many. You risk being left aside if you go too far.
- add your system specs, just important components. They are probably going to ask about it, so better cover it from the beginning.
- explain the problem, steps to reproduce.
- tell them you already have the latest GOP for your card, but don’t tell them how you got it. They will use this “custom firmware” as an excuse to close your ticket without solving it.
- show that there is already a confirmation and a fix for this issue. See the links above. The actual fix is in the PciBus module.
- you could try to ask for all further fixes to be added into this new UEFI, but consider that they might also push new bugs.
- if they don’t fix this, you will know how to thank them on your next purchase.

I’m sure they won’t fix anything besides major bugs and this will not be considered major by any means. To fix that kind of bugs you need to make a tree upgrade from AMI source control server, which will be very painful because of the amount of time passed since the latest release (huge changes to pretty much anything). Then you need to port all your own changes, rewriting some parts that aren’t working because of the updated tree, then you need to test the result on all available boards in different setups to ensue nothing gone wrong, and still some bugs will always lurk in your new code waiting to f*ck everything up on the user side.
That is why no one will ever touches old BIOSes code - it’s too much effort for nothing, buying a newer board it actually cheaper than fighting with tech support here.

This might sound silly coming from someone who doesn’t know such things, but if they have fixed this problem on other almost-identical motherboards, can’t they just “port” the fix?

Sure. But as far as I know ASUS they have the same BIOS tree for almost all boards, so they can just recompile it without any porting, if it’s already done. The problem is that the whole thing is hard and makes no sense from the developer’s point of view.

I guess it doesn’t hurt to try contacting Asus although from a very similar personal experience I had with ASRock you will probably not even get a reply. Still, I suggest that OP checks this card on a pure UEFI system just in case.

Truth is, that when looking at this from a consumer’s perspective it feels shity to have a motherboard that is not working properly even though it was designed to. This a 6-series board so yeah originally it did not have UEFI support but since Asus decided to update them to UEFI & ME8 they have to do a good job at it.

Anyway, if nothing comes out of it maybe someone in here (lordkag?) can try to port the fix (if that’s possible by anyone except Asus that is).

I have an open case with Asus and they do reply once a day. I’ll relay as much information I can give them and hope they release a new BIOS revision for this specific issue.

There is nothing any of us can do. Here are the real changes between 4001 and 4003:

4001_vs_4003.jpg



From that, only PciBus relates to this GOP issue. Sadly, not only the changes from 4001 to 4003 are all over the place (plus new code added), but P8Z68V_LX and P8Z68V_LE use a different code base than other P8Z68-V boards. So there is no possible way to port this in hex, no way to take that file as is. PciBus is marked as EFI Boot Driver, so you will brick your system faster than a speeding bullet.

But I see that they updated P8Z68V_PROGEN3 at 2014/11/17, almost two years after previous release. So, they haven’t abandoned this completely, although no real fixes like in the other branch. This is the big issue here: why didn’t they ported this at the release time, when it would have been easier and a big plus for them?

They probably forgot or maybe they check how popular certain old boards are and decide based on that if they should spent people on fixing them? Either way, some pushing by kevindd992002 may make then reconsider.

I had a similar issue with ASRock where they had updated other almost identical models with a fix (some sleep issue when installing 4GB of ram only, serious stuff) but not my board. I asked then nicely but not even a single reply. I ended up cross-flashing and the problem was fixed. That’s how similar these boards were (I think the only difference was an extra PCI-E lane or so).

EDIT: Not that I suggest cross-flashing in this case. Not at all, just sharing an older similar experience I had with another OEM.

If ever ASUS fixes my issue, I can right away just switch from Legacy to EFI Compatible without any ill-effects on the already-installed Windows on my machine, right? If I understand correctly, Legacy/EFI only affects the drivers during boot time (pre-OS).

Did you try the gpu on a CSM-disabled system to rule that out as a problem source?



Not yet, I haven’t gone to my other house yet where the CSM-disabled computer is. But like lordkag mentioned, it could highly be the ASUS board being the issue.

I wanted to update this thread and some further advices from you guys. Well, ASUS gave me a beta BIOS to try out. I flashed over that BIOS revision and it worked just fine, I even got into Windows and EFI boot was working already. Now I restarted the machine, went into the BIOS setup page and disabled the “full screen logo” and did the save settings and restart. After that, the board won’t POST at all. The VGA_LED is now solidly lit red and it doesn’t go past that.

I’ve already tried clearing CMOS by using the 3-pin header, removed the CMOS battery, removed all GPUs and tried using just the onboard GPU and it still doesn’t work. When I google for this problem, it seems that this is a very common problem for this board when updating the BIOS. The beta BIOS that they gave is the one that caused it, definitely. I’ve flashed this board several times without any problems but this time it just failed on me.

Is there a way to flash back an older version if the board can’t even pass POST? If worse comes to worst, can a universal K150 PIC programmer work in hopes of flashing the stable ROM file for the chip? The BIOS chip is easily removable from the board. I can buy a pic programmer locally for just about $10 here but I’m not sure if it’ll work?

@ kevindd992002:

If you really are not able to flash any working BIOS into your mainboard BIOS chip, I recommend to contact the ASUS Support and ask for a new BIOS chip. It has been at least their Beta BIOS, which had bricked your mainboard.