Try this new one, I’ve modded gopuefi in order to accomodate the uefi part from gigabyte like you requested.
Evgauefi_2012.zip (103 KB)
Artifacts are still there. It seems the gop driver version isnt the culprit(Who knows maybe its the mobo fault.). I will test further and see from where those artifacts come from.
Thanks for everything and sorry for taking up your time, you really helped me!
It could also be the motherboard bios.
Thanks for input Sylar. In fact, I had found some sample of someone adding UEFI support to a BIOS that initially had none, using the GOP updater too ( https://www.techpowerup.com/forums/threa…95/post-3851793 ).
And he got no warnings or whatsoever. So I thought what I screened is not only due to the ROM having no UEFI part inside.
Some side infos I spotted today:
- From linux, I could only dump the GPU ROM from host (i.e. “cat /sys/path/to/gpu > myDump.rom”) while setting HybridMode to “disabled” (i.e. Intel GPU disabled and Nvidia GPU enabled), and booting the host in UEFI-with-CSM. Booting in UEFI-no-CSM or legacy granted me no access to the “/sys/path/to/gpu” file (i.e. “I/O error” when displaying/cating it). With both that HybridMode=disabled and UEFI=UEFI-no-CSM settings in BIOS, I spotted that some new info appears at top-left corner now when the computer boots. As if the system BIOS enabled some special variant of itself.
- From linux, from host still, nvflash_linux could not generate the ROM dump (i.e. it states “Image size: 0 bytes”, “IFR-only image”)
I’ll let you know what happened when I’ll have flashed the ROM of the GOP-updater I generated earlier.
@Sylar76 I didn’t flash the ROM, but I provided the virtualization software with it.
- With the initial ROM, I’ve no POST when the VM boots
- With the GOPupdated one, I’ve POST and land into windows. The latest or older Nvidia drivers will then install with no error message (no previous Nvidia drivers were installed, it’s a brand new Windows 10 running here). But then, the devices manager shows the GPU as “error code 43”. That is, the GPU sits there, still with the default Windows 2D driver. This may be due to the VBIOS, as much as not. I’m clueless about that atm.
That’s still a big improvement from the initial no-POST situation.
I don’t know well the VM behaviour but if you flash the correct gop uefi table, VGA can boot in “real environment” as a Full-UEFI system.
Hi,
I have a problem with the GOPupd tool. I try to update vBIOS of MX150 (GP108) card (link to the image: https://cernbox.cern.ch/index.php/s/BEXhHhpcYGMeTWb) using the tool in the latest version (1.9.8.b). The Nvidia flash tool shows the following information for my original vBIOS:
$ ./nvflash_linux --version vga.rom
NVIDIA Firmware Update Utility (Version 5.414.0)
Simplified Version For OEM Only
IFR Data Size : 0 bytes
Image Size : 180736 bytes
Version : 86.08.11.00.29
~CRC32 : E1265835
Image Hash : 05507E5C2517B6A7F24370C493BDDF40
OEM String : NVIDIA
Vendor Name : NVIDIA Corporation
Product Name : GP108 Board
Product Revision : Chip Rev
Device Name(s) : GeForce MX150
Board ID : F107
PCI ID : 10DE-1D10
Subsystem ID : 17AA-225E
Hierarchy ID : Normal Board
Chip SKU : 650-0
Project : 2902-0000
CDP : N/A
Build Date : 04/11/17
Modification Date : 09/06/17
Build GUID : 4E71C004CA014FE3BC64F3B718CFB814
UEFI Support : No
UEFI Version : N/A
UEFI Variant Id : N/A ( Unknown )
UEFI Signer(s) : Unsigned
InfoROM Version : N/A
InfoROM Backup Exist : NO
License Placeholder : Absent
GPU Mode : N/A
Sign-On Message : GP108 E2902 SKU 0 VGA BIOS
However, after the updated image (link: https://cernbox.cern.ch/index.php/s/eitrxVCDB3Lc5An) generated with the tool for GP1xx (number 7) GPU architecture contains the errors reported by the nvflash:
$ ./nvflash_linux --version vga_updGOP.rom
NVIDIA Firmware Update Utility (Version 5.414.0)
Simplified Version For OEM Only
ERROR: PCI Block corrupted - size mismatch
Do you know how could we fix it?
Did you try a different nvflash version ?
Anyway it would be nice to have sources of GOP Uefi Updater in order to accomodate also the incoming Turing vga cards.
Some new bits regarding the patching issue I met with a Quadro K2100M for an HP Zbook 15 Mobile Workstation ( previous posts: AMD and Nvidia GOP update (No requests, DIY) (35) , AMD and Nvidia GOP update (No requests, DIY) (35) , AMD and Nvidia GOP update (No requests, DIY) (35) ).
Reminders: I run a linux. So I cloned a tiny installed-Windows to an USB stick, in order to boot it bare-metal on the laptop. I still run the OEM system BIOS (that ties the VBIOS of the discrete Nvidia GPU). The Nvidia discrete GPU is only in use as primary graphics when the BIOS is set to HybridGraphics=disabled. What follows uses this context.
What I saw from that USB-hosted Windows installation: the Nvidia drivers provided by HP installs fine, and device shows no error 43 in the end. I can access the Nvidia control panel.
What is more interesting about VBIOS:
- The latest Windows version of Nvflash couldn’t dump it: same error as obtained in the reference post message of this topic (“IFR-only image”). I tried dumping with both HybridGraphics=disabled and HybridGraphics=enabled set in BIOS: same results
- Only once the Nvidia drivers were installed, that registry hex key got created: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4d36e968-e325-11ce-bfc1-08002be10318}\0001\Session\vbios”: you’ll find it attached
After converting that Windows-reg hex VBIOS to binary (with https://sourceforge.net/projects/reg2exe/ ), I cleant what I thought to be overhead bytes before and after what I think to be the VBIOS. It results in a 256KB file. A second pass led to a 98KB file (i.e. slightly bigger than the other-version ROM found on TechPowerUp).
Dumping the 256KB file on GOPUpd Nvidia info bat prints good info.
But dumping it on the GopUpd updater bat prints ** “Strange Nvidia image was found after ROM! Please report it!” **.
The 98KB file prints good info too, and only shows the red and yellow warnings I stated in the initial post.
REG file, various steps dumps and tools are attached, see the archive’s readme.
@Sylar76 :
I have tried the latest version (original post) and a bit older (5.265) and both report the same error. I don’t expect it’s a problem of nvflash as it works properly for the original vBIOS. Moreover, the one generated with GOPudp doesn’t solve the famous Nvidia “Error 43” in KVM (although, despite my precautions, a source of this could be still somewhere else).
Can I help somehow, to fix the tool so it generates a proper vBIOS for newer NVIDIA GPUs like mine?
You have to force flash under nvflash as any modded bios in order to be properly flashed.
@Sylar76 :
I don’t want to flash my GPU. I need a UEFI compatible vBIOS in order to have a discreet GPU assigned to a virtual machine (KVM). Thus, I need to generate a valid vBIOS. I think currently it’s simply either ignored by KVM or NVIDIA drivers inside the virtual machine.
I assume that for other vBIOS, the users didn’t report a modded image which would be corrupted, did they? Thus I think GOPupd has a bug which we could address.
I can’t figure out that bug yet.
@Sylar76 : Do you need more information from me?
In my original message, I enclosed the original vBIOS file (properly recognised by nvflash) and the output file generated by GOPudp.
The bios you linked in your post is very very strange. How did you obtain that ?
The original one or the one produced by GOPupd?
The original one was extracted by UEFITool (https://github.com/LongSoft/UEFITool) from the BIOS of the Lenovo T480 laptop (https://pcsupport.lenovo.com/ch/en/produ…nloads/DS502355). I believe it’s fine, as nvflash doesn’t report any problems.
I’m not sure about that. Could you dump the original bios using nvflash instead of uefi tool ?
@Sylar76 : I can’t dump it using nvflash, as this graphics card doesn’t come with a separate EEPROM to store vBIOS (https://gist.github.com/Misairu-G/616f7b…tract-you-vbios). The vBIOS of this GPU is stored inside UEFI of the laptop and stored in the EEPROM which is shared for the whole machine.