I don't know what I did wrong, but now my MP won't boot if I have the XFX card in any slot. Even tried with my gt120 still in.
So I decided this flashing thing ain't for me. Guess I'm not smart enough.
If anyone is interested in profiting from my tragedy, I'm ebaying this probably very usable card.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=200444936156&ssPageName=ADME:L:LCA:US:1123
Dude, you don't necessarily need to get rid of your card. I mean you can do whatever you want of course haha, but I'm just saying. The card is not dead or a lost cause.
Let me give you a little background on the whole flashing deal:
So, I'll assume you don't know much about it. If you do I'm sorry that I'll sound a bit repetitive.
The rather simplified version is as follows:
The hardware in these cards is perfectly capable of working with any machine that implements PCI-E. PC's with PCIE and the MacPro, for instance fall into this category. So this means the card can work on both PCs and Macs. Now, the card has, among many other components, one IC (integrated circuit -- a chip) which acts as a general controller for the card. That is, this chip is the one that initializes the card, provides all the info that a machine wanting to use the card needs (for the machine to discover the card -- know what it's dealing with and what this card's capabilities are) and establishes a bridge between the hosting machine and the GPU (graphics processing unit -- like your comp's CPU but specific to graphics) in the card.
This controller is of type eeprom (electrically erasable programable read-only memory). The name eeprom is sort of a misnomer at this point because, being electrically-erasable and therefore re-programmable, it is not properly a read-only memory. But anyways this name is an extension of the original ROM chips which back in the day were hard-coded (by burning internal fuses in the chip) at the factory and, once programmed, could no longer be modified. The name just stuck in the industry as the ROM technology evolved throughout the years.
Technically, what we are doing here is flashing new firmware. That is, flashing implies that we erase the data inside the eeprom and upload new software to it. The software is the so-called ROM files, and again we speak of rom but they are firmware. This is another borderline term at this age, but it's basically software meant to run in a dedicated IC and mainly for controlling / interfacing purposes, as opposed to regular macro-scale software running in the context of an OS.
So, back to the story. Computers also have their own eeprom chips with their own firmware. This firmware is executed when the machine starts up, before any OS loading. When a machine starts up, before loading the os at all, one of the things the firmware does is to poll the buses (PCI for instance) to discover any devices plugged to the machine's motherboard. Any devices found, are queried for their info (model, make, capabilities,etc...) and are assigned a memory address so that the CPU in the computer can address them for future use.
So the sequence, sort of, is: machine's firmware in the machine's eeprom polls and queries the PCI bus-> the firmware in the eeprom's of different devices in the PCI bus (such as the video card) in turn, query their own hardware in the card and then report this info back to the machine's firmware. This way, by the time the OS starts loading, the kernel has enough info on what devices are present, what their characteristics are and what drivers to load up to interface with them in the context of the os.
So let's put all this together now. The main difference between a PC and a Mac at bootup time, that we are concerned with for the purposes of the card, is that the firmware involved in a PCs start up process is what we call the 'old-world' BIOS. BIOS historically means basic input output system and it's a firmware arquitecture for implementing this whole (simplified) process I (sort of) explained. In other words, a certain way of accomplishing this process. Macs, have for some time now been using a different version of the truth, called EFI (extensible firmware interface).
So Macs and PCs both go through this whole start up, discovery process. Only that PCs do it by implementing a BIOS architecture and Macs use an EFI architecture. The PC video cards we are dealing with here have BIOS-type firmware in their eeproms. So this means that if you plug them in a PC, they get along just fine with the PCs BIOS-based start up sequence and everything goes fine. If you plug the card in a Mac, however, this is not the case, because you are basically having the Mac's EFI trying to comunicate with a device in the PCI bus that speaks another language all together, mainly BIOS (this is somewhat figurative -- remember, BIOS or EFI are not 'languages'). So the symptom of plugin in the PC card with the original PC firmware (PC bios, PC rom, whatever you want to call it) is logical: the mac chimes and after that..... black screen. nothing. Basically, the Mac can't communicate with the eeprom in the card and can't do anything about it. The OS cannot start either, because OS X at least in its default state needs some standard output device in the form of a video interface.
If you plug in now another card, a mac one, and now you have 2 cards in the machine the story is different. Now, at start up, pre-os, again the mac can't communicate with your PC card. But it can certainly poll and query your second mac card, and this is the one that it adds to the list of devices that the kernel will need to load a driver for. This is why with the second card, you at least do get a grey screen in the mac and maybe even the apple logo.
At this point, though, this is where I am not entirely sure how the story continues... just because I've never looked into the os x booting process yet (I mainly do audio software these days). It appears that, at some point, in the process of loading drivers for the different devices, the kernel still runs into the 'foreign' card and something gets messed up. Maybe the kernel has mismatched info or sees some PCI device and has basic info on it and still tries to install a driver to interface with it (crash logs seems to imply this). In either case, something goes wrong and the machine will usually give you a so-called kernel panic because the attempt to interface with the PC card goes wrong.
So what are we doing when we flash the card? the idea is, we leave the BIOS code inside the firmware and we also add an EFI section of code which (I'd assume) does exactly the same as the BIOS code but comforming to the EFI architecture. In this way, if the card is in a machine with BIOS, the BIOS section of the card can communicate with this machine. If the card, in contrast, is in an EFI machine, then it can still communicate with this machine too, through it's EFI section of code. Makes sense?
Last, this firmware is specific to your card. I mean, there's a a lot of code that is going to be shared between different cards of the same manufacturer and if the cards are, say ... ZWFC's or something between those too. But still, the cards can be different revisions. And different revisions imply some firmware code in the eeprom has changed. So this is why you can't just flash the card with someone else's firmware unless you are positive they have the same card as you, down to the revision of the firmware. And the only way to figure out the revision of the firmware is by examining the firmware itself.
So what most probably happened to your card is that you flashed it to the firmware that Cindori made me. This firmware was unfortunately wrong, because he made a mistake and used the EFI section of a 4890 card and not a 4870. But besides that, it might also not been even the right BIOS section for your card, because you and me might have different revisions of the same card.
So your card is in a state of induced-brickness shall we say (as in it's brick right now but it's not permanent).
For one, you might have the wrong BIOS in it... so the card might still work in a PC (thought it might be glitchy because the BIOS inside it might be trying to do things that are not exactly right for the hardware actually present in the card).
Also, you definitely have the wrong EFI in it. So on the OS X side of things (on the EFI side we should say), things are definitely wrong. The EFI firmware in the card is going to try and do / report things that are totally mismatched in terms of the hardware actually present in the card.
The first thing you can do, if you haven't done so already, is to flash the card back to the orginial PC rom. Then you have once again the card fully functional in PC world as it shipped.
The second step would be to try to come up with the right BIOS/EFI hybrid firmware for your card. This is what I personally have been trying to do for a few days now with no success. The process basically amounts to:
1. Backup your original PC firmware
2. Extract the EFI firmware from a suitable mac firmware file for your card
3. merge these BIOS and EFI parts into one hybrid firmware
4. realign some jump tables here and there to account for the nasty-ass merging you just did.
The above steps are basically, the pipomolo method. Personally I haven't had 100% success with it so far...
I have at least one doubt about the above process. How do I make sure that the EFI firmware I'm extracting from a ROM file in step 2 is the right one? Because since there's different BIOS code for different revisions of the card, I'd assume there might as well be different EFI versions for different revisions of the card too. That's one thing I'm unsure about.
Still, say there only one EFI version of the code for a 4870. And say I have been using the right EFI code all along. I'm still having problems. So I wonder, is my problem then with re-aligning the code? The thing about this is that we are just executing a script that someone made. So, personally, I can't really tell too much how the code is really being modified. If I had a way of reading both the BIOS and EFI sections in either assembly (with references of course) or, better yet, in C, then I could better understand if the final firmware makes sense or not.
But that's a whole other story.
Anyways, this whole thing turned super long!!! I don't know, hope it's at least somewhat interesting. And yes, I might have totally got something I said wrong within all this stuff.....
