Author Topic: [MOVED] Hacking NVidia Cards into their Professional Counterparts  (Read 1217825 times)

0 Members and 6 Guests are viewing this topic.

Offline sw

  • Newbie
  • Posts: 2
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #400 on: June 17, 2013, 07:42:09 am »
Ok, so will I use the resistors on the EVGA GTX 660Ti  (03G-P4-3663-KR) that have been shown for the 670 card because the board is the same? And is anyone working on a way to make this information easier to view? That would be nice, if not I may do that.
« Last Edit: June 17, 2013, 07:59:58 am by sw »
 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #401 on: June 17, 2013, 08:39:47 pm »
... will I loose PhysX support or anything similar by reporting this cards to the computer as a higher model?

To add to what gordan said, my experience has been strictly with one card (GTX680) and Windows 7 64.

When I was running native Windows, I never lost Physx under any scenario.

While running Windows under Xen, I lost phsyx when the card reported itself as a Quadro K5000 and I was using the Quadro (not the GeForce) drivers. While using the geforce drivers it worked fine.

While running Windows under Xen, I lost phsyx when the card reported itself as a Grid K2, I was able to retain Physx will doing primary gpu passthrough only.

Nvidia drivers seems to know they are running on Xen even with primary passthrough and like to cause trouble (some missing options and features that are tricky to get back).
 

Offline verybigbadboy

  • Contributor
  • Posts: 38
  • Country: ru
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #402 on: June 17, 2013, 10:00:22 pm »
There is no issue with physx for me.
I have grid k2 as xen domu with quadro/grid drivers. I have no physx by default, because quadro drivers doesn't contain "PhysX System Software". But it is easy to fix :) just download geforce drivers and unpack. after that install "PhysX System Software" from "PhysX" folder and enjoy :)
I able to run Supersonic sled demo from nvidia. :)

May be I am miss something? ;)
« Last Edit: June 18, 2013, 06:02:41 am by verybigbadboy »
6'7''
 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #403 on: June 18, 2013, 12:28:55 am »
May be I am missing something? ;)

Bad luck. Ill give you some if you want it.
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #404 on: June 18, 2013, 02:02:15 am »
When modding to the Quadro on my card, it had different results when using the Geforce vs Quadro drivers.

I take it this is GTX680 -> K5000 mod you are talking about. How much of a difference do you actually see in specviewperf? A slight difference or a ~5x difference in catia?
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #405 on: June 18, 2013, 08:23:28 pm »
Just in case anyone is wondering, I just compared the output of
lspci -vvvv
between my genuine Q2000 and a modified GTS450, and there is no difference between them at all. The only things that come up on a diff are the different BAR addresses the card got mapped to. At least that excludes one thing that could be making it not quite behave like a real Quadro in terms of SPECviewperf, and we're back to the GF106 vs. GF106GL chip-wise.

Has anyone got a genuine Quadro 5000 or Quadro 6000 (or even Quadro 7000 - yes, I know, fat chance) that they could capture the output of lspci -vvvv on? We could then compare it to what my faux Quadros show.
 

Offline nporter

  • Newbie
  • Posts: 1
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #406 on: June 19, 2013, 01:14:24 pm »
I have a Quadro 4000 and a Tesla C2075 if either of those would help in this or anything in the future.
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #407 on: June 19, 2013, 03:35:42 pm »
I have a Quadro 4000 and a Tesla C2075 if either of those would help in this or anything in the future.

Hmm... Q4000 doesn't really have a straight GeForce equivalent, but a C2075 is essentially a GTX480 with 4x the RAM.
Give me a few days to re-mod my GTX480 into a pseudo-C2075 and see what I can come up with for comparing notes.
We'd need to find some kind of a benchmark to compare performance between them, though, since AFAIK Teslas have no video ports (or do they?), which means no SPECviewperf comparison, which is the only thing I've found that performs differently.

Edit:
Dismantled my Q2000 and GTS450s. There is a difference in the chip number.
Q2000: GF106-875
GTS450: GF106-250

Whether that means something conclusive or not remains to be seen.
« Last Edit: June 19, 2013, 09:37:29 pm by gordan »
 

Offline jimseal

  • Newbie
  • Posts: 3
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #408 on: June 19, 2013, 09:04:17 pm »
Thanks for your help so far,

Back concerning the ASUS GTX660TI-DC2T-2GD5

One more question please:

The config I am looking for (tk10) asks for a 40kOhms
and it seems that they are not that easy to find or no longer sold, so question is will a 39KOhms or a 46KOhms one work?

Thanks for anyone that could answer with some experiance at this detail here.



 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #409 on: June 19, 2013, 09:40:22 pm »
so question is will a 39KOhms or a 46KOhms one work?

39k should work. I don't actually use any 40k resistors as the 40k caused me some problems and are just a solution to the stability issues some have experienced.

Since you have an ASUS card in the same series as mine (ive got the 680 equivalent of that card), try without a 40k resistor and see if your ID changes randomly. If it doesn't change randomly and is the value you want, you can leave off the 40k ones.

EDIT: Clarified wording.
« Last Edit: June 20, 2013, 02:40:45 am by gamezr2ez »
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #410 on: June 20, 2013, 09:42:20 pm »
Interesting article on GeForce vs. Quadro performance:
http://doc-ok.org/?p=304
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #411 on: June 21, 2013, 07:09:30 pm »
I think I might be getting somewhere with this.

Attached is the glxinfo output from a genuine Q2000 and a GTS450 modified to Q2000.

They are quite substantially different.

I wonder what differences lurk in the BAR0 registers and if they might be changeable...
 

Offline Bishop

  • Newbie
  • Posts: 2
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #412 on: June 25, 2013, 08:09:32 pm »
Good evening
I have a Galaxy GeForce GTX 670 GC 2 GB GDDR5  67NPH6DV5ZVX and I would like to turn it into one of the workstation counterparts. I mainly want it for Xen passthrough to a second monitor domU with 3d/gaming capabilities. The dom0 will be used by another person for work with the iGPU. Is this possible? Do I have to remove or solder resistors? Removing resistors is an option but resoldering cables/resistors freaks me out!
 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #413 on: June 26, 2013, 07:27:37 am »
The dom0 will be used by another person for work with the iGPU. Is this possible?

Possible, yes. The i915 (Intel HD4000) will only work if you are using it for a text only console. X has artifacting with the Xen kernel and intel driver when using the iGPU on dom0 (presumed Xen is at fault here, no solution in the works afaik).

I wouldn't recommend using dom0 as a workstation anyway. I passed the iGPU through to an hvm and used it that way. More secure, bit harder to manage dom0 when it is headless, though.

As for the resistors and such, I suggest reading the thread before attempting anything like this. The questions you posed are all answered.
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #414 on: June 26, 2013, 07:32:50 pm »
I would have thought you'd still be able to use the iGPU with the dumb frame buffer, if performance isn't too much of a requirement.

Performance of accelerated drivers is often an issue on dom0 - Nvidia accelerated drivers get about 3fps in glxgears. ATI ones didn't work at all in Xen dom0 last time I checked (not that I would recommend ATI for anything these days - they have crippled and dumbed down their products to the point where Nvidia have me well and truly by the proverbials by being the only game in town for my use-cases).
 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #415 on: June 26, 2013, 08:43:21 pm »
nVidia and ATI/AMD proprietary and open source drivers all work with dom0 from reports I have read.

I have personal experience with AMD proprietary and open source working with dom0.

As far as I am aware, the _only_ crippling issue with video and dom0 is with the i915.
 

Offline Bishop

  • Newbie
  • Posts: 2
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #416 on: June 26, 2013, 09:48:02 pm »
The dom0 will be used by another person for work with the iGPU. Is this possible?

Possible, yes. The i915 (Intel HD4000) will only work if you are using it for a text only console. X has artifacting with the Xen kernel and intel driver when using the iGPU on dom0 (presumed Xen is at fault here, no solution in the works afaik).

I wouldn't recommend using dom0 as a workstation anyway. I passed the iGPU through to an hvm and used it that way. More secure, bit harder to manage dom0 when it is headless, though.

As for the resistors and such, I suggest reading the thread before attempting anything like this. The questions you posed are all answered.
Got it. What about the nvidia gtx670 passthrough? I've been reading some stuff that says it is not possible, only the workstation counterparts are able to do it. I am sorry I'm just scared of bricking my card as I'm currently a broke student in a 3rd world country studying beginner's virtualization in a subpar laboratory  :-+
 

Offline amigo

  • Regular Contributor
  • *
  • Posts: 108
  • Professional Wannabe
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #417 on: June 27, 2013, 02:27:44 pm »
I think I might be getting somewhere with this.

Attached is the glxinfo output from a genuine Q2000 and a GTS450 modified to Q2000.

They are quite substantially different.

I wonder what differences lurk in the BAR0 registers and if they might be changeable...

I'm not sure what version of NVidia drivers you are using, but as a hint try something older, perhaps from the 270.XX line.

With the original softmods back when, I believe that NVidia had caught up with that and disabled advanced features (ie. Quadro) in drivers.

Still trying to determine when it occurred, which requires testing many old versions of drivers.
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #418 on: June 27, 2013, 08:15:27 pm »
I'm not sure what version of NVidia drivers you are using, but as a hint try something older, perhaps from the 270.XX line.

What would that prove?

With the original softmods back when, I believe that NVidia had caught up with that and disabled advanced features (ie. Quadro) in drivers.

How do you figure that? How does the driver know it's not a real Quadro? I'm using the latest, 319.23 on Linux. There are no separate Quadro and GeForce drivers on Linux, it's the same driver for both.

Still trying to determine when it occurred, which requires testing many old versions of drivers.

I suspect the functionality is laser cut out.
Then again, it could be there is extra strapping on the PCB (e.g. a cap across chip pins) that disables certain functionality, but this is hard to eyeball. All 3 GTS450 cards hav emarkedly different cap arrangements under the GPU, which is different again from the real Q2000.

I don't really use apps that benefit from the extra GL primitives, so I'm not that interested in researching further, but if anyone else is planning to put some more work into it, I would suggest comparing the register values in BAR0 before the driver loads (reasonably easy to do in Linux, just mmap() the bar and dump it out, and compare the real thing vs. the modified card). PMC should contain register values that should imply what engines are enabled/disabled and you _might_ be able to re-enable them by clobbering the values, as provided by the real Quadro. If you can figure it out, on Linux you could write a small program that gets executed before the binary driver loads and clobbers the values to get the driver convinced the card is the real deal.

I'm not a big Windows user so I'm not sure how that might work in Windows, but something similar might be possible.
 

Offline amigo

  • Regular Contributor
  • *
  • Posts: 108
  • Professional Wannabe
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #419 on: June 27, 2013, 08:56:16 pm »
What would that prove?
It would prove that things have changed in the mean time.

People have soft-modded their GTX cards to Quadros in the past, remember RivaTuner? It had a soft-strap editor that would change PCI Id to match whatever other card.

Also, remember that fellow who posted on NVidia CUDA forums about modding vbios soft-straps on his GTX 480 to a Tesla.

How do you figure that? How does the driver know it's not a real Quadro? I'm using the latest, 319.23 on Linux. There are no separate Quadro and GeForce drivers on Linux, it's the same driver for both.
I might as well say the same thing back at you: How do *you* figure that?? Obviously you have not done anything past installing the latest drivers and drawing a conclusion based on a quick look at it.

I suspect the functionality is laser cut out.
Then again, it could be there is extra strapping on the PCB (e.g. a cap across chip pins) that disables certain functionality, but this is hard to eyeball. All 3 GTS450 cards hav emarkedly different cap arrangements under the GPU, which is different again from the real Q2000.
Prove it.

Everyone assumes some kind of manufacturing process or what not involved to cripple GPUs. I suppose because this is an electronics forum that's inherent, but if you have not looked into other aspects, I would not draw conclusions so fast.

Actually I am somewhat positive that crippling occurs on the software side because, unlike you, I tried an older driver giving me different result than the new one, AND I took a peek under the hood (inside the driver).
 

Offline gamezr2ez

  • Contributor
  • Posts: 30
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #420 on: June 27, 2013, 10:41:55 pm »
I am somewhat positive that crippling occurs on the software side

I would agree with you that this is a very strong possibility. With my experience so far, the driver tends to not want to allow certain features under xen. I think this is mostly due to the way xen presents the GPU to the OS (and whether you have a secondary GPU, even if it is disabled). The point here is they have a documented history of crippling features within the software.

But I know more about software, so I would tend to believe it to be a software problem with a software solution.
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #421 on: June 28, 2013, 07:08:23 am »
What would that prove?
It would prove that things have changed in the mean time.

Like what? Are you suggesting that newer drivers do more crippling and better faux-Quadro detection than the old ones?
Can you please list an old driver version that produces markedly better results in SPECviewperf tests on a pseudo-Quadro?

People have soft-modded their GTX cards to Quadros in the past, remember RivaTuner? It had a soft-strap editor that would change PCI Id to match whatever other card.

Also, remember that fellow who posted on NVidia CUDA forums about modding vbios soft-straps on his GTX 480 to a Tesla.

Soft-modding still works to a large extent. The only limitation is the strap bits that are exposed in software.
In the past three weeks I have soft-modded:
GTS450->Q2000
GTX470->Q5000
GTX480->Q6000
GTX580->Q7000
GTX680->Tesla K10

Q7000 and Tesla K10 aren't "MultiOS" capable, so the driver doesn't make them work with VGA passthrough, which makes the mod of limited usefulness, over and above enabling TCC feature in Windows.

Everything required to do this is pretty well documented by the nuoveau project. There are also other things that are useful (and easy) to mod, for example BAR1 size to be >= the size of the RAM on the card. This lets you take, say, a 4GB card and when you're not gaming, you can map it as a really fast block device for some fast swap or whatever you might need.

Kepler BIOSes are quite different, but having spent an hour looking at the dump out of my GTX680, I've worked out most of the bits relevant to this thread. The strapping on them is... odd. It's done in two places, but what is odd is that it is done the same way in two places.

The other odd thing is that the PCI device ID is set in two places, but it has a profound effect on the way the card is handled. For example, just changing the the strapping for the device ID from GTX680 -> Tesla K10 works fine. But if you also chance the PCI ID, at least in the primary location, the card no longer works properly - it gets detected as a standard unaccelerated VGA adapter, even though the Quadro driver is still running it, and the RAM on it shows up as 2990MB instead of 4096MB. Put the device IDs back to GTX680 (but keep the K10 strapping), and it works fine. I'm guessing there may be a checksum on the blocks containing the PCI IDs, but I didn't have a genuine Tesla K10 BIOS handy to cross-check against it last night.

Also, I'm not 100% sure, but I thought I saw a substantial boost in Crysis benchmark fps when running as a K10, but I could have just been dreaming that - will need to re-test that later today when I am more properly caffeineated.

How do you figure that? How does the driver know it's not a real Quadro? I'm using the latest, 319.23 on Linux. There are no separate Quadro and GeForce drivers on Linux, it's the same driver for both.
I might as well say the same thing back at you: How do *you* figure that?? Obviously you have not done anything past installing the latest drivers and drawing a conclusion based on a quick look at it.

I'm guessing that on the basis that laser cutting chips is cheap and easy during production, and the technique is widely used.
Plus the fact that the GF106 in the Q2000 has a different part number etched into it compared to the GF106 in the GTS450 (sample size 3 for GTS450, 1 for Q2000).

I suspect the functionality is laser cut out.
Then again, it could be there is extra strapping on the PCB (e.g. a cap across chip pins) that disables certain functionality, but this is hard to eyeball. All 3 GTS450 cards hav emarkedly different cap arrangements under the GPU, which is different again from the real Q2000.
Prove it.

Everyone assumes some kind of manufacturing process or what not involved to cripple GPUs. I suppose because this is an electronics forum that's inherent, but if you have not looked into other aspects, I would not draw conclusions so fast.

Actually I am somewhat positive that crippling occurs on the software side because, unlike you, I tried an older driver giving me different result than the new one, AND I took a peek under the hood (inside the driver).

Prove it. :)
« Last Edit: June 28, 2013, 08:01:07 am by gordan »
 

Offline amigo

  • Regular Contributor
  • *
  • Posts: 108
  • Professional Wannabe
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #422 on: June 28, 2013, 01:18:05 pm »
Soft-modding still works to a large extent. The only limitation is the strap bits that are exposed in software.
In the past three weeks I have soft-modded:
GTS450->Q2000
GTX470->Q5000
GTX480->Q6000
GTX580->Q7000
GTX680->Tesla K10

Q7000 and Tesla K10 aren't "MultiOS" capable, so the driver doesn't make them work with VGA passthrough, which makes the mod of limited usefulness, over and above enabling TCC feature in Windows.

Everything required to do this is pretty well documented by the nuoveau project. There are also other things that are useful (and easy) to mod, for example BAR1 size to be >= the size of the RAM on the card. This lets you take, say, a 4GB card and when you're not gaming, you can map it as a really fast block device for some fast swap or whatever you might need.

It seems to me you mistakenly compare ability to be detected as something else (spoofing) with real conversion of one to another. Perhaps in your application of this modification (Xen in Linux) it is sufficient to just spoof the wanted card but what I'm looking for is actually getting the Quadro performance instead.

I'd like to know how did you mod the GTX 580 to Q7000 with soft straps and have it work?

Because, I've spent some time on a similar project using a GTX 570 and the only real way to do this was through changing hard straps (driver ignores vbios soft-straps and the system will not boot, will boot with a black screen or not initialize the GUI). Some, if not all, Quadro vbioses actually check if the ROM and board PCI ID match and also lock out.

I am able to get a Q7000, C2075 through hard straps and the system actually boots and initializes. Then I am able to install the latest Quadro/Tesla driver, alas the performance is not there due to whatever limitations imposed (I'd say software).

Kepler BIOSes are quite different, but having spent an hour looking at the dump out of my GTX680, I've worked out most of the bits relevant to this thread. The strapping on them is... odd. It's done in two places, but what is odd is that it is done the same way in two places.

Why don't you share that information here, as it is not documented anywhere it will help everyone else?

The other odd thing is that the PCI device ID is set in two places, but it has a profound effect on the way the card is handled. For example, just changing the the strapping for the device ID from GTX680 -> Tesla K10 works fine. But if you also chance the PCI ID, at least in the primary location, the card no longer works properly - it gets detected as a standard unaccelerated VGA adapter, even though the Quadro driver is still running it, and the RAM on it shows up as 2990MB instead of 4096MB. Put the device IDs back to GTX680 (but keep the K10 strapping), and it works fine. I'm guessing there may be a checksum on the blocks containing the PCI IDs, but I didn't have a genuine Tesla K10 BIOS handy to cross-check against it last night.

You might be finding the PCI ID from the VBIOS and the EFI sections, that's why there are two matches.

On newer Windows systems and Macs, EFI is used to init/boot the card and so the PCI ID in that section also has to be changed - needs to match hard straps. EFI code itself also checks for the Vendor ID, PCI ID and Board ID, so that has to be changed accordingly.

As far as I know the checksums exist for the entire ROM and for the HWINFO section (soft-straps), although it is true that the GK ROM format has changed and they've introduced wrappers for the old VBIOS. Obviously one needs to make sure the HWINFO checksum is correct and then adjust the entire ROM checksum.

You've also probably noticed a cryptographic signature at the end of the ROM which UEFI/Winblows uses to verify authenticity of hardware. In Linux that is irrelevant but thanks to M$, they've managed to create a deadlock and control all OEMs who produce motherboards with this whole signature issue (remember Linux booting problems until the whole UEFI issue was figured out).
 

Offline gordan

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: 00
    • Tech Articles
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #423 on: June 28, 2013, 03:15:56 pm »
It seems to me you mistakenly compare ability to be detected as something else (spoofing) with real conversion of one to another. Perhaps in your application of this modification (Xen in Linux) it is sufficient to just spoof the wanted card but what I'm looking for is actually getting the Quadro performance instead.

Indeed, all the mods so far, hard or soft, have been purely about spoofing. I am not aware of any mod that will re-enable the missing part of the hardware GL implementation.

I'd like to know how did you mod the GTX 580 to Q7000 with soft straps and have it work?

The usual way. Change the PCI ID, re-calc the checksum, flash the card, change the straps, in that order. It "just works". Doesn't really gain you much, though. Mosaic app might work, but since Q7000 isn't MultiOS, it won't run in VGA passthrough mode.

Because, I've spent some time on a similar project using a GTX 570 and the only real way to do this was through changing hard straps (driver ignores vbios soft-straps and the system will not boot, will boot with a black screen or not initialize the GUI). Some, if not all, Quadro vbioses actually check if the ROM and board PCI ID match and also lock out.

I'm not using a Quadro BIOS, I'm using a modified version of the original BIOS. Switching to a Quadro BIOS would be a whole different can of worms to open.
I've not had any problems with it as Q7000, the only reason I bother keeping it as that is so that I don't have the GeForce driver clashing with the Quadro driver on the same system when I boot into Windows (the other card is a GTX480 -> Q6000, which i what I use for VGA passthrough).

I am able to get a Q7000, C2075 through hard straps and the system actually boots and initializes. Then I am able to install the latest Quadro/Tesla driver, alas the performance is not there due to whatever limitations imposed (I'd say software).

I got to that point without heating up my soldering iron.

Why don't you share that information here, as it is not documented anywhere it will help everyone else?

Half of the info was already posted on this thread, the first (newly added) strap is at the beginning of the BIOS. This seems to be the same as the first 8 bytes of the normal strap, apart from a discrepancy in th efirst bit of the OR mask, IIRC. The old strap you can easily work out where it is - nvflash edits it correctly. There appears to be a 0x400 length header prepended to the BIOS (includes the new strap), after which the BIOS is fairly similar to previous generations.

You might be finding the PCI ID from the VBIOS and the EFI sections, that's why there are two matches.

That seems quite plausible.

On newer Windows systems and Macs, EFI is used to init/boot the card and so the PCI ID in that section also has to be changed - needs to match hard straps. EFI code itself also checks for the Vendor ID, PCI ID and Board ID, so that has to be changed accordingly.

Hmm... I wonder if this could be stripped out to reduce the BIOS to the old, EFI-less state that is more open to modifying. It'd also make it a lot more similar to the previous BIOSes in terms of understanding what the various bits do.

As far as I know the checksums exist for the entire ROM and for the HWINFO section (soft-straps), although it is true that the GK ROM format has changed and they've introduced wrappers for the old VBIOS. Obviously one needs to make sure the HWINFO checksum is correct and then adjust the entire ROM checksum.

Prior to 6xx at least, the strap checksum is independent of the full checksum, IIRC (unless nvflash updates both when you use it with --straps, which I don't think it does).

You've also probably noticed a cryptographic signature at the end of the ROM which UEFI/Winblows uses to verify authenticity of hardware. In Linux that is irrelevant but thanks to M$, they've managed to create a deadlock and control all OEMs who produce motherboards with this whole signature issue (remember Linux booting problems until the whole UEFI issue was figured out).

I don't own any EFI motherboards, but I would have thought the whole EFI wrapping should be strippable out from the VBIOS. Once you skip past the 0x400 bytes of header, the rest of the BIOS is similar in terms of offsets of known areas to the Fermi BIOSes.
 

Offline amigo

  • Regular Contributor
  • *
  • Posts: 108
  • Professional Wannabe
Re: Hacking NVidia Cards into their Professional Counterparts
« Reply #424 on: June 28, 2013, 03:36:28 pm »
The usual way. Change the PCI ID, re-calc the checksum, flash the card, change the straps, in that order. It "just works". Doesn't really gain you much, though. Mosaic app might work, but since Q7000 isn't MultiOS, it won't run in VGA passthrough mode.
Ah, so you change the straps from the command line with nvflash.

I actually edit the straps while I'm editing the ROM. I find it easier because all I have to do afterwards is flash the ROM, although I do make sure that nvflash verifies my ROM first.

I got to that point without heating up my soldering iron.
For me, Windows Quadro driver would not install if I do not change hard-straps. Matter a fact in some cases I could not even get to Windows GUI to install the driver.

Hmm... I wonder if this could be stripped out to reduce the BIOS to the old, EFI-less state that is more open to modifying. It'd also make it a lot more similar to the previous BIOSes in terms of understanding what the various bits do.
That should be doable, but you have to make sure that you include all ROM parts (minus the EFI). In Fermi cards, the ROM had two parts (one was the vbios and the other another device, I believe HDMI audio).

I don't own any EFI motherboards, but I would have thought the whole EFI wrapping should be strippable out from the VBIOS. Once you skip past the 0x400 bytes of header, the rest of the BIOS is similar in terms of offsets of known areas to the Fermi BIOSes.
IIRC, according to the PCI firmware spec the wrapping stuff ends up being ignored on older computers with BIOS, until the 55 AA signature is detected. On the new UEFI, they will probable read the wrapper and then read the rest (55 AA, on).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf