Updating UEFI Gop Tables has nothing to do with memory modules of the specific graphic card (Micron, Samsung, Hynix, and so on…).
I just updated the GOP for my Asus 2070 Mini OC from 50014 to 50018 so I thought I’d share some info.
I have uploaded #GOP_Database.txt for all Turing GOP’s (I have added 5000E, 5000F, 5001C) and all the Turing GOP EFIROMs for anyone that wants them;
Turing_GOP.zip
I’d suggest anyone with a Turing card to only update to a GOP version that is exactly the same size as the GOP in the VBIOS you want to update e.g.
50005 = 71,168 bytes
50006 = 71,168 bytes
50008 = 71,168 bytes
50009 = 71,168 bytes
5000A = 69,632 bytes
5000B = 69,632 bytes
5000C = 69,632 bytes
5000D = 69,632 bytes
5000E = 69,632 bytes
5000F = 69,632 bytes
50011 = 69,632 bytes
50012 = 69,632 bytes
50013 = 69,632 bytes
50019 = 69,632 bytes
5001A = 69,632 bytes
5001B = 69,632 bytes
5001C = 69,632 bytes
5001D = 69,632 bytes
50014 = 69,120 bytes
50015 = 69,120 bytes
50016 = 69,120 bytes
50018 = 69,120 bytes
You can swap the one you want with the one currently in the #GOP_Files folder - just remember to rename it to nv_gop_TU1xx.efirom
Note that there are two versions of 50019, the larger one was found in Quadro T600 Mobile and Quadro T400 Mobile VBIOS;
50019v2 = 73,216 bytes
There is also a modified version of Nvflash 5.735 to override Subsystem ID mismatch here (source) - thanks TheSin!
nvflash64_5.735_patched.zip
Turing_GOP.zip (1.55 MB)
@chinobino
“I’d suggest anyone with a Turing card to only update to a GOP version that is exactly the same size as the GOP in the VBIOS you want to update e.g.”
@Dagal The problem is that the GOP_Updater tool has not been updated to work with Turing GOPs past 50009.
When GOP updater updates a Turing VBIOS with a different size GOP to the original it does not realign the internal images and corrupts the VBIOS.
I think wudimobile (AKA wudi6160096) described the situation well;
@wudimobile Are you still working on a new tool? If so, will be released to the public soon?
@chinobino
Sorry, I used Google Translate to reply to you
Yes, the development of the tool for Turing and post architecture is complete. It can correctly handle issues arising from architecture changes and support firmware update packages beyond the firmware files. Tools for easy extraction and management of UEFI GOP modules are also included.
In terms of programming languages, I developed using batch and powershell, which are very small, less than 6KB in size after many optimizations, and can be processed in less than 1 second on older machines.
However, I am not good at multilingualism, including English. I only have Chinese and Japanese ready, so I haven’t been able to publish them yet. If anyone is capable and interested in working on multiple languages, please contact me as it will help speed up the publishing process. (Including translating in-app tips, post editing and making user manuals)
@wudimobile Your tool sounds amazing! Unfortunately I only speak/write English so I am not much help.
@wudimobile idk if i could help but maybe if you have the list of texts that need to be translated, maybe i could as my friends who understand japanese
@wudimobile You could try using deepl.com - it’s very accurate, even the german television is using it.
@Koekieezz Thank you for your kind words, I am writing the user manual and I will contact you when it is finished.
@troubadix Thank you for your suggestion, but in any case for firmware operation it would be safer to involve a human in the translation, because in my opinion the user should understand the current status accurately and sometimes word deviations can cause different results.
Is this DisplayID update tool the same as an gop update tool? Saw on YouTube this guy Jaystwocents was able to fix black screen issue on a 3080 card using this:
https://nvidia.custhelp.com/app/answers/…l-for-displayid
Before publicly releasing the new results, I would like to publicly answer some doubts and give some feedback on the pitfalls of GOPUpdate for more friends to receive help.
In fact, in NVIDIA graphics cards, Pascal architecture does not yet verify the size of the UEFI GOP, but in later architectures subject to stricter digital signature restrictions, using a different size of UEFI GOP will not be able to initialize the card correctly, in order to bypass the restrictions, cross-version cross-size update requires the use of some tricks.
Regarding the existence of two versions of 0x50019 proposed by @chinobino , it is actually just a different digital certificate and no more fixes or improvements. Generally Microsoft digitally certifies the UEFI firmware (digitally signs and adds a digital certificate) and in the larger size version there is an additional digital certificate issued from digicert.com, which I am not sure yet in which software this will work.
Also I would like to give feedback on an existing flaw in gopupdate to avoid some of friends getting into trouble with it.
well known, GOPUpdate suffers from a lack of flexibility in the handling of header data for the UEFI GOP module, in addition to the lack of necessary follow-up to properly handle Turing and updated architecture.
For example, at 0x31h of the UEFI GOP header data (description: Last image), there are two cases of using 0x00 and 0x80 for cards with different parameters. The current GOPUpdate will use the header parameter settings in the .efirom module file to directly overwrite the original firmware header parameter settings, which will cause the initialization to fail for some graphics cards with the wrong parameters.
This issue affects all versions of nvidia (unknown for AMD), so before using gopupdate, it is recommended to make sure you have another graphics card or built-in graphics card or programmer to fix your graphics card, just to be safe.
The AMD GOP file of the new version of GOP_Updater, after comparing with the previous version, is an old version, please fix it
Guys post GA1xx - 0x6000C.efirom. It’s not the last, it’s for the collection.
https://www.upload.ee/files/14072002/GA1xx_0x6000C.rar.html
I don’t know who is maintaining this thread, but want to report missing ID so that database can be updated.
Link to the vbios:
https://www.techpowerup.com/vgabios/2307…xt-16384-201104
My terminal output:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
python "C:\Users\G5\Downloads\GOP_Updater_v1.9.6.5.k_mod_v0.4.9\GOPupd.py" "C:\Users\G5\Downloads\GOP_Updater_v1.9.6.5.k_mod_v0.4.9\AMD.RX6900XT.16384.201104.rom" gop_upd
---------------------------------------------------------------
***************************************************************
*** Processing with Python... ***
***************************************************************
GOP is not present!!!
EFI ROM is not last image!
Do you want to update GOP to latest available? Y for yes or N for no: Y
Warning! Your VBIOS ID 1002-73BF doesn't exist in latest available GOP!
Do you still want to update GOP? Y for yes or any key for checking the ID in older 1.57.0.0.0 GOP: Y
There are other ROM images in this binary! Please report it!
Fixing ID for EFI image. No checksum correction is needed.
Removing unnecessary end padding.
Data after ROM and not part of EFI! Please report it!
Unable to recover extra data at the same offset 0x14200! Please report it!
File "AMD.RX6900XT.16384.201104_updGOP.rom" with updated GOP 1.69.0.15.50 was written!
sha 256 hash of the updated vbios:
A2CC4BDE2BF99F6A8E4DB5E787ECF2AB31A9DF0840688FB10D994F0336118FF3
Apparently the program removes the ARM efi rom (Unable to recover extra data at the same offset 0x14200! Please report it!).