|
|
Post by andrehe on Jun 26, 2023 10:10:17 GMT
After having problems reading out vbios with newer versions of GPU-Z (since 2.51) on Asus ROG Strix RTX 3090 OC, I have tried SIV64X V5.70. vbios size is different, and I wonder which one is complete or contains maybe unnecessary parts. Usage: GPU passthrough on Linux/KVM GPU-Z 2.50 : 999424 bytes
SIV64X 5.70 : 549376 bytes
|
|
|
|
Post by siv on Jun 26, 2023 10:41:24 GMT
With my GeForce RTX 3080 I see the same size of 536.5KB which is what SIV reads via NvAPI_GPU_GetVbiosImage(). Given this I expect the size reported/dumped by SIV is correct and if not it's an NVAPI bug.
I have no idea how GPUZ reads the VBIOS, but wonder are the first 549376 bytes of the two dumps the same? If so I wonder are all the other bytes in the GPUZ dump 0xFF?
Update: I happen to have GTX_680_2682_V470.rom which is the VBIOS that I programmed into my EVGA GTX 680s. It's 179KB in size which is almost the same as the 178KB that SIV reports as the size. When I compare GTX_680_2682_V470.rom has a 1024 byte header and the remainder is identical to the SIV dump, given this I expect the size report by SIV is correct and GPUZ has a bug.
|
|
|
|
Post by andrehe on Jun 26, 2023 11:46:07 GMT
I want to add that nvflash64 V5.814 saves vbios with the same size as GPU-Z, result is identical.
./nvflash64.exe --index=0 --save nvflash-asus_rog_strix_rtx_3090_oc_vbios.rom
NVIDIA Firmware Update Utility (Version 5.814.0)
Copyright (C) 1993-2023, NVIDIA Corporation. All rights reserved.
Reading EEPROM (this operation may take up to 30 seconds)
Build GUID : 744CE6E8A7A84761B6353B3559A78B0C
Build Number : 29236791
IFR Subsystem ID : 1043-87AF
Subsystem Vendor ID : 0x1043
Subsystem ID : 0x87AF
Version : 94.02.42.00.A9
Image Hash : N/A
Hierarchy ID : Normal Board
Build Date : 10/23/20
Modification Date : 03/08/21
UEFI Version : 0x60009 ( x64 )
UEFI Variant ID : 0x000000000000000A ( GA1xx )
UEFI Signer(s) : Microsoft Corporation UEFI CA 2011
XUSB-FW Version ID : N/A
XUSB-FW Build Time : N/A
InfoROM Version : G001.0000.03.03
InfoROM Backup : Present
License Placeholder : Present
GPU Mode : N/A
CEC OTA-signed Blob : Not Present
|
|
|
|
Post by andrehe on Jun 26, 2023 11:51:09 GMT
With my GeForce RTX 3080 I see the same size of 536.5KB which is what SIV reads via NvAPI_GPU_GetVbiosImage(). Given this I expect the size reported/dumped by SIV is correct and if not it's an NVAPI bug. I have no idea how GPUZ reads the VBIOS, but wonder are the first 549376 bytes of the two dumps the same? If so I wonder are all the other bytes in the GPUZ dump 0xFF? Update: I happen to have GTX_680_2682_V470.rom which is the VBIOS that I programmed into my EVGA GTX 680s. It's 179KB in size which is almost the same as the 178KB that SIV reports as the size. When I compare GTX_680_2682_V470.rom has a 1024 byte header and the remainder is identical to the SIV dump, given this I expect the size report by SIV is correct and GPUZ has a bug. It seems that nVidia does not use this API call, strange. The short BIOS file begins with 55AA, the long one has to be stripped. I removed the header from the long one until the first occurrence of 55AA (512 byte boundary), and get a file size of 962048 bytes. There are more 55AA signatures, seems to be multi-part.
|
|
|
|
Post by galkinvv on Jan 2, 2024 6:00:57 GMT
I have no idea how GPUZ reads the VBIOS, but wonder are the first 549376 bytes of the two dumps the same? If so I wonder are all the other bytes in the GPUZ dump 0xFF? Hello. I suppose that the complexity in saving NVIDIA VBIOS is caused by the fact that actually there is 2 common variants of NVIDIA VBIOS: - The full VBIOS stored inside flash IC
- its "CPU-visible" part that is actually transferred to the PC via PCIe bus and used by the boot process and the driver.
(some newer VBIOSes like 3060 with ~2MB full VBIOS size additinally also uses the duplication scheme - there are a pair of "CPU-visible part" variants inside single full VBIOS, seems like "reliable firmware" mechanism that can survive interrupted flash process
The full VBIOS seems to be accessed only by GPU-internal ucode and is never transferred to CPU via PCIe bus during normal operation (including initial POST during boot and inside-driver usages). The CPU-visible part is actively used by a driver/boot process/etc. During driver initialization it is stored in binary form in a (session-lived?) registry value named vbios in a key like Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\00 NN\Session Where 00 NN corresponds to the GPU path in registry (can be seen in GPU-Z, I don't know much about it).  It is that "CPU-visible" part that is saved by SIV by calling NvAPI_GPU_GetVbiosImage (so, it ssems to be just loadable from the registry, also undocumented I suppose) There seems to be no simple way for getting the full VBIOS since even driver do not use it. There is what is done behind the scenes by modern version of GPU-Z (a bit simplified): - GPU-Z unpacks bundled nvflash and calls it with --save argument to save VBIOS
- nvflash temporarily unloads driver (the screen flickering you see), to avoid interfering its non-stanard operations with loaded driver
- It gets the GPU chip model and selects the signed ucode blobs bundled inside nvflash corresponding to the GPU model (quite many blobs nowdays)
- It uploads the signed blob to the GPU and executes it. The GPU verifies blob signature and if the check passes allows it to operate on SPI-related functions
- NVFlash communicates to the running uploaded blob and sens it the "read VBIOS and report it back" operation
- The blob performs read and send the full VBIOS to nvflash.
- NVFlash saves the VBIOS
- NVFlash reactivates the driver
What is the difference in content between full VBIOS and "CPU-visible" part? The full VBIOS contains the "header" - NVGI section and the footer - ISBN section. The NVGI section seems to contain some chip initialization and the history of VBIOS flashes(!) - not sure about its format, some structured data on offset 0x3000 for Turing GPUs and 0x4000 for Ampere GPUs) The ISBN maybe corresponds to the NBSIgnature abbreviation, not sure. (just registred. Great thanks for SIV! - Its "GPU Power Status" is very helpful tool in diagnosing Nvidia GPU faults caused by some damage related to power limits) |
|
