Use flashrom to read the old chip contents, then compare old contents and new file with a hex editor. This might give you a clue where the garbage is. If you're dealing with a mainboard BIOS/EFI, there is usually ca. 4 kB garbage at the end and no garbage at the beginning. I've never seen files with more than 16 kB garbage. Good luck!
Did you upgrade the Bus Pirate firmware since your first try? Older BPv4 firmware (sometime before firmware 6.2) is known broken because it handles the reset command in an unexpected way and causes flashrom to hang.
In theory, current flashrom in combination with BP (v3 or v4) firmware 6.2 (or newer) should work fine without any problems. If you can reproduce the hang in any way with BPv4 firmware 6.2 or newer and current flashrom 0.9.7-r1710 or newer, please tell me so I can investigate further.
Hi grasshopper, can you please post a full log with flashrom 0.9.7? Simply use the --output parameter for flashrom to get a log file with sufficient verbosity. If you post the contents of logfile.txt in here, I can take a look.
In this case, the Winbond W39V040A is _not_ a parallel flash chip, but a LPC flash chip (it can be programmed with some special parallel interface as well, but you don't want that). The Bus Pirate doesn't have enough pins to handle the LPC protocol. Your best bets are:
Using another mainboard with a LPC flash chip to hotflash your corrupted flash chip (i.e. boot other mainboard with its own chip, remove chip while board is runnung, insert corrupted chip, write to it with flashrom, remove corrupted/rewritten chip, insert old chip, be happy.
Get a VIA VT6421A SATA controller card. Those are really cheap (~12 EUR), desolder the flash chip, solder a PLCC32 socket on it, and then use it as programmer with flashrom (I think you have to tell flashrom to use the satavia driver). You may have to patch flashrom first (not sure if that driver is already merged).
Get a Raspberry Pi and wait for me to finish the LPC bitbanging code in flashrom (not in the next 4 weeks).
Please check how long the wires are... in my experience the wires should not be longer than 10 cm. Make sure the connections are mechanically stable and not in an electrically noisy environment.
Pro tip: Use at least flashrom 0.9.6.1 (preferably latest flashrom from svn) and Bus Pirate firmware 6.2 to get reasonable speed. Using a Raspberry Pi instead of a Bus Pirate is ~50x faster because it avoids USB roundtrips.
flashrom 0.9.1 is ancient! Apparently Backtrack Linux simply shipped the flashrom version present in old Debian stable. Kali Linux (successor to Backtrack) has flashrom 0.9.5.2, but AFAICS that version doesn't have all the workarounds for Bus Pirate firmware.
That said, would it help if we (flashrom developers) offered .deb package downloads on flashrom.org?
If anyone is willing to test a flashrom patch to detect the Bus Pirate v4 issue, please post here or send an email to [email:]firstname.lastname@example.org[/email:]. I hope to detect this BPv4 issue in the flashrom code so flashrom can print a warning and suggest a BPv4 firmware upgrade.
Hi melk0r, the Intel ME is indeed a likely culprit. Lifting the GND pin and keeping Vcc seems to solve the problem that HOLD# and WP# should be high because those are usually connected via pullup to Vcc. Another option may be to short-circuit the reset button/connector of the mainboard as long as you want to access the flash chip. Some people have claimed that this is sufficient to disable the Intel Management Engine. You may want to verify that claim with the SPI sniffer before you rerun flashrom. If it works, you can skip desoldering. Good luck! Please report your results so others can benefit.