"UEFI Boot" is in green, so it means it is enabled, if we should trust the software. The "Not capable" message is definitely a bug, probably related to the fact that your BIOS is more than two years old. But it is still UEFI. More than that, how could you have UEFI Boot without an UEFI firmware? Even my old laptop is seen as "UEFI Capable" (but not UEFI Boot) and its last release was in 2010. You can report this bug in their forums, they should fix it fast. Every BIOS released after 2012 should be in fact UEFI, unless it was a bugfix of a very old release.
Did you guys know that it’s possible on the P8Z68 to disable CSM through AMIBCP as ‘CSM Support’ is a hidden menu option so theoretically you could disable CSM by hard coding it into the bios optimized settings. If only there was a way to unhide that menu option?!
Edit: Can someone test this rom to see if it has a uefi gop?
https://www.dropbox.com/s/eggv04exrs10yoe/GK110.rom?dl=0
Thanks
Thanks for the info. I didn’t know that.
When I am back home and have the needed time, I will do some tests with my old ASUS P8Z68-V mainboard.
It seems to be an old GPU BIOS v80.80.31.00.82 for the NVIDIA GTX 780 graphics card. I don’t know, whether this BIOS supports UEFI GOP.
Interesting. I hope you can work on the CSM support more.
By the way, ASUS gave me a new BIOS for my ASUS P8Z68-V/GEN3 board that works when “EFI compatible” is chosen in the BIOS. Apparently, they fixed the problem but I’m not sure what the changelogs are.
If I post the BIOS in this thread, can you guys look at the difference in code?
Anyone from our BIOS module experts may be able to analyze the differences.
Lordkag usually does such comparisons effectively. So yes, it’s very much possible. Also, this beta BIOS might be useful for other people with the same board that are facing the same issues. Unless Asus has updated the support page with the new BIOS I don’t see why not share it here.
These are the changes:
To be fair, there were many files that had a different CRC, but after removing the date stamp with a script, this is the result. In green you have the files that had only cosmetic changes, like new version and a new compilation date. In blue I have selected the files that have little chances to be related to the topic’s problem. Only those in red could be related, where AMITSE and CORE_DXE come first, while CSMCORE and BIOSBLKIO are less likely to fix the problem.
So to sum it all up, what do you think they really did in this BIOS? Just more on cosmetic changes that "led me to believe" that they fixed it? I’m not sure if using this beta BIOS would be better than using the latest published one.
Hi,
I did a little trouble shooting and found on one of my systems having more than one gpu installed in a pci-e slot causes a failure in pure efi boot mode with CSM disabled.
This is a Gigabye Z87X-UD5h motherboard with a EVGA 770GTX videocard that according to nvflash --version has a UEFI compatible GOP. I also had a second 740GT video
card with UEFI firmware. Swapping each card or booting with the onboard gpu was as easy as can be unless I plugged in more than one video card where the system
would hang on the boot logo. This is remarkably similar to my P8Z68 Deluxe gen 1 board with two 780GTX’s in there. Unfortunately that board doesn’t have an dGpu
port though I am willing to bet it would post if I had only one video card in there!
I mean I have no trouble booting with just one video card.
Thanks
I never said that the changes are more on the cosmetic side. The simple fact that they fixed your issue is a proof that the changes are present and effective, the other proof is the changing size of the components selected in red. What I really said is that :
- the changes selected in green are just inertial changes, like version, compilation date, SLIC code etc.
- the ones in blue are real changes, but not related to this topic: AINT13 (AHCI) and USBINT13 are for Interrupt call 13, ASUS_EUPPEI is for EUP, PchS3Peim and S3Restore changes are probably related to a flaw in the UEFI code, AsusPostErrPei is for POST errors like CMOS fail, chassis etc., the freeform is ACProtect dll, SMBios64 is SMBIOS and OCMR seems to overclocking related. All these changes are rather small in code, maybe simple bugfixes or even refactoring/reallocation.
- the ones in red are big changes: CSMCORE for CSM, AMITSE for Text Setup Environment (but is much bigger than that, it impacts the UEFI menu, it can trigger ME recovery in Asrock) and CORE_DXE is the foundation of DXE drivers.
If this one works for you, keep it, there is no doubt about it.
Great! I’ll do that. How about overclocking potential? Since there are OC’in-related changes, is it safe to assume that the OC’ing potential would be affected either positively or negatively? I’m not sure if I need to re-do my overclock to get a better one.
I don’t see the changes so important as to affect the overclocking, neither in good nor in bad. But it is always a safety measure to reset to defaults before flashing, again reset after flashing, shutdown and only after that re-apply your settings. If you were talking about testing for new overclocking potential, I wouldn’t do that, unless you have problems with current settings or have the time to do it.
Hi kevindd992002,
I had the exact same problem as you described in your first post and I’m curious if we have the same mobo. If they are the same I’m thinking of trying out the BIOS you posted.
Is your board an ASUS P8Z68-V Pro/Gen3?
That’s exactly the process I’m performing when flashing new BIOS revisions, so no problem with that. Regarding the vBIOSes of my GTX 670 cards though, are the ones you edited still the latest GOP’s?
Mine is the non-PRO version, sorry, but I’m sure you can request one from ASUS.
Ok thanks
That is why I have written this script. I can’t make it to run on its own. I mean I could, but this would be consistent with a virus activity. I always try to help others to the best of my abilities, but come on guys, isn’t it possible for you to make one little step, when I have already walked the rest of the mile? Is it so hard to comprehend the days/weeks invested in the code, the days of testing, the hours of torment regarding if I should publish this sloppy code, not to mention the background knowledge which doesn’t come in a day or two - and try to be at least supportive by running the tool just once before asking such questions? Your only reasonable excuse would be that you missed that thread, but it has been here for days and it had a few replies, so it is less likely. Let me do that for you:
That is why I have written this script
That’s exactly my excuse, I apologize. I’m not really active in looking for other threads as I’m relying more of email notifications from subscribed threads because of me being very busy at work lately. Regardless, I should’ve seen that thread and I will definitely give it a try. Thanks again.
Thanks Lordkag! Solved a conflict I was having and I did the gop update and flash myself!