Thanks a lot, guys. I use Nvidia G210 (chip GT218, «Ninja Nvidia GT210») for VGA-passthrough in qemu-kvm linux virtual machine (OVMF UEFI boot, Windows 8.1 Pro), and without modification of videocard bios that's can't be possible.I just dropped original vbios from GPU-Z to utility and get modified GT218_updGOP.rom. I didn't flash my hardware card but only just point qemu to load romfile until boot:

First of all thanks for great tool. It's worked just fine for my Asus HD6950 1GB with exception that I didn't flashed it since I run it in VM.

Is there any chance there might be working GOP for Asus GTX 260 896mb? I attached ROM in case it's might be helpful and I'll be happy to test absolutely any idea that might make it work. Of course I already tried to run it with GT21x GOP and it's obviously didn't worked.

Other thing I wonder about what is the difference in patching that done for Mac EFI? I seen several mentions of GTX 260 on Mac forums and looks like someone had it working on boot without some post-boot magic. Unfortunately I have no idea if there any difference between Mac EFI in 2009-2011 and EFI on modern hardware.

Is finally my turn to mod the VBIOS of my old Radeon 5770 since I need UEFI GOP, but the reasons why I need it are totally different to everyone which posted in this Thread (Edit: Didn't noticed that TWO guys in the last page do this, too). I use VGA Passthrough to pass a Video Card to a Virtual Machine, so I can get near-native compatibility and performance for gaming inside a Windows VM. At the moment, I'm using the Xen Hypervisor with a Linux host, but I'm intending to migrate to KVM and re-do my entire setup.The reason why UEFI GOP is very valuable for the virtualization crowd is because the legacy VGA protocol can't be simultaneously used by multiple Video Cards, causing issues with Linux VGA Arbitration. Not having UEFI GOP rules out doing Primary VGA Passthrough, which is when the Video Card VBIOS PCI Option ROM is loaded by the VM Firmware (OVMF for UEFI) so it can display the POST stage on the Monitor attached to the passthroughed Video Card. Instead, you have to wait that the OS loads the GPU Drivers, which is called Secondary VGA Passthrough. With UEFI GOP, legacy VGA is not used at all so you should be able to do it with no issues related to it. There are other important issues, like not being able to reboot the VM properly due to not working Function Level Reset causing issues with GPU warm boot, requiring a host reboot if you want to reboot the VM, and some other issues depending on the specific Video Card.

The first problem is that UEFI GOP support was unheard about during the Radeon HD 5xxx generation (Except for Apple cards with their custom EFI), so there was scarse info about getting working UEFI GOP "donors" for older GPUs. Regardless, I recall that some people successfully modded their Radeons 5450 somehow and were able to enjoy Fast Boot, so it was possible in that generation. At some point I hear about the Insanely Mac tool that was mentioned in the first Post and tried it, then I found an issue that didn't allowed me to try the modded ROM: Junipers have a small 128 KiB Flash ROM, and the modded ROM was around 180 KiB or so, so I couldn't flash it. After some googling I found more people that failed to add UEFI GOP to other Junipers based cards for the same reason, so it seemed like a lost cause.Recently, I hear that QEMU allows you to sideload a custom PCI Option ROM and replace the PCI Card provided one. This allows me to workaround the size issue, and even test the ROM without even having to actually flash it! The only thing that remained unknow is if the UEFI GOP mod worked in a Juniper, since no one I was aware of did so previously. Then I found in this Thread that there was another guy with a Radeon 5770 with the ROM size issue, but which was workarounded by using a very specific UEFI GOP Driver version that fitted even with the size constrains, and probabily may work for my card, too. Regardless, I think I'm going to use the QEMU custom ROM approach, since it seems easier. Only thing I don't know if it can be of an arbitrary size or a power of two one (256 KiB), which may require to inflate it.I still prefer to ask if there is anything else that I should have to check (The other guy with a Radeon 5770 got it working but not with the standard procedure with the GOPUPD tool), or go straight to test the mod to see if it works. GOPUPD seems to complain about being unable to get some data, and to report it. The next magic trick would be if I could mod the Radeon 5770 to a FirePro V5800, heh.

My Video Card is a Radeon 5770 Sapphire Flex, this one. I don't have the original VBIOS ROM, but I recall that at some point I dumped the VBIOS with GPU-Z and compared the CRC32 with the one on TechPowerUp VGA BIOS Database, here, and it was the same. Currently, my Radeon 5770 has a BIOS modded by myself with Radeon BIOS Editor, since I wanted lower noise and power consumption, so I edited the PowerPlay Power states to underclock and undervolt it, and modify the Fan ramp curve.

Besides the obvious thing that would be to test if pure UEFI Boot works, is there anything else that I would have to check? I hear that some people get a half-working mod where the ACPI VFCT Table is missing, Power States may not work properly (Though I have that issue on warm reboots since lack of FLR), but not sure what else I would need to check.

Hi,This is brilliant, thanks for your efforts in this. I can't believe video vendors aren't pushing for UEFI on their cards across the range.

I've run your tool, and attached screenshots of the output, original BIOS info, and updated BIOS info. I've also zipped and attached the updated BIOS.The orginial video BIOS already looks like it's on TECHPOWERUP here:https://www.techpowerup.com/vgabios/1038...450-1024-110609I'm not just looking at the model name, the BIOS file name seems to match too (645ZNH73.SB)

As you can see, my card (XFX HD 6450 model HD-645X-ZNH2) has no UEFI support at the moment. The old BIOS file is 64KB, and the new is 122KB, is this going to be an issue if I try to flash my card?

I am planning on updating the bios on my Zotac 2GB GTX 680 card so it will have UEFI support to boot in CSM Disabled mode. Card is a GK104 (Kepler). I have included the original and modified bios in a zip file.

Currently this computer is running Windows 10 Pro x64, but I could make a windows to go drive with windows 7 x64 to flash with an older version of nvflash if you think that would be necessary or better.Do you think this would be a good idea, or should I just flash from windows 10? If a windows to go drive is a good idea, what version of nvflash and nvidia graphics driver i should use on it? Thanks so much for making this tool!

UPDATE May 3rd 2016: I went ahead and flashed the modified bios using the 64 bit version of NVFlash 5.278.0 for Windows on my Windows 10 Pro x64 system and everything went perfectly. Now I have a UEFI Zotac GTX 680 and can boot in CSM disabled mode.

So thanks for your tool and you can add me as having done a successful flash with the bios I attached in the zip of this post for the 2GB Zotac GTX 680 model # ZT-60101-10P video card. :)

Hi, I used your tool to update the bios of my HD5750 card, but I got the message to report the problem. So here a screen of your tool and both rom files. When I drop the updated file on #AMD_ROM_Info.bat it looks Ok, but I still would like you to have a look before I use it.Thanks,

Rather than read 17 pages on this forum, I followed your instructions (which were very clear) and your tool flawlessly upgraded my Sapphire HD 7970 OC Boost (Tahiti BIOS 015.025.000.099.000000). There were no errors and the Techpowerup utility both before and after shows no differences other than the UEFI being enabled. Windows 8.1 is now running as it should (although enabling fast boot really doesn't make my system boot up any faster from it's already fast boot time).

So the only reason I'm creating an account on this board is to say thank you for all your hard work. I'll point out one aberration I noticed, though. Running the Passmark benchmark software (v7) shows that I took a 10% hit on my G3D score. In all fairness, I didn't run the graphics benchmark immediately before flashing (last ran it about a year ago) but it has been fairly stable at 5200, now at 4650 (no tweaking). I'll just throw that out there for people to investigate. Fast enough for full tilt Crysis, fast enough for me.

The last time I checked, I couldn't find a clear device match on Nvidia, like AMD is using. Either they are using a chipset match or some other registers. I don't know if I can help with that. If someone used GT200 in an UEFI environment, it probably used a custom Mac EFI GOP, which is a complete different firmware than those offered by Nvidia and found in GOPUpd. If you can find a matching Mac EFI GOP you might have a chance, otherwise I can't offer assistance.

The 5xxx and 6xxx generations are indeed suffering from the lack of space for EFI and microcode at the same time. The only solution I knew was to use a smaller EFI ROM, but with QEMU this doesn't seem to be an issue. Still, the file used with QEMU is still not perfect, as the microcode is not at the expected offset. If you want to flash the card, you can use the future 1.9.4 release with the images I attached, by replacing the one from #GOP_Files folder. Here is the explanation:- Image 1 will keep the microcode at the same offset. This is the same I provided for another user with 5770. It contains GOP 1.48.0.15.33 unsigned.- Image 2 will relocate the microcode, but still fit the chip size. It contains GOP 1.52.0.0.0 unsigned.- Image 3 will relocate the microcode, but still fit the chip size. It contains GOP 1.48.0.0.0 signed, if you need signed drivers.

Use them with GOPUpd, as described above, DON'T use them directly! If you decide to load the VBIOS with QEMU, you should still use the newest GOPUpd 1.9.4, as it will relocate the microcode after the EFIROM and fix its pointer. The only problem is the size of the resulting file. ATIFlash doesn't complain about the size, since it already has a fixed and rounded container - the chip. If QEMU barks at the non-standard size, I could add an option for automatically padding the image to a standard size (128KiB, 256Kib, 512Kib and so).

- Added GP1xx 0x30002, thanks to OCN, Orbmu2k and Sylar76- Updated NVFlash to 5.287, same source.- added extraction of Nvidia signing certificates. In GOPUpd.bat change ISBN=0 to ISBN=1 to make it available. You can also change DEBUG=0 to DEBUG=1 if you want the ISBN structure to be printed. Just the basic support, only started investigating this structure.- if you run the above, you will obtain either a cert_nrX.cer or a cert_nrX.lic in the temp folder. The first one should be available for inspection from any system, it is a PEM encoded certificate. The second one should be dropped on #Nvidia_ROM_Info.bat, as it has an Nvidia container.- enabled class-code 03-02-00. I saw several images from Nvidia with this class-code, they all used the official GOP.- report if there are other ROM images in file. Useful for containers like the Nvidia flashers, where there can be more than one image inside.- added reports for bad EFI images. This is currently done using the database file. Will explain later.- AMD will now be extracted as "AMD GOP x.x.x.x[_custom]_[un]signed_CRC32". The term "_custom" will be added only to those containing tables in the EFI, _signed/_unsigned should be obvious what they mean.- relocate the AMD microcode. Unfortunately, the cards that have a microcode also have a limited chip space. You need to ask for help if you are in this situation, I can provide you an older EFI ROM that will fit your image.