Forum - RE: AMD and Nvidia GOP update

Win-Raid Forum (Drivers - Firmware - Modding) � BIOS Modding � BIOS Modding Guides and Problems � AMD and Nvidia GOP update (No requests, DIY)

Page 5 of 92 � Page 1 2 3 4 5 6 7 8 9 ... 92 Page �

Topic settings

Print view

Jump to forum

General & Forum related Topics News / Announcements Forum-related Questions & Suggestions Off Topic Important Drivers (AHCI/RAID, NVMe, USB etc.) General: Storage Drivers (AHCI/RAID, NVMe and USB) Specific: Intel AHCI/RAID Drivers Specific: NVIDIA nForce Chipset Drivers (incl. AHCI/RAID) Specific: NVMe Drivers Other Drivers System Performance RAID Performance AHCI/NVMe Performance Solid State Drives BIOS Modding BIOS Modding Guides and Problems BIOS modules (PCI ROM, EFI and others) BIOS Modding Requests Reports: BIOS Modding Results Offers: Already modded special BIOSes Special Topics Intel Management Engine CPU Microcodes NVMe Support for old Systems Other Tools (not BIOS modding related) Interesting PC Hardware & Software OS related Topics Windows 11 Windows 8-10/Server 2012-2019 Windows 7/Vista/Server 2008 Windows XP/2000/Server 2003 DOS/Windows 3.X/9X/ME - Retro Gaming Other Operating Systems

#61 | RE: AMD and Nvidia GOP update datum

Fri May 22, 2015 11:23 pm (Last edited: Fri May 22, 2015 11:27 pm)

@RoughBoy
@davidm71

The problem with your board is not Fast Boot/Secure Boot, since it didn't supported this from the beginning. If it were about adding Fast Boot to an older board, it would have been understandable from Asus part. But your problem is that you have an option "PCI ROM Priority" that lets you boot from EFI drivers instead of Legacy ROM. And this is broken, with Asus already been aware of the problem and a fix in their hands. Try to explain it better and stand for your rights. They shipped a broken UEFI firmware from the beginning, so they should at least try to offer what it was promised at the time of release, nothing more. This is not about performance or Fast Boot, it is about a bug in their code that prevents you from running your board to full potential with the options Asus provided. If other OEM can fix older legacy boards for ROM space issues, why is it that Asus can't fix an UEFI board?

@Sylar76

Thank you for the file, it has been added.

Version 1.6
- updated GM2xx to 0x2000A
- added AMD to database check. But this one will be difficult to follow. I have only started to add some GOPs and it is already grown with several types for the same version. Will think of what to keep if things get out of control.
- the temp folder will not be removed if the GOP is not in database

reply

#62 | RE: AMD and Nvidia GOP update datum

Sat May 23, 2015 12:14 am

I know that and was very explicit in filling out the asus test report form. The fact the bios has a bug is what bothers me and that some manufacturers forget about a product not long after release. Personally I find legacy boot satisfactory but would love if they fixed their bugs.

reply

#63 | RE: AMD and Nvidia GOP update datum

Sat May 23, 2015 1:53 am (Last edited: Sun May 24, 2015 5:28 pm)

@lordkag

Note 1: All the stuff below were done using the (now) older GOPUpd v1.5.
Note 2: To make the job slightly less consuming, I added the line "os.remove(file_dir)" whenever "GOP is not present!!!" was reported.

Today I tested GOPUpd with 10010 vBioses and these are the results:

AMD:

ALL --> There was no repository at v1.5 so I have included all 263 vBIOS images which have a GOP of some sort inside. There is nothing newer than 1.58.0.0.0, only older stuff.
APPLE-UNCOMMON --> These are Apple vBIOS images and of course they are different. Classic Apple.

NVIDIA:

ALL --> In case I missed something at the following folders, I have included all 500 vBIOS images.
DUAL MONITOR --> These are Dual Monitor vBIOS images. Included is an OEM release-note document from Nvidia. Is that the Multi-Display firmware you were looking for?
MXM --> These are MXM vBIOSes, reported as unsupported. One of them is at the repository (kept for testing), the rest are new.
NOT IN DB --> Images which are not at the repository, old but missing from the DB.
OTHER --> A .exe update which I don't know how to properly extract. GOPUpd does find a GOP inside but I suspect it may hold more than one. Manual hex checking is required.
UNCOMMON --> A Clevo vBIOS that reports "Not GOP or GOP is not common type. Please report it!".
UNKNOWN --> Images that are GOPs but report "Unable to determine GOP type!"

PROBLEM:

A 2011 vBIOS from an AMD FirePro V5900 which causes an error. It either has an ancient AMD GOP (0.0.1.18.5) or it's accidentally detected as having one. The latter is most probable. Either way, manual hex checking is required.

FORUM:

The 0x2000A GOP, ignore it.

vBIOS Collection 22-05-2015:

All 10004 vBIOS images from TechPowerUp, updated as of 22/05/2015. Everything below 120KB certainly do not have a GOP inside. Warning: That 30.1MB archive extracts a 881MB folder (3% compression - RAR5 256MB).

Download Link: http://www.mediafire.com/download/vcl6tj...for_Lordkag.rar

EDIT 24/05/2015:

Attached GK1xx_MXM 0x1002A GOP

plutomaniac has attached files to this post

GK1xx_MXM 0x1002A.rar

reply

#64 | RE: AMD and Nvidia GOP update datum

Sat May 23, 2015 11:11 am

@plutomaniac

Hi, could you tell me why the 0x2000A GOP update should be ignored ?

reply

#65 | RE: AMD and Nvidia GOP update datum

Sat May 23, 2015 2:15 pm

Zitat von Sylar76 im Beitrag #64
Hi, could you tell me why the 0x2000A GOP update should be ignored ?

Because it's already included at GOPUpd v1.6, no other reason. As I said at Note 1, all the above were done using the older v1.5 version of the tool.

reply

#66 | RE: AMD and Nvidia GOP update datum

Mon May 25, 2015 11:13 pm (Last edited: Mon May 25, 2015 11:39 pm)

@plutomaniac

I took some time to reply, because I wanted to get the entire collection parsed and supported. I can't thank you enough for the collection and I will add a few more words at the end.

Zitat von plutomaniac im Beitrag #63
Note 2: To make the job slightly less consuming, I added the line "os.remove(file_dir)" whenever "GOP is not present!!!" was reported.

When doing mass searches, it is easier to add a sys.exit() right before "Do you want to update GOP...". It is also easier to place all ROMs in one folder and use XSearch with hexadecimal string F10E0000, which is 00000EF1 in little indian. Only the EFI ROM has this string.

Zitat von plutomaniac im Beitrag #63
AMD - There was no repository at v1.5 so I have included all 263 vBIOS images

By looking at the current database file, I would have never added AMD GOP for checking when the version is lower than 1.53.0.0.0, it is just impossible to capture them all. But now that I have a big collection of files, it seemed like a small step to do.

Zitat von plutomaniac im Beitrag #63
These are Apple vBIOS images

I have added a version display for Mac GOPs, if there is a version to be found. But I have only a few samples and the EFI is not recognized by either AMD/Nvidia tools, so it is an Apple made EFI driver, with a big chance that the structure will change between different cards and different versions.

Zitat von plutomaniac im Beitrag #63
Is that the Multi-Display firmware you were looking for?

This is only an example, not a real image, but the multi-display should look like this:

Zitat von plutomaniac im Beitrag #63
These are MXM vBIOSes, reported as unsupported.

I have added GK1xx_MXM and GM1xx_MXM to the updater. With GM2xx there seems to be a single image, while GFxxx and GT21x are less likely to be found as MXM GOP.

Zitat von plutomaniac im Beitrag #63
A .exe update which I don't know how to properly extract.

This one is similar to the two .run files and they are packed as following:

But only one image is OK, the rest are mixed. I can't get them properly unpacked and they don't seem compressed, because I even tried to dump the region of the running process. Maybe they are using a packing similar to xdelta, maybe it is a packing related re-structure, I don't know. The .run files are OK, since they have only one ROM image.

Zitat von plutomaniac im Beitrag #63
A Clevo vBIOS that reports "Not GOP or GOP is not common type. Please report it!".

I don't know what to think about that uncommon Clevo. It looks like a normal Nvidia GOP and it is MXM, but no tagging what so ever.

Zitat von plutomaniac im Beitrag #63
Images that are GOPs but report "Unable to determine GOP type!"

One way to determine the GOP type for Nvidia, when the ID is missing, is to inspect the first ROM image, which usually has "GXxxx board" message. That is, if they don't mix the GOPs. I plan to add this as a hint message, when the type can not be determined.

Zitat von plutomaniac im Beitrag #63
A 2011 vBIOS from an AMD FirePro V5900 which causes an error.

I fixed that AMD FirePro V5900, which looks like a really old version. I don't want to bash AMD, since they try to open source some good stuff, but they don't have a clear set of standards. And it is not just about the version in GOPs changing to a different structure all the time, the same thing happens with microcodes and other firmwares.

Zitat von plutomaniac im Beitrag #63
All 10004 vBIOS images from TechPowerUp, updated as of 22/05/2015.

Pardon me, my fair knight, but your collection is missing one file, not to mention you missed some GOPs. I refuse to accept an incomplete collection. Do you actually expect me to do some work?

Of course, this was a bad joke from my part. It had crossed my mind to get the database from techpowerup, but I would have never found the courage the get the job done. I'm afraid to ask you how you got it, I will just assume you know someone there, so I can sleep better. At first, when I saw that you mention a few hundreds AMD files and other few hundreds Nvidia files, I was wondering if my math or yours is broken. I could not find those 10004 images in the folders and was browsing the archive with WinRar using the tree view, so I managed to miss that other archive. After parsing that folder with XSearch, getting files with F10E0000 content and comparing with your folders, I got 8 extra files + 1 newly published. From those 8, one was a false positive, two were badly compressed (not even ATIFlash was able to unpack them) and 5 were regular Nvidia, nothing new.

Your collection reminded me that there is another old collection of techpowerup. After updating the database with your collection and parsing that old one, I can say he is right, they don't publish all files. Around 75 files were not in database and by extension not present in your collection, not counting those that are already in the database. Even so, your collection is a big step forward, so you have another thank you from me. I will search HP and Lenovo for more images, maybe also MSI and Gigabyte. Asus is using a tool to retrieve the newer versions, so it is a no go, others might not publish VBIOS files or are just old versions.

Another release, version 1.7 :
- added GK1xx_MXM and GM1xx_MXM
- updated GM1xx to 0x10030
- fixed AMD version until it will be broken again
- added Mac version display. Only AMD works well, Nvidia is missing the version most of the times.
- enabled Mac GOP replacement, but the validity of the new image falls in user's hand. Drop the compressed image as mac_gop.efirom in GOP_Files. Then check the resulting file on your own. I have only a few samples of Apple images and no intention of supporting them.

reply

#67 | RE: AMD and Nvidia GOP update datum

Tue May 26, 2015 1:03 am

Zitat von lordkag im Beitrag #66
When doing mass searches, it is easier to add a sys.exit() right before "Do you want to update GOP...". It is also easier to place all ROMs in one folder and use XSearch with hexadecimal string F10E0000, which is 00000EF1 in little indian. Only the EFI ROM has this string.

Because I was dealing with thousands of files, I wanted to automatically delete those that didn't have a GOP inside. Unfortunately I didn't have a searcher like XSearch that could detect HEX so I decided to modify the python script slightly to do that for me. A searcher would have made this easier indeed, especially now that I know what hex bytes to look for exactly. I have added such a feature at ME Analyzer as well which helps immensely. It scans all the files with no user intervantion and if something new is found the file stays intact, everything else is deleted on the spot. Thus, in the end I may end up with let's say 20 "new" files from the original 1200.

Zitat von lordkag im Beitrag #66
I have added a version display for Mac GOPs, if there is a version to be found. But I have only a few samples and the EFI is not recognized by either AMD/Nvidia tools, so it is an Apple made EFI driver, with a big chance that the structure will change between different cards and different versions.

Apple has this obsession to change everything, modify it and make it their own. Well after seeing custom ME firmware, I should have expected this as well I guess.

Zitat von lordkag im Beitrag #66
This is only an example, not a real image, but the multi-display should look like this:

Yes I saw it at the python script but I wondered whether there was a mistake or similar with it's detection. Better safe than sorry.

Zitat von lordkag im Beitrag #66
But only one image is OK, the rest are mixed. I can't get them properly unpacked and they don't seem compressed, because I even tried to dump the region of the running process. Maybe they are using a packing similar to xdelta, maybe it is a packing related re-structure, I don't know. The .run files are OK, since they have only one ROM image.

It's an Nvidia update executable of sorts. I know it includes a lot of GOPs because the text file accompanying it mentioned around 5 different vBIOS versions for different cards. Generally those Dual-Monitor, custom Nvidia .exe files etc are all from Dell.

Zitat von lordkag im Beitrag #66
I don't know what to think about that uncommon Clevo. It looks like a normal Nvidia GOP and it is MXM, but no tagging what so ever.

I will search at some point the Clevo BIOS mirror site because it also includes their updated MXM vBIOS. If it's a pattern then maybe more investigation is required. Otherwise, I don't know, maybe that specific file had some issue.

Zitat von lordkag im Beitrag #66
One way to determine the GOP type for Nvidia, when the ID is missing, is to inspect the first ROM image, which usually has "GXxxx board" message. That is, if they don't mix the GOPs. I plan to add this as a hint message, when the type can not be determined.

Oh the Sign-On message, yes I see. I'll keep that in mind. Hopefully they don't mix and match GOPs though (as you said)...

Zitat von lordkag im Beitrag #66
It had crossed my mind to get the database from techpowerup, but I would have never found the courage the get the job done. I'm afraid to ask you how you got it, I will just assume you know someone there, so I can sleep better.

Nope, I wish. Thing is, if they allowed listing of more than 50 images per page I would have finished acquiring the links in 2 minutes. But, because they allowed 50 links per page of a total of 201 pages (thus 10004 images because the latest page had 4 only) it took around 45. I use a chrome extension called Linkclump which allows me to select a big list of links and automatically copy them to clipboard among other things. So for every page of the 201, I formed a box with the mouse and those 50 links were copied to the clipboard automatically. From there, I used Internet Download Manager which has a feature to automatically grab clipboard links. So the procedure was load next page, copy all 50 links, get grabbed by IDM and added to Queue. Multiply this by 201 times and bingo. The procedure afterwards of modifying the script and loading 200 files a time at GopUPD (because it doesn't accept more, batch limitation) was a whole other "time beast".

Unfortunately, there is no way to determine when new roms are updated at the collection and where they are placed. Yes, I would for example now see 202 pages but I wouldn't know where the new files are. It could be page 2, page 69, page 200 etc. So, this collection cannot stay up-to-date unless someone does the same thing in the future.

Zitat von lordkag im Beitrag #66
At first, when I saw that you mention a few hundreds AMD files and other few hundreds Nvidia files, I was wondering if my math or yours is broken. I could not find those 10004 images in the folders and was browsing the archive with WinRar using the tree view, so I managed to miss that other archive. After parsing that folder with XSearch, getting files with F10E0000 content and comparing with your folders, I got 8 extra files + 1 newly published. From those 8, one was a false positive, two were badly compressed (not even ATIFlash was able to unpack them) and 5 were regular Nvidia, nothing new.

I'm surprised I didn't miss more "valuable" files to be honest. Most probably those 9 extra files were deleted by my code addition because GopUPD reported the GOP not present error. Still, it's good that you double checked.

Zitat von lordkag im Beitrag #66
Your collection reminded me that there is another old collection of techpowerup. After updating the database with your collection and parsing that old one, I can say he is right, they don't publish all files. Around 75 files were not in database and by extension not present in your collection, not counting those that are already in the database. Even so, your collection is a big step forward, so you have another thank you from me.

Honestly I was surprised that GOPUpd showed such few "errors" after being tested with so many files (10000+)! You have done a great work, that's all I have to say.

reply

#68 | RE: AMD and Nvidia GOP update datum

Wed May 27, 2015 10:19 pm

Wow, awesome developments here since i checked last time... Newer GOP already incorporated and flashed!

It seems that when CSM is set to auto or disabled, my board can't handle bootup with two (identical) graphics cards installed though. When turning my system on, display is initialised but nothing more happens...
I tried this with the original Asus GOP-vbios as well, same result. So i guess there's a persistent bug somewhere.
When i enable CSM and force UEFI on my boot device and PCI-E expansion devices,all goes well. This is with a Asus Crosshair V/F-Z and 2x Asus gtx660.

reply

#69 | RE: AMD and Nvidia GOP update datum

Wed May 27, 2015 11:11 pm (Last edited: Wed May 27, 2015 11:14 pm)

If you enable CSM and force UEFI on devices, it will most likely default to Legacy when GOP is not loaded. But have you tried with only one card, can it boot then? If it works, it might be the mainboard's UEFI firmware and a bug report to Asus could make them to fix it. Also, do you have the latest BIOS/UEFI 2201 for your mainboard?

The GOP version is pretty much updated, there is only one new update - 0x10030 - that I need to track down. I trust Nvidia would have found and fixed such a simple bug like yours by now. I know that Davidm71 had a similar issue with two cards, which was fixed with a GOP update, meaning that Nvidia did their work. So try with one card and report to Asus if it works.

reply

#70 | RE: AMD and Nvidia GOP update datum

Thu May 28, 2015 12:32 am

Zitat von lordkag im Beitrag #69
If you enable CSM and force UEFI on devices, it will most likely default to Legacy when GOP is not loaded. But have you tried with only one card, can it boot then? If it works, it might be the mainboard's UEFI firmware and a bug report to Asus could make them to fix it. Also, do you have the latest BIOS/UEFI 2201 for your mainboard?

The GOP version is pretty much updated, there is only one new update - 0x10030 - that I need to track down. I trust Nvidia would have found and fixed such a simple bug like yours by now. I know that Davidm71 had a similar issue with two cards, which was fixed with a GOP update, meaning that Nvidia did their work. So try with one card and report to Asus if it works.

I had the same problem fixed with GOP update. He should first troubleshoot with one card installed and update gop if needed.

reply

#71 | RE: AMD and Nvidia GOP update datum

Thu May 28, 2015 1:58 am (Last edited: Thu May 28, 2015 1:47 pm)

Hi lordkag, thanks for the powerful tool. Here are the outputs from my tests.

Video card: XFX HD 7870
Shipped with this VBIOS: http://www.techpowerup.com/vgabios/12628...048-120420.html

Sadly XFX won't update it, but I managed to add the GOP driver from a similar PowerColor model a while back. The interesting thing is that it contains an ACPI table "VFCT", which in turn seems to represent a small part of the VBIOS and influences the cards clocks, probably among other things.

1.1) Adding the GOP driver to the original, legacy only VBIOS. The resulting MD5 hash is A5D00C8BECB8607D00EDB82BD61ED4FE.

1.2) Checking the GOP version of the new file

************************** GOPupd 1.7 **************************

************************ Update EFI GOP ************************

***************** Drop VBIOS file on this .bat *****************

Dumping info from = orig_updGOP.rom

ID of ROM file = 1002-6818

***************************************************************
*** Extracting with UEFIRomExtract by AndyV ***
***************************************************************

Found compressed EFI ROM start at 0x58
Input size: 58280, Output size: 105128, Scratch size: 13360

---------------------------------------------------------------

***************************************************************
*** Extracting with Python... ***
***************************************************************

AMD GOP 1.58.0.0.0 LibBuild ---- Dated: Feb 17 2015 15:41:41

AMD_Build 156 AMD_ChangeList 1122881 GOP BIOS_IDTF 0xDEADBEEF

Most likely signed by: Microsoft Corporation UEFI CA 2011

Machine Code = x64

Checksum CRC32 = F047653C

---------------------------------------------------------------

***************************************************************
*** Processing with GOPupd... ***
***************************************************************

You already have the latest available GOP!

---------------------------------------------------------------

Press any key to exit..

2.1) Updating the GOP driver in a custom VBIOS (attached). The resulting hash is C36B7E06A477630DC146868E4B7DB7DC.

************************** GOPupd 1.7 **************************

************************ Update EFI GOP ************************

***************** Drop VBIOS file on this .bat *****************

Dumping info from = mod.rom

ID of ROM file = 1002-6818

***************************************************************
*** Extracting with UEFIRomExtract by AndyV ***
***************************************************************

Found compressed EFI ROM start at 0x5c
Input size: 61348, Output size: 104632, Scratch size: 13360

---------------------------------------------------------------

***************************************************************
*** Extracting with Python... ***
***************************************************************

AMD GOP 1.46.0.15.32 LibBuild 2208 Dated: Feb 14 2013 14:08:53

AMD_Build 257145 AMD_ChangeList 885532 GOP BIOS_IDTF 0xD1DDFF2F

AMD GOP has tables! Customized GOP with legacy parts!!

Legacy BIOS_IDTF 0xD1DDFF2F

Most likely signed by: Microsoft Corporation UEFI CA 2011

Machine Code = x64

Checksum CRC32 = 4564C35A

---------------------------------------------------------------

***************************************************************
*** Processing with GOPupd... ***
***************************************************************

Latest available GOP is 1.58.0.0.0

Do you want to update GOP to 1.58.0.0.0? Y for yes or N for no: Y

Fixing ID for EFI image. No checksum correction is needed.

Removing unnecessary end padding.

File "mod_updGOP.rom" with updated GOP 1.58.0.0.0 was written!

---------------------------------------------------------------

Press any key to exit..

2.2) Checking the GOP version of the new file

************************** GOPupd 1.7 **************************

************************ Update EFI GOP ************************

***************** Drop VBIOS file on this .bat *****************

Dumping info from = mod_updGOP.rom

ID of ROM file = 1002-6818

***************************************************************
*** Extracting with UEFIRomExtract by AndyV ***
***************************************************************

Found compressed EFI ROM start at 0x58
Input size: 58280, Output size: 105128, Scratch size: 13360

---------------------------------------------------------------

***************************************************************
*** Extracting with Python... ***
***************************************************************

AMD GOP 1.58.0.0.0 LibBuild ---- Dated: Feb 17 2015 15:41:41

AMD_Build 156 AMD_ChangeList 1122881 GOP BIOS_IDTF 0xDEADBEEF

Most likely signed by: Microsoft Corporation UEFI CA 2011

Machine Code = x64

Checksum CRC32 = F047653C

---------------------------------------------------------------

***************************************************************
*** Processing with GOPupd... ***
***************************************************************

You already have the latest available GOP!

---------------------------------------------------------------

Press any key to exit..

The files produced after the steps 1.1) and 2.1) are different, but this is due to the dirty way of fixing the checksum by changing the last byte of the legacy part, I guess.

I didn't test the resulting VBIOS yet, as I am quite happy with the situation right now. But I will do so in a couple of days.

PS: Hopefully the abscence of screenshots doesn't bother you too much :-)

EDIT:

I am using the updated VBIOS without the CSM now, everything seems fine.

k3nny has attached files to this post

mod.zip

reply

#72 | RE: AMD and Nvidia GOP update datum

Thu May 28, 2015 2:47 am (Last edited: Thu May 28, 2015 2:55 am)

I got the same results and everything seems fine, there should be no issues in flashing this image. And you are right, the different hash comes from the fact that you changed the last byte, while I change the AMD checksum byte. But this has no practical importance.

The story with the legacy tables in GOP goes like this. The GOP driver needs to be signed to pass Secure Boot and to ensure no malware has been added to the code. But at the same time the GOP driver needs to load some configuration data, which can be found on the unsigned legacy ROM. To solve this breach of trust, the vendors have three solutions: 1 - copy the configuration data in GOP, which increases size, increases time in debugging, endless trouble with signing multiple images; 2 - apply an authentication to both legacy and UEFI; 3 - hash the legacy ROM and let the GOP driver authenticate it. First one is sometimes used by AMD, the third is always used by Nvidia in newer cards. I don't know if Nvidia is hashing the entire image or just the legacy ROM, but if they hash only the legacy part and the image already has a GOP, then my script should not break the hash, since I only replace the EFI ROM, which has a compressed, untouched and signed GOP driver. If they hash the entire image, I don't know what this will do to Secure Boot, but I haven't seen anyone complaining about failed boot in the GPU modding forums. Probably only legacy is hashed or the hash is checked by the nvflash during flash.

Starting with version 1.53.0.0.0 AMD has abandoned this convoluted solution and is offering a universal GOP for all cards, loading the configuration data from legacy. But they don't use any hashing method for legacy ROM, leaving the door open to any sort of modification.

For your card, I recommend to update to latest GOP if you plan on using Fast Boot or Secure Boot. Not only you will have the latest version, but you will avoid using the tables from another card, which might not be entirely good for your card.

reply

#73 | RE: AMD and Nvidia GOP update datum

Thu May 28, 2015 2:17 pm (Last edited: Thu May 28, 2015 9:17 pm)

Zitat von lordkag im Beitrag #69
If you enable CSM and force UEFI on devices, it will most likely default to Legacy when GOP is not loaded. But have you tried with only one card, can it boot then? If it works, it might be the mainboard's UEFI firmware and a bug report to Asus could make them to fix it. Also, do you have the latest BIOS/UEFI 2201 for your mainboard?

The GOP version is pretty much updated, there is only one new update - 0x10030 - that I need to track down. I trust Nvidia would have found and fixed such a simple bug like yours by now. I know that Davidm71 had a similar issue with two cards, which was fixed with a GOP update, meaning that Nvidia did their work. So try with one card and report to Asus if it works.

Wait..what?!? When i launched my pc today, and the Windows 10 logo appeared,i was on my desktop only 6 seconds later... That's less than half the time it used to be! Rubbed my eyes..rebooted..same result!
I already had the latest mainboard bios flashed,combined with the 1002D vbios GOP on both gfx cards.
Haven't changed anything else,so it must be the newer 1002F GOP that is responsible for this. Not sure why this didn't happen after a warm boot.
Lol.. will try
-to see how CSM responds now ->edit-> same bad behaviour when turning it off
-retry 1002D GOP to see if startup -> edit-> time is decreased again. -> erratic results,sometimes system boots fast and sometimes not. Something dodgy going on. Win 10 needs 2 cold boots to accumulate.
-to run with only 1 card and see how csm responds ->edit -> This was fine, a 1 card setup does not mind if i set CSM to Auto, Enabled or disabled!

I have to add an interesting and weird discovery. I use KGB to edit my vbios'es and raise the power target of my cards.
When i've done a fresh flash of the cards and boot into uefi mode,there is no way to raise the power target..as if the vbioses were not modded.
When i force my PCIE devices to boot in legacy mode,i can raise the power target again. When put back in UEFI mode,i can still raise it.
But, Windows would still prefer to boot in legacy mode then... To solve this i had to disable the fast-boot feature in Windows, and re-enable it! After that, fast boot and graphics cards are power tweakable.

Final thoughts..it seems that a single card bootup/CSM disabled is about as fast as a dual card with CSM and forced UEFI... maybe the first part of system initialisation is a bit faster,but windows startup is just as fast.
I'll still see to contact Asus and see what they have to say!

reply

#74 | RE: AMD and Nvidia GOP update datum

Thu May 28, 2015 10:50 pm

For starter, I don't think Win 10 can be used as a reference, since it is not even RTM released, let alone having important updates. If I were you, I would test this on Win 8.1 with all updates. There are two other things to consider:

- if one card is working with CSM disabled, most likely it is an Asus bug, since the GOP is already updated. So try with Asus first.
- your different results with booting speed and power target might be determined by the way Fast Boot works. That hibernation part could prevent the system from fully updating with new conditions. So a proper full shutdown (or restart) is recommended. And since you updated the firmware, a reset to defaults is also a good way to ensure that the system has integrated all new components.

reply

#75 | RE: AMD and Nvidia GOP update datum

Fri May 29, 2015 7:44 pm (Last edited: Fri May 29, 2015 7:46 pm)

Zitat von lordkag im Beitrag #74
For starter, I don't think Win 10 can be used as a reference, since it is not even RTM released, let alone having important updates. If I were you, I would test this on Win 8.1 with all updates. There are two other things to consider:

- if one card is working with CSM disabled, most likely it is an Asus bug, since the GOP is already updated. So try with Asus first.
- your different results with booting speed and power target might be determined by the way Fast Boot works. That hibernation part could prevent the system from fully updating with new conditions. So a proper full shutdown (or restart) is recommended. And since you updated the firmware, a reset to defaults is also a good way to ensure that the system has integrated all new components.

Thanks for all this! Will do some more testing with win8.

I have been emailing with Asus now...i started with clearly explaining things > they tried to give me the run around,by saying it's Win10's fault > responded that i had clearly stated that system wont even post with 2 gfx cards and CSM disabled,and OS does not even get a chance > now they are saying; 'clear cmos by flipping the battery around,and leave it like that for five minutes...see if it helps'

Whut?!? I have to reverse polarity of the battery? Never heard of that before?!? Is a normal clearing procedure not good enough? I cleared it a few times already.
What do you guys think of that...do or don't... yay or nay? Is this a dangerous thing to do?

reply

[problem] Restore bios information after bricked bios � � Hypervisor-protected Code Integrity (HVCI)

Page 5 of 92 � Page 1 2 3 4 5 6 7 8 9 ... 92 Page �

Please enter a reason for warning.