(omg)vflash | Fully Patched nvflash from X to Ada Lovelace [v5.780]

[Falkentyne]

I guess now I have a reason to actually buy a 4090 FE and crossflash it once I get enough money.
I can't believe brother @Papusan is here too....

 

[Papusan]

I guess now I have a reason to actually buy a 4090 FE and crossflash it once I get enough money.
I can't believe brother @Papusan is here too....

HeHe. I'm everywhere where things happens bro Falkentyne So you don't fully get rid of me, HaHa. Nice see you here brother. I'll still hold on my HOF and the dual 12VHPWR connector. Yep, I expect we now will see more fried 12VHPWR connectors forwards. Not only the cheapo made CM angled adapters will melt so be careful with that FE

 

[Dr. Dro]

Not really, unless it can restore the glorious days of Maxwell BIOS editing

This lays the foundation to make that possible. To which extent we do not know. With the restrictions and checks on flashing bypassed, it should open the door for an editor to be developed.

 

[Sambrownie]

Dear @Veii,
Do you plan to post linux version since some of us are no longer microsoft bound...
Thank you.

 

[Space Lynx]

HeHe. I'm everywhere where things happens bro Falkentyne So you don't fully get rid of me, HaHa. Nice see you here brother. I'll still hold on my HOF and the dual 12VHPWR connector. Yep, I expect we now will see more fried 12VHPWR connectors forwards. Not only the cheapo made CM angled adapters will melt so be careful with that FE

I remember you from the forum notebook review website, I went by Lynx there too, talked to you a few times there.

 

[Hei]

Welp, am I doomed forever? Have a 3080-10 TUF OC FHR and get a "Adapter not accessible or supported EEPROM not found" exception with a "Detecting GPU failed" error when doing "OMGVflash.exe -6 bios.rom". Only have one GPU in the system, doesnt matter if I add "--index=0", or if I just try to save the ROM. I've tested the original NVFlash 5.780.0 and it gives me the same exception despite newer and older NVFlashes working as intended.

 

[kefi]

Welp, am I doomed forever? Have a 3080-10 TUF OC FHR and get a "Adapter not accessible or supported EEPROM not found" exception with a "Detecting GPU failed" error when doing "OMGVflash.exe -6 bios.rom". Only have one GPU in the system, doesnt matter if I add "--index=0", or if I just try to save the ROM. I've tested the original NVFlash 5.780.0 and it gives me the same exception despite newer and older NVFlashes working as intended.

Try nvflashk, which is based on the latest version of nvflash. It seems as of right now some work on only mine, and some work on only Veii's.

 

[rusTORK]

Quick question: I have got RTX 3080 Ti which is LHR. Are there any kind of performance limitation because of that? If so, is it possible to remove it? Or it's something W1zzard talk about, that some things are just "fused" in GPU?

 

[Dr. Dro]

Quick question: I have got RTX 3080 Ti which is LHR. Are there any kind of performance limitation because of that? If so, is it possible to remove it? Or it's something W1zzard talk about, that some things are just "fused" in GPU?

AFAIK LHR is physically a different die, although the limiters should no longer be active in recent drivers.

 

[rusTORK]

although the limiters should no longer be active in recent drivers.

Yeah... i find information about 522.25 driver. Hm... is it possible to scan for LHR? Like reflect it's presence via GPU-Z.

 

[wzrd]

Can be disable memory channels? 900=>4090 videocards?

 

[Nazo]

I wanted to crossflash my Zotac 3060Ti OC LHR model to the non-LHR model and it very much did not work. Rendered it completely unbootable. I guess they must just be massively different dies then? As far as I know the only differences between the two otherwise is just that LHR. Speeds are the same, power limits the same, etc etc. I don't know how to check voltages, but it wouldn't even boot, so I doubt they're different enough to render it unbootable. Of interest (or not) was I once tried flashing the listed BIOS from here for my model card just because it was listed as newer (mine says 94.03.1B.00.4A and the latest one for my model on this site says 94.04.46.40.0E) and the stock nVidia flash tool wouldn't accept it even with -6, so maybe it's a slightly different revision versus that anyway? Not sure if that has any meaning in this context or not.

I've been a bit paranoid about the LHR thing myself. I made a mistake in buying this card in the first place (both that I really needed at least a 3070Ti and the fact that the LHR makes me paranoid,) but I bought it back at the end of the GPU crisis and at the time thought it was grab that card for a reasonable price or see nothing below $1000 again for who knows how long. (I had no way of knowing the crisis had basically ended then!) Honestly I don't even know why a 3060Ti has a LHR model in retrospect (come on, did anyone really use this one for mining? That would be stupid. Its limitations would make it suck compared to pretty much any other option at the time...) My paranoia is that various things could trick it into thinking there is mining and activate the limiting (such as AI stuff, but what if even gaming could do it at times? I have slowdowns and issues I haven't been able to explain at times and do kind of wonder sometimes...) I am also wondering if there is any way to tell if LHR limiting is actually disabled or not.


BTW is there any chance of BIOS editing? I have the "OC edition." While I am concerned about performance as a whole, I really don't need the extra 0.1% of performance the OC version adds and would rather see voltages and etc bump down just ever so slightly to the non-OC levels (and I want that in everything including *nix and etc where you can't load third party software like MSI Afterburner to adjust GPU settings.) Performance-wise I doubt I could even measure the difference and frankly they shouldn't have bothered with that OC.

 

[bug]

@Nazo Instead of being paranoid, better read up on stuff. Mining is about generating hashes. No real-world workload would need to generate that many hashes, unless you're looking for collisions. LHR does nothing to any other functionality of a card.

 

[StViolenceDay]

I've tried experimenting with BIOSmod flash on my 1070ti - the VBIOS is https://www.techpowerup.com/vgabios/197646/197646.rom
As a starting point I tried to swap lettres in the NVIDIA word (the "Sign-on message" at offset 0xA68) NVIDIA -> IVIDNA.

From experiments with previous generations I know that swapping letters does not affect the 8-bit checksum, but I'm not sure about the 32-bit one.

However, flashing fails. To get more info I added the

-L log.txt

to the command line and save the flashing log.
The first error message is

BCRT: Start Certificate 2.0 verification
Send VV Command...
Command id: 0x3000000E Command: NV_UCODE_CMD_COMMAND_VV failed
Command Status: NV_UCODE_CMD_STS_COMPLETE
Error Code = 0x00000011(17): NV_UCODE_ERR_CODE_CMD_VBIOS_VERIFY_BIOS_SIG_FAIL

I'm attaching the full flash log. Is this caused by a 32-bit checksum problem after letter switching?

Also tried with 2080S, and 3060. Similar error logs attached.

 

[Nazo]

@Nazo Instead of being paranoid, better read up on stuff. Mining is about generating hashes. No real-world workload would need to generate that many hashes, unless you're looking for collisions. LHR does nothing to any other functionality of a card.

I am aware it is about generating hashes. The question is not "will a game generate hashes." (Though, btw, there are a couple of games with mining, so yeah.) The question is: will whatever mechanism these models use to DETECT hash generation MISDETECT under some circumstances. Instead of defaulting to personal attack destruction mode, isn't it more constructive at least to respond to what the person said instead of what they did not? How was that in any way whatsoever constructive? At least if you thought it was you should link to whatever you thought illustrated your point.

To restate as clearly as possible, my question is: could the detection mechanism misdetect something else such as AI generation or even maybe certain scenarios in a game and enable limiting.

Anyway, here's another interesting thing to add: I tried crossflashing to the newer BIOS version in the database listed under this exact card model (LHR and all) and it still would not boot. That's with what's supposed to be the exact same card otherwise. So I guess there's a different die or something even for this model? (Well, it's listed under verified uploads, but alternately, could it just be a bad upload?)

In case it's useful to anyone with the BIOS database stuff, here is what my card says when I do a backup:

Spoiler: output

Build GUID : 8E38263F5428447D984FC1F67E6D64B4
Build Number : 30802293
IFR Subsystem ID : 19DA-6630
Subsystem Vendor ID : 0x19DA
Subsystem ID : 0x6630
Version : 94.03.1B.00.4A
Image Hash : N/A
Hierarchy ID : Normal Board
Build Date : 12/20/21
Modification Date : 01/16/22
UEFI Version : 0x60011 ( 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.94.01
InfoROM Backup : Present
License Placeholder : Present
GPU Mode : N/A
CEC OTA-signed Blob : Not Present

Attempting to crossflash normally says mismatch because firmware image PCI Device ID should be 2489 (versus 2414) and firmware image PCI board ID should be 02D8 (versus 0395) so even the same exact model must have revisions that I guess matter enough to render it unbootable. Ultimately this might only be useful for most when (if) BIOS editors come about to actually modify your own backups rather than trying to crossflash.

 

[R-T-B]

@Veii just fyi, Nvidia is not going to be happy about this. you might want to edit original post, and just at the bottom of page just say "doing this will void your warranty" because Nvidia probably will consider it voided, but I am just guessing, I don't know much about this stuff. I know you have one disclaimer about doing it, but you don't specifically mention warranty voiding

@W1zzard not sure if this is good advice? your advice is welcome. just trying to help out.

He's likely already way beyond that and on their lawsuit radar if they ever identify him.

Not really, unless it can restore the glorious days of Maxwell BIOS editing

You really didn't read the post much, did you?

It can up to Turing.

 

[papatsonis]

After all of this, does anybody know how to help and fix the checksum ? (only altered the Power limit) but of course, i've no idea on fixing the checksum

 

[mouacyk]

He's likely already way beyond that and on their lawsuit radar if they ever identify him.


You really didn't read the post much, did you?

It can up to Turing.

With the vagueness in the post, I just couldn't connect the dots...

 

[R-T-B]

With the vagueness in the post, I just couldn't connect the dots...

It's not so much vague as extremely technical. But yes, I suppose that can be equally confusing. Sorry, wasn't trying to shame you or anything.

 

[Wrigleyvillain]

^ This is awesome and well that is Veii for you (along with friendly and extremely helpful)...get him going on about GDM; near the end your head will spin but it will also be disabled!

On that note this explains why I havent seen him in the OCN AMD DDR4 thread of late...careful out there bro we still need you! Im still at 2T! (four dimms at 2K tho so...)

 

[Shadowsnight]

Re-Bar on the old 2080ti maybe?

Edit-1: Alright here goes! I found the "gpumode" and arguments I've noticed most screenshots of bar1 in GPU-Z have a higher value that the Vram for the card which is odd, I'll start with 8GB see if it works, then try higher. I'm still trying to figure out how to use the command prompt to actually modify the bios file XD
I have backup a GPU and I've backed up my VBios on a USB and HDD so I'm not too worried, but... this is my best card it'd suck if I bricked it XD

Edit-2: So i think I just flashed the card with the un-modified bios OMGVflash.exe TU102.rom gpumode physical_display_enabled_8GB_bar1 wasn't the play

Edit-3: OMGVflash.exe --gpumode physical_display_enabled_8GB_bar1 seems to be what I was after, but doesn't seem to work, OMGVflash.exe --gpumode physical_display_enabled_256mb_bar1 also doesn't work, though it should be that by default according to gpu-z so I'm not sure what is with that \o/

 

[bug]

I am aware it is about generating hashes. The question is not "will a game generate hashes." (Though, btw, there are a couple of games with mining, so yeah.) The question is: will whatever mechanism these models use to DETECT hash generation MISDETECT under some circumstances. Instead of defaulting to personal attack destruction mode, isn't it more constructive at least to respond to what the person said instead of what they did not? How was that in any way whatsoever constructive? At least if you thought it was you should link to whatever you thought illustrated your point.

To restate as clearly as possible, my question is: could the detection mechanism misdetect something else such as AI generation or even maybe certain scenarios in a game and enable limiting.

To the best of my knowledge, there has not been a single case where a benchmark has shown differences between an LHR and an original Ampere card.

 

[papatsonis]

Re-Bar on the old 2080ti maybe?

Edit-1: Alright here goes! I found the "gpumode" and arguments I've noticed most screenshots of bar1 in GPU-Z have a higher value that the Vram for the card which is odd, I'll start with 8GB see if it works, then try higher. I'm still trying to figure out how to use the command prompt to actually modify the bios file XD
I have backup a GPU and I've backed up my VBios on a USB and HDD so I'm not too worried, but... this is my best card it'd suck if I bricked it XD

Edit-2: So i think I just flashed the card with the un-modified bios OMGVflash.exe TU102.rom gpumode physical_display_enabled_8GB_bar1 wasn't the play

Edit-3: OMGVflash.exe --gpumode physical_display_enabled_8GB_bar1 seems to be what I was after, but doesn't seem to work, even OMGVflash.exe --gpumode physical_display_enabled_256mb_bar1 doesn't work even though it should already be set to that, according to gpu-z so I'm not sure what is with that \o/

With this argument "--gpumode physical_display_enabled_8GB_bar1" you do enable the resize-bar????!!!!!

 

[Deleted member 218758]

As a starting point I tried to swap lettres in the NVIDIA word (the "Sign-on message" at offset 0xA68) NVIDIA -> IVIDNA.

From experiments with previous generations I know that swapping letters does not affect the 8-bit checksum, but I'm not sure about the 32-bit one.

You will break the 32bit checksum that way.

You can go and swap an SSID value, or change on-boot description in PMID
PMID/PCIR ansi text are headers and can be used to identify rom spacing. It exists on all cards.
But for example changing PG611 to PG612 - will need header checksum from 6F to be shifted to 6E ~ else Code43
It will on lower than Ampere still flash (soo a good check to see how much prevents)
But you will still break 32bit file checksum IF you edit header-checksum.
If you don't edit header checksum, you will boot ~ because file integrity remains, yet utilization will fail with Code43.

Since 1000/2000 series, a longer file checksum was introduced.
But this was found and broken by multiple people now.
Most of their data is wiped from the net including Github archives.
Soo i can not credit everyone down the line unfortunately.

The mobile pascal tweaker remains and showcases this well for 1000/2000 series.
It has zero support for desktop, except in identifying partially the powerplay table.

As for the powerplay-table itself.
Depending on constant changing location it will still need a checksum fix. Usually the bottom one before InfoRom
Our ROMs have 4 checksums to what i can vaguely find.
Top Header, Bottom Header
one more at the bottom and one for InfoROM section.

Top and Bottom Header missmatch, will boot on 1000/2000 series
This is an old screenshot from Q2/2022
There was a long debate that XOC roms never actually were XOC, as SRC effectively limited power supplied to chip and mem.

But they won't boot if they are fixed ~ as by doing a change in code, you effectively shift 32bit CS.
And with 3000/4000 series, you also effectively invalid cert - created on the base of data (hex) it is created for

---

---

Edit-3: OMGVflash.exe --gpumode physical_display_enabled_8GB_bar1 seems to be what I was after, but doesn't seem to work, even OMGVflash.exe --gpumode physical_display_enabled_256mb_bar1 doesn't work even though it should already be set to that, according to gpu-z so I'm not sure what is with that \o/

Unfortunately

But your data was correct
I'll remember that for another day

Not sure if it pulls it from their servers, or it is required to exist in ROM. Given it answers with gpu/compute mode.
BAR patch usually came with a newer VBIOS , but tool is able to pull data from their server.
Its an nvidia tool after all.

I might try to inspect what it actually does.
Thank you for the command

---

---

That's pretty much what our BIOS Collection already does. Happy to add more readouts if there's something worth adding that you can think of

Yes actually that, chipPL, memPL & SRC limit

OCN lost a lot of my pictures, this is what found in the fast
March,2022 ~ 3000 series

Top Header CS:

// all research belongs to me

PPTable sadly constantly shifts its location,
But exists for pretty much every card.
Having listed:
~ SRC allowed PL
~ ChipPL
~ MemPL
~ PCI Slot PL (would showcase Boardpartner trickery in running 80-90W for consumer bioses)

Instead of this vaguely, pretty much "fake" TDP slider range
I think it would be overall beneficial to everybody who browses the database.

---

---

With the vagueness in the post, I just couldn't connect the dots...

If this tool fails flash, it's not on nvflash's work.
Most runs through falcon.
There are couple scenarios of it being too weak, which i will fix as long as screenshots of "fail" are given.
(tool is too huge to work blind, i need at very least a screenshot of what fails & how flashing procedure was)

I'm attaching the full flash log. Is this caused by a 32-bit checksum problem after letter switching?

As long as you changed unsigned parts, Vendorname, PCIID, Bootup message
You will break top header CS, but you can flash and boot.
If you fix header CS, you modify the file integrity and break the 32bit checksum

If you change memory straps, its the same thing.
This plus now a certificate is 3000/4000's work.
1000/2000 has no certificate, but a new introduced file-content checksum.

 

[W1zzard]

I think it would be overall beneficial to everybody who browses the database.

Nice requests, this is good info, will work on it soon

Check the NVIDIA BIT documentation, the perf table has an entry that has a pointer to the power table. Easier to recognize if you delete everything before the actual BIOS, so 55 AA is at offset 0