Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I've already fixed the microcode issue, that part is very easy using AMI's AMIBCP tool. You can dump microcodes from a donor BIOS from boards which support the Xeons (like the EVGA Classified SR-2 or any Supermicro or whatever), patch them into the target BIOS, flash that in, problem solved.
The traces and the "magic code" in the BIOS, that enables ECC are the real problem. Either they're there, or they're not. If they're not, I wouldn't care about actually soldering wires onto the DIMM and CPU socket pins. I wouldn't go that far, although it'd be fascinating to try.
Of course this would always be a dirty hack. But curiosity is hard to suppress. I just want to see whether it CAN be done!
Waiting for those rusty-nail-in-knee results, too!
Well dude, why the hate? This is the same sort of hacking that uncovers things like the HD 6950 to 6970 mod:
http://www.techpowerup.com/articles/overclocking/vidcard/159
Usually things like this are locked via fuses, but not always. So it doesn't hurt to experiment
It doesn't matter. If any result is reached, and it turns out to corrupt data rather than protecting it, all I can lose is data on a Debian testing installation that I'm gonna wipe anyway.
But it's not like this is going anywhere. I believe I'm stuck as it stands (which is why I posted here, as I was hoping somebody could provide further insight).
I thought about it again, and ASUS not adding the ECC traces for their desktop boards does make sense. They'd save a lot of money not needing to test that stuff or for extending their QVLs with ECC memory when the whole WS/workstation series of boards can do it and bring in a 100 bucks more per unit. The only reason why they'd be there would be if ASUS wasn't originally sure which markets to target with those specific boards of the very first S1366 generation.. Still unlikely?
So even if I would hit the jackpot, I'll probably never even notice it, if my mainboard doesn't have the physical connections..
Given that there are multiple uncertainties, I might be on the wrong platform for attempting this..
I do have the pinouts for the DIMM sockets and the LGA1366, but who can tell whether those pins are connected or not, given the board has so many layers the traces could sit on...
It doesn't matter. If any result is reached, and it turns out to corrupt data rather than protecting it, all I can lose is data on a Debian testing installation that I'm gonna wipe anyway.
But it's not like this is going anywhere. I believe I'm stuck as it stands (which is why I posted here, as I was hoping somebody could provide further insight).
I thought about it again, and ASUS not adding the ECC traces for their desktop boards does make sense. They'd save a lot of money not needing to test that stuff or for extending their QVLs with ECC memory when the whole WS/workstation series of boards can do it and bring in a 100 bucks more per unit. The only reason why they'd be there would be if ASUS wasn't originally sure which markets to target with those specific boards of the very first S1366 generation.. Still unlikely?
So even if I would hit the jackpot, I'll probably never even notice it, if my mainboard doesn't have the physical connections..
Given that there are multiple uncertainties, I might be on the wrong platform for attempting this..
I do have the pinouts for the DIMM sockets and the LGA1366, but who can tell whether those pins are connected or not, given the board has so many layers the traces could sit on...
Sorry for the double post..
I'm a bit lost. At first I thought the traces just aren't there like Dan suggested, as I could not get a connection between DDR2_ECC[3] in the LGA1366 and CB[3] on the DIMM socket. To verify it, I tried to connect DQ[0] on the DIMM (pin #3) and DDR2_DQ[0] in the socket (pin W34). And it's the same thing, there is seemingly no connection.
But that's a DDR3 data pin, it's got to be connected?! I tried a few other circuits on the board, and continuity measurements worked there.
I checked everything multiple times, pin locations, correct memory channel and all, but I must be doing something wrong..