DISCLAIMER: If you attempt to reflash your screen's firmware, there is always a chance that something goes wrong, and that you end up with a very expensive brick. As always, I cannot be held responsible in this case.

Important Note: as you can see by reading the above forum topic, people have had mixed results, depending on the hardware they used. So if the update fails the first time you attempt it, don't panic, and simply retry it using a different desktop or laptop.

Update (2014-05-04): A new version of the patch is available, that removes the hardcoded path and address, and has better error messages. The article has been updated.

Update (2014-05-07): A new version of the patch is available, that adds a "noreset" option. When set, the reset command will not be sent at the end of the read/write operation. Furthermore, the reset command will also be skipped in the event an error occurred during the process. This aims to prevent bricking the screen, since the reset command seems to do more than just exit the ISP mode. Simply run flashrom in chip identification mode, without the reset option, after a successful flash, to exit the ISP mode.

I recently bought a XL2411Z screen, but it turned out that Blur Reduction, its "key selling feature", wasn't working properly.

BenQ then released a V2 firmware, but no instruction or tool allowing to reflash the firmware. The only available options were to buy a 50$ USB flasher, or to build a parallel port one, and use some proprietary and windows-only tool by MSTAR, the company that provides the chip used in these screens.

MSTAR offers no datasheet for their products, so buying a one-time use flasher wasn't really interesting, and building yet another parallel port adapter to use a completely obscure utility wasn't really challenging (even if I had the possibility to borrow a computer with a parallel port, this isn't necessarily everyone's case nowadays).

I then read a bit more about DDC, the I2C based protocol allowing to exchange information between screens and computers, and I guessed that since it uses I2C, and since MSTAR seem to provide a way to flash SPI flash chips through I2C for many of their products, there were good chances that the same protocol would also be exposed through the I2C bus used by DDC on my screen.

So, I decided to scan the I2C bus. I plugged the screen to my laptop using a VGA cable (so yeah, by the way, you'll need a PC or laptop running GNU/Linux, probably also a second screen (or remote shell) in the case it's a PC, since the one you'll be flashing has to be in standby mode during the operation, and the driver of your graphics card or chipset must register the DDC channel as an I2C bus to the Linux kernel. Intel and ATI hardware using the open source driver are OK, ATI proprietary driver is not as it doesn't expose I2C, I don't know about Nvidia open source or proprietary drivers), and ran the following commands:

Bingo! There were 4 I2C addresses responding. 0x37 and 0x50 are the "well known addresses" for DDC/CI and the EDID EEPROM, and as for 0x49 and 0x59, they are 7bit I2C addresses, which, when shifted for the R/W bit can also be represented as 0x92 and 0xb2, which appear in various service manuals of TV sets and monitors based on MSTAR chips (as well as in screenshots of the MSTAR ISP utility), and are described as 0x49/0x92 being the ISP (in-system programming) port, and 0x59/0xb2 being a debug port.

I then analyzed the two drivers that I mentioned earlier, and realized that the MSTAR ISP protocol is composed of 5 I2C commands (enable ISP, read/write, end r/w command, and reset) that merely encapsulate the SPI commands that can be found in the SPI flash chips' datasheets.

I then simply had to write a SPI programmer for the flashrom tool following the MSTAR I2C ISP protocol, and voilà!, moments later, I was flashing my screen's firmware.

Also, please note that I2C works at 100kb/s, and thus, reading and writing the firmware takes a long time. Reading the 2MB takes 3 and a half minutes (and 8192 commands), and writing, which includes verifying afterwards, takes almost 10 minutes (and 32768 commands).

This version is:* derived from Firmware v1.2 sources* ported MSP430 architecture* tested on msp430g2452 and msp430g2211* built from scrap parts

Following are a hand-drawn schematic and the accompanying "routing" diagram (note that there are a pull-up resistor and a pull-down capacitor missing on ¬RST, but the one on P1.3 is handled by P1REN):

You can have a look at the repository for my changes, its origin is the v1.2 sources.

There are currently three different branches:* with_crystal_sync uses an external 32 KHz Xtal for clock calibration* master uses the factory-calibrated values instead, eliminating the need for the external Xtal, and saving a few dozen bytes* 8k_fill removes the debugging code to fill the 8 KB of ROM of the MSP430G2452 with as many TV codes as possible

Most of the changes are hardware related, and can be found in the following functions of main.c:* main: clock setup, hardware configuration, main loop providing low power mode switching* blast_code: timer setup for the carrier* xmitCodeElement: output pin function selection depending on carrier usage

Note that I initially tried to use an interrupt to handle the carrier manually, instead of relying on the Capture/Compare Control Register, which turned out to not work so great, due to the delay function not accounting for the time spent in the interrupt handler.

Disclaimer: This is totally unsupported! I won't be responsible if you Mac Pro catches fire or simply refuses to boot afterwards. I did the update on a 2006 Mac Pro, running the MP21.007F.B06 EFI firmware and 1.7f10 SMC firmware. Anything else, I can't guarantee.

Following MacEFIRom's work on his Mac Pro 2006-2007 Firmware Tool (you need to be registered to see the download link), here is a way to update the SMC, to complete the 2006-2007 conversion.

The first 5 bytes replace the call to the function that checks whether the upgrade path is approved by Apple (isValidConfig) by xor eax, eax; nop; nop; nop.The next 9 bytes replace a comparison and a conditional jump (related to a global variable set by isValidConfig) by 9 nops.And the last 5 bytes replace the call to the function that prevents from downgrading the SMC firmware by xor eax, eax; inc eax; nop; nop.

If you edited the file properly, its md5 sum should now be 84dbe9708eafc0c29653414b06292f8e.

In order to use it, copy the two files to a EFI accessible partition (FAT or HFS), boot to the EFI Shell, and simply issue the command:

SmcFlasher.efi -LoadApp m43a.smc

To boot the EFI Shell, simply install rEFIt. you can also take a shell.efi binary (for instance, from rEFIt's tools), rename it to boot.efi and copy it at the root of a FAT formatted USB key. You can then boot the key using the Mac Pro built-in boot selector (holding Alt before the chime).

Don't forget to chmod +x ~/.w3m/cgi-bin/magnet.py, modify the cmd_list tuple to match your host, port, and authentication parameters, and you should be set. Hitting "Enter" on a magnet link should now add it to your queue.

First, mount the graphics update image and use Pacifist to open it. You'll need to extract two files from here, using administrator privileges: ATIROMFlasher.kext and ATIFacelessFlash.app.

After extracting them, we'll first need to make sure the kext is able to load. Open a Terminal, and run "sudo kextutil -nt ATIROMFlasher.kext" to check whatever problems it might have.

On my system, it complained about authentication failures, and also showed a few warnings. The warnings can be ignored, but the auth issues have to be fixed, using those two commands: "sudo chown -R root:wheel ATIROMFlasher.kext" and "sudo chmod -R 644 ATIROMFlasher.kext".

Note: removing the other firmwares is only important if you have other ATI cards in your mac. When ran, the ATIFacelessFlash application looks for all files in the Resources directory, tries to find a match in your PCI devices, and when one is found, initiates the flashing. So it could "harm" one of your other ATI cards. And I don't know how it behaves with a 4870X2 card, *IF* it is seen by the system as two cards with the same ID, *BUT* each need a different firmware for the card to work fine. From a quick disassembly, I'd say that only the first one would be flashed.

Now, time to plug the PC 4870 card in your machine. I had it in the 1st PCI Excodess slot, with no display connected, and the 7300 GT that originally came with my Mac in the 3rd PCI Excodess slot, driving my display. I don't know if MacOS X can boot without any graphics card, but if it does, you could also use ssh instead of a second card, if you have a second machine available.

Restart your mac, and flash the card: "sudo kextload ATIROMFlasher.kext" (loads the interface to the card), "sudo open ATIFacelessFlash.app" (flashes the card. The app should appear in your Dock, wait for it to complete), "sudo kextunload ATIROMFlasher.kext" (unloads the interface).

Then reboot once more, and voilà, your 4870 is now a Mac card. No need to boot a FreeDOS CD, no need to create a FAT partition on your disks.