This is interesting! I just had a look at DSDT table (module 10) of a P6T Asus board: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00003370 5F 43 52 53 00 79 01 0A 0A 60 _CRS.y...` 00003380 A0 0D 7B 49 4F 53 54 60 00 A4 4D 32 52 30 A1 06 *.{IOST`.¤M2R0¡. 00003390 A4 4D 32 52 31 14 14 2E 50 53 32 4D 5F 50 52 57 ¤M2R1...PS2M_PRW 000033A0 00 A4 47 50 52 57 0A 1D 0A 04 10 4F 10 5E 5E 50 .¤GPRW.....O.^^P 000033B0 43 49 30 08 53 4C 49 43 11 42 0A 0A 9E 39 38 37 CI0.SLIC.B..ž987 000033C0 31 33 34 35 31 32 37 38 31 47 65 6E 75 69 6E 65 134512781Genuine 000033D0 20 4E 56 49 44 49 41 20 43 65 72 74 69 66 69 65 NVIDIA Certifie 000033E0 64 20 53 4C 49 20 52 65 61 64 79 20 4D 6F 74 68 d SLI Ready Moth 000033F0 65 72 62 6F 61 72 64 20 66 6F 72 20 41 53 55 53 erboard for ASUS 00003400 20 50 36 54 20 44 65 6C 75 78 65 20 20 20 20 20 P6T Deluxe 00003410 30 31 30 31 2D 43 6F 70 79 72 69 67 68 74 20 32 0101-Copyright 2 00003420 30 30 38 20 4E 56 49 44 49 41 20 43 6F 72 70 6F 008 NVIDIA Corpo 00003430 72 61 74 69 6F 6E 20 41 6C 6C 20 52 69 67 68 74 ration All Right 00003440 73 20 52 65 73 65 72 76 65 64 2D 37 36 35 32 38 s Reserved-76528 00003450 39 38 39 31 30 32 33 28 52 29 00 5B 82 4D 05 57 9891023(R).[‚M.W 00003460 4D 49 31 08 MI1. I've to figure it out how to extract / insert it into another bios. There is also a way to softpatch the DSDT using a special version of grub, or even better for testing purposes use rw-everything to patch the DSDT till you found a proper way. After that you can hardcode it into bios..... Please don't confuse the SLIC with variable C of SLI = SLIC!!! Any comments?
These are the changes Gigabyte had made from f3 to f5 biosupdate: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00002C90 02 10 40 12 5C 2E 5F 53 42 5F 50 43 49 30 08 53 ..@.\._SB_PCI0.S 00002CA0 4C 49 43 11 42 0A 0A 9E 39 38 37 31 33 34 35 31 LIC.B..ž98713451 00002CB0 32 37 38 31 47 65 6E 75 69 6E 65 20 4E 56 49 44 2781Genuine NVID 00002CC0 49 41 20 43 65 72 74 69 66 69 65 64 20 53 4C 49 IA Certified SLI 00002CD0 20 52 65 61 64 79 20 4D 6F 74 68 65 72 62 6F 61 Ready Motherboa 00002CE0 72 64 20 66 6F 72 20 47 49 47 41 42 59 54 45 20 rd for GIGABYTE 00002CF0 47 41 20 45 58 35 38 55 44 34 50 33 32 38 37 2D GA EX58UD4P3287- 00002D00 43 6F 70 79 72 69 67 68 74 20 32 30 30 38 20 4E Copyright 2008 N 00002D10 56 49 44 49 41 20 43 6F 72 70 6F 72 61 74 69 6F VIDIA Corporatio 00002D20 6E 20 41 6C 6C 20 52 69 67 68 74 73 20 52 65 73 n All Rights Res 00002D30 65 72 76 65 64 2D 37 36 35 32 38 39 38 39 31 30 erved-7652898910 00002D40 32 33 28 52 29 00 5B 82 4A 06 57 4D 49 31 08 5F 23(R).[‚J.WMI1._ 00002D50 48 49 44 0D 70 6E 70 30 63 31 34 00 08 5F 55 49 HID.pnp0c14.._UI 00002D60 44 0D 4D 58 4D 32 00 08 5F 57 44 47 11 17 0A 14 D.MXM2.._WDG.... 00002D70 3C 5C CB F6 AE 9C BD 4E B5 77 93 1E A3 2A 2C C0 <\Ëö®œ½Nµw“.£*,À 00002D80 4D 58 01 02 14 2D 57 4D 4D 58 03 8A 6A 0A 00 46 MX...-WMMX.Šj..F 00002D90 55 4E 43 A0 1B 93 46 55 4E 43 0C 53 4C 49 41 A4 UNC*.“FUNC.SLIA¤ 00002DA0 5C 2F 03 5F 53 42 5F 50 43 49 30 53 4C 49 43 A4 \/._SB_PCI0SLIC¤ Update ex58ud4.f3 to ex58ud4.f5 (added SLI support) Anyone want's to do some tests?? Wanna try for SLI enable? Only software based, no need to flash bios....
This is definitely a new field of research that could yield big rewards. Just look at all the AMD Crossfire boards out there - no reason physically why you couldn't stick a pair of nVidia cards in them!
OMG, I've forgotten this thread. At the moment I'm busy with another project. But I'm still interested in. As soon as the new Phoenix mod tool is released, I'll come back to here..... ..and please PM me again, let's say mid of September to make sure I won't forget it again.
Posted a working driver for XP 32 bit over at techpowerup forums. I'm still doing some work to make this more simple, but it shows that it can be done.
Hopefully once Yen is done with his tool, he can help out with what you've started. I'd really love to see it use original drivers
OK, I have read now most of it. It seems the approach went to patching the driver and hal.dll. If I got this right all the device IDs and vendor / sub IDs of the chipset are verified also...... I'm still interested in the 'other side'. I need to know from where come the IDs and if they are really read from the chip itself (hardcoded) or from bios...... IMO it is reading from bios. Still unknown what IDs (the chipset consists of several system units)...and where. You need to play with rw-everything......
Yen, I was the one who reversed and patched nv4_mini.sys. Feel free to ask me the questions you need to know. This is how it works: The driver checks the vendor ID and chipset ID of bus = 0 , device = 0, function = 0. If the vendor ID is 8086 (intel), it also checks the subsys ID of one of the PCI express ports to get the manufacturer of the motherboard. This gets put into a string for later use. Later, the driver checks this string against an encrypted table of Vendor/Device IDs. This table contains address values of code that should be executed if a certain chipset is found. If the hardware ID is an X58 or P55 chipset, it makes a call to WMI to get the SLIC string from the BIOS. The BIOS SLIC string is then compared to an encrypted SLIC string in the driver. If they match (and the motherboard manufacturer matches the one in the SLIC string), SLI is enabled. The driver and hal.dll dont *both* have to be patched... Just one or the other. The driver just needs to think you have an X58 chipset (ven_8086, dev_3400), and WMI has to return a valid SLIC. Hope this helps.
Thanks a lot for your reply. I've read the thread about where you've developed a approach to SLIC enable to pre x58 /P55 boards. Have you tried the tool rw-everything already? It's a real powerful tool to read and write (everything) It also can be used to be executed at startup of the OS to patch. Some questions: I've tried to obtain the relevant IDs. Are they found somewhere at device manager? A intermediate way could be to use rw-everything to patch the IDs everytime at startup, so there would be no more need to patch the driver all the time when it's updated. I don't have access to a pre-X58 /P55 board to test. Also I don't think the driver reads the IDs from a 'hardcoded' address at the chipset itself (hope so), but somewhere at the bios. Do you think there is another place, probably at DSDT too where it gets them? A big problem will be: If we could manage to patch at the bios to an x58 /P55 chipset device, what will be about compatibility? The OS will probably install another chipset driver thinking it's an X58/P55 chipset. The patch needs to be selective enough, therefore we need to find a selective place. At the moment I think there is no better way than to patch the graphics driver itself... I'll do more researches about. Thanks again.
Bump Just wondering if you ever took another look? There are still workarounds being done with HAL.dll, but it's all still very software hacky. It'd be nice to see a BIOS solution