Skip to main content
Topic: Flashing Winbond 25Q64BV Chip (Read 37920 times) previous topic - next topic

Flashing Winbond 25Q64BV Chip

Hello community,

I am attempting to flash (or at present probe) the Winbond 25Q64 BIOS chip on a motherboard using the Bus Pirate. I went about this in the most common sense way, but it didn’t work; so I troubleshot until I found what I believe to be the problem. I may have overlooked something simple, however, so I will be giving a detailed account of exactly what I have done (so be prepared for a long post).

First, the chip I am trying to flash is the Winbond 25Q64BV, whose datasheet is here. Anyway, it is an 8-pin package, but two of the pins (write-protect and hold) are not relevant to me. So I use the following connections:
Code: [Select]
Bus Pirate	W25Q64BV
CS          /CS
3.3V        VCC
MISO        DO
CLK          CLK
GND          GND
MOSI        DI
Simple enough. Then, I use flashrom to try to probe the chip:
Code: [Select]
$ flashrom -VVV -c W25Q64 -p buspirate_spi:dev=/dev/ttyUSB0
flashrom v0.9.5.2-r1540 on Linux 3.3.3-gentoo (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org

flashrom was built with libpci 3.1.9, GCC 4.6.2, little endian
Command line (5 args): ./flashrom -VVV -c W25Q64 -p buspirate_spi:dev=/dev/ttyUSB0
Calibrating delay loop... OS timer resolution is 2 usecs, 1088M loops per second, 10 myus = 12 us, 100 myus = 100 us, 1000 myus = 995 us, 10000 myus = 9933 us, 8 myus = 9 us, OK.
Initializing buspirate_spi programmer
SPI speed is 8MHz
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 0 Sending 0x00, receiving
buspirate_sendrecv: write 1, read 5 Sending 0x00, receiving 0x42 0x42 0x49 0x4f 0x31
Raw bitbang mode version 1
buspirate_sendrecv: write 1, read 4 Sending 0x01, receiving 0x53 0x50 0x49 0x31
Raw SPI mode version 1
buspirate_sendrecv: write 1, read 1 Sending 0x4b, receiving 0x01
buspirate_sendrecv: write 1, read 1 Sending 0x67, receiving 0x01
buspirate_sendrecv: write 1, read 1 Sending 0x8a, receiving 0x01
buspirate_sendrecv: write 1, read 1 Sending 0x03, receiving 0x01
The following protocols are supported: SPI.
Probing for Winbond W25Q64, 8192 kB: buspirate_sendrecv: write 7, read 7 Sending 0x02 0x13 0x9f 0x00 0x00 0x00 0x03, receiving 0x01 0x01 0x00 0x00 0x00 0x00 0x01
RDID returned 0x00 0x00 0x00. RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0x00, id2 0x00
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
buspirate_sendrecv: write 1, read 5 Sending 0x00, receiving 0x42 0x42 0x49 0x4f 0x31
Raw bitbang mode version 1
buspirate_sendrecv: write 1, read 0 Sending 0x0f, receiving
Bus Pirate shutdown completed.
Okay, so what went wrong? It took some reading of the buspirate_spi.c source code as well as SPI_(binary) docs to figure out what it all means. The first 20 null bytes sent put the Bus Pirate in raw bitbang mode and return the string “BBIO1”. Then raw SPI mode is entered by sending the byte [tt:]0x01[/tt:] and receiving the string “SPI1”. Then some configuration bytes are sent all successfully (in order, configure power supply on, pull-ups off, AUX and CS high, speed to 8MHz, Hi-Z off, CKP low, CKE active-to-idle, and SMP middle). Finally, reset CS to high successfully.

Then, the actual JEDEC command is sent: set CS low, inform the Bus Pirate of a 4-byte send/receive, send the byte [tt:]0x9f[/tt:] followed by three dummies, and finally set CS high. The only problem is that the three bytes read all all null, but they should be (according to the datasheet 0xef, 0x40, and 0x17). Well, this is puzzling. It’s as if the chip is not even talking back (the same results are obtained with the header disconnected). Btw, I did try different speeds, but the datasheet says it should work at speeds of up to 80MHz.

So I then attempted to do it manually.
Code: [Select]
Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>5
Set speed:
 1. 30KHz
 2. 125KHz
 3. 250KHz
 4. 1MHz

(1)>
Clock polarity:
 1. Idle low *default
 2. Idle high

(1)>
Output clock edge:
 1. Idle to active
 2. Active to idle *default

(2)>
Input sample phase:
 1. Middle *default
 2. End

(1)>
CS:
 1. CS
 2. /CS *default

(2)>
Select output type:
 1. Open drain (H=Hi-Z, L=GND)
 2. Normal (H=3.3V, L=GND)

(1)>2
Ready
SPI>W
Power supplies ON
SPI>i
Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
CFG1:0xFFDF CFG2:0xFF7F
*----------*
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND    3.3V    5.0V    ADC    VPU    AUX    CLK    MOSI    CS      MISO
P      P      P      I      I      I      O      O      O      I
GND    3.38V  4.89V  0.00V  0.00V  L      L      L      H      L
Power supplies OFF, Pull-up resistors OFF, Normal outputs (H=3.3v, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls AUX pin
SPI (spd ckp ske smp csl hiz)=( 1 0 1 0 1 0 )
*----------*
SPI>[ 0x9F, r:3 ]
/CS ENABLED
WRITE: 0x9F
READ: 0x00 0x00 0x00
/CS DISABLED
SPI>w
Power supplies OFF
SPI>
As you can see, the same results.

Then, I decided to start probing things. First, without connecting the header to the 25Q64BV, I get to the point in the interactive usage above where I have turned on the power supply (“W”). I verify with a voltmeter that I am getting 3.3V on power pin. Then, since CS should be high, I do the same verification. This checks out (3.29V on the voltmeter for both CS and 3.3V).

I turn off the power supply (“w”) before reconnecting the header. It’s when I connect the header and press “W”, however, that things get interesting. I probe the pins on the chip itself. As expected, VCC is 3.29V. The CS pin, however, is at 1.59V (less than half of what it should be). When I press “[” it should go low (and it does—something like 0.2mV), and upon “]” it should go high again (and again it’s at 1.6V). Is it mistakenly in Hi-Z mode?

I turn off the power and swap the leads going to CS and VCC (my reasoning here is that I just want to verify voltages and see if CS is in some strange mode to get pulled so low). Without doing anything beyond turning the power supply on, in the default state, the result should be the same (as both CS and VCC should be at 3.3V). Interestingly, in this scenario, I find that both pins do have the correct voltage (the CS pin on the chip is at 3.29V as is the VCC pin).

Reading the datasheet (page 9), it states, “After power-up, /CS must transition from high to low before a new instruction will be accepted. The /CS input must track the VCC supply level at power-up (see ‘Write Protection’ and figure 31). If needed a pull-up resister on /CS can be used to accomplish this.” I believe this to be the problem (the 25Q64BV never actually comes out of standby since 1.6V is not enough to be high, so my flashrom thinks it’s connected to nothing). According to my knowledge, a pull-up resistor should not be needed as the Bus Pirate CS should correctly go high. Is this a firmware problem? A hardware problem? A user problem?

Please help, and thank you in advance.

Re: Flashing Winbond 25Q64BV Chip

Reply #1
Hi osor,

I'm sorry about the problem, thanks for the detailed report.

Just to verify:
1. CS high is 3.3volts when you are NOT connected to the chip
2. When you connect to the chip, CS only reaches 1.6volts

Is it possible the chip pin is grounding for some reason? (incorrect connection)

The chip is in the motherboard, is it possible the MB is holding that pin low?

Do you have a 2K to 100K resistor handy? Try connecting one side of the resistor to a 3.3volt supply (bus pirate maybe) and the other end to the CS pin of the in-situ flash chip. Measure the voltage on the pin. It should be 3.3volts, but if something is pulling low it will be 0volts.

A firmware issue is certainly possible, but common stuff in v5.10 is very well tested. You could perform the opposite test on the Bus Pirate. Connect the on-board pullup resistors to ground (Vpu to GND). Enable them in the terminal (P) and then raise CS high. If it is in hiz or a hardware failure, it read 0volts/low in the i menu.

I will load v5.10 and check it out later today, you could also try the latest v6.1.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashing Winbond 25Q64BV Chip

Reply #2
Ah, the perils of flashing a chip on the mainboard.
It is possible that the board is pulling CS# down. Such funny business is rather likely if this is a modern Intel board or a laptop.
Are you 100% sure the mainboard is not attached to any power source (I don't mean "switched off", I mean physical unplugging of the power plug/source of the mainboard)?
Even if all power is unplugged, the Bus Pirate might actually supply enough power to the board (indirectly by powering the 3.3V line attached to the flash chip) for some chips on the mainboard (southbridge and/or SuperIO and/or EC) to start accessing the chip. The constant CS# up/down caused by potential chip accesses from mainboard components might be averaged out by your multimeter to read 1.6V on CS#.

Which mainboard is this, by the way?
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashing Winbond 25Q64BV Chip

Reply #3
Thanks to both of you for the suggestions.
[quote author="ian"]
Just to verify:
1. CS high is 3.3volts when you are NOT connected to the chip
2. When you connect to the chip, CS only reaches 1.6volts
[/quote]Yes, and yes.[quote author="biosflasher"]Ah, the perils of flashing a chip on the mainboard.
It is possible that the board is pulling CS# down. Such funny business is rather likely if this is a modern Intel board or a laptop.
Are you 100% sure the mainboard is not attached to any power source (I don't mean "switched off", I mean physical unplugging of the power plug/source of the mainboard)?[/quote]I have unplugged everything from the motherboard (including the small button cell which is supposed to run the RTC) and taken it out of the case. It is bare, sitting on the workbench on anti-static foam. The motherboard model is ECS X79R-AX, but just to give you an idea, I have attached an image of the 25Q64: [attachment=1]I simply connect the female header terminal ends of the Bus Pirate cable directly to the relevant pins of the SPI_DEBUG header on the board (the top left is pin 1—CS). When I probe voltages, I am putting the probe leads directly on the pins of the chip.

Unfortunately, but somewhat predictably, the SPI_DEBUG header is not documented in the manual (IIRC it says something to the effect of “factory use only”). But the simple fact that it exists leads me to believe that this chip is meant to be programmable in situ.
[quote author="ian"]
Do you have a 2K to 100K resistor handy? Try connecting one side of the resistor to a 3.3volt supply (bus pirate maybe) and the other end to the CS pin of the in-situ flash chip. Measure the voltage on the pin. It should be 3.3volts, but if something is pulling low it will be 0volts.[/quote]The results of this experiment are interesting. I used a 10k resistor, but rather than 3.3V, I get a reading of 0.56V on the CS pin. Just to be clear on the setup, I have attached a schematic:[attachment=0]With a voltage drop of 2.74V there seems to some sort of internal circuit to ground, with an internal resistance of about 2k, though I am not really sure what it means. The datasheet says that standby current is at max 50µA (which I believe should be current drawn through the VCC pin not the CS pin), but this is more like 300µA. I guess that the earlier reading of 1.6V puts the internal resistance of the Bus Pirate pin for CS at about 6k? I may be reading the datasheet incorrectly.
[quote author="ian"]A firmware issue is certainly possible, but common stuff in v5.10 is very well tested. You could perform the opposite test on the Bus Pirate. Connect the on-board pullup resistors to ground (Vpu to GND). Enable them in the terminal (P) and then raise CS high. If it is in hiz or a hardware failure, it read 0volts/low in the i menu.[/quote]I don’t quite understand. If I connect VPU to ground, how could any pin have positive voltage? Anyway, when I do this and press “P” in the terminal, it says:
Code: [Select]
SPI>P
Pull-up resistors ON
Warning: no voltage on Vpullup pin
Then, the “i” command does indeed show CS as low (but I don’t see how this is atypical given the setup). Of course a voltmeter on the CS pin (not connected to the chip, just the CS pin on the Bus Pirate) is around 0V as well.

I hesitate to remove the chip from the board because there are many small surface mount components nearby, which kind of puts a heat gun out of the question (and my desoldering skills with an iron are not that good). Moreover, as I already said, the mere presence of the header leads me to believe that it should be possible to flash in situ.

I will experiment further, and if either of you have any other suggestions or insight, please let me know. Thank you for your help so far.

Re: Flashing Winbond 25Q64BV Chip

Reply #4
By the way, please note that BIOS image downloads for modern Intel mainboards such as yours are often incomplete (missing Management Engine firmware), i.e. if you just blindly overwrite the flash chip contents, your board might not boot anymore and not even power on.

That said, can you try holding the board in reset by holding the reset button (or using a jumper to short-circuit the pins of the reset button connector) while you rerun the experiment with the 10k resistor? It might make a difference.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashing Winbond 25Q64BV Chip

Reply #5
Side note: If there really is pulldown resistor on CS#, that would be one of the stupidest designs I ever saw. A pullup would make sense, but a pulldown? The signal is active low, and a pulldown is a sure fire way to make the SPI flash chip interpret all sorts of static interference as commands.

Have you considered the possibility that the pins of the chip and the pins of the SPI connector have a different layout and that you might be mixing up the CS# pin with the WP# pin? A pulldown on WP# would be a pretty normal configuration, and even a pulldown on HOLD# would make some sense in a few circumstances.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashing Winbond 25Q64BV Chip

Reply #6
Thanks for doing the tests. It sounds like it is a connection problem to the chip, rather than a toasted Bus Pirate since the pins seem normally ok.

I concur with biosflasher, you may have some luck if you hold the reset button while repeating the resistor test. I would guess that if you provide 3.3volts over the header that the other chips are being (partly) powered and start to access the chip.

The debug header is interesting, and I would guess it has one of two normal use scenarios:
1. Power the board normally with a ATX supply. Hold the reset button (or maybe there is another reset jumper or something) and then you may be able to access the chip without powering it from the Bus Pirate.
2.A logic analyzer or sniffer of some type connects here to monitor traffic passively.

I strongly feel you should be able to program over the header. The chip has to be flashed at the factory, and they need a way to rescue boards. The trick is going to be holding the rest of the PCB in reset. I think it is also likely this is best accomplished by powering the board externally instead of with the Bus Pirate.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashing Winbond 25Q64BV Chip

Reply #7
Also... a pull-down on the CS pin would be strange. It could be an incorrect pinout, it could also be that another chip is trying to access it and holding the line low.
Got a question? Please ask in the forum for the fastest answers.

Re: Flashing Winbond 25Q64BV Chip

Reply #8
Hello all, and thank you for your suggestions.

Sorry for the long delay, but here is an update. First, to address some questions:
[quote author="biosflasher"]By the way, please note that BIOS image downloads for modern Intel mainboards such as yours are often incomplete (missing Management Engine firmware), i.e. if you just blindly overwrite the flash chip contents, your board might not boot anymore and not even power on.[/quote]I kind of figured this out already (simply because the rom image from the website is exactly 4MiB, whereas the chip size is exactly 8MiB). Right now, I have sort of a semi-working BIOS (it will POST and allow me to edit settings, but will not boot), and I basically can’t get to the point of being able to use the vendor-supplied flashing software (which requires being able to boot an operating system, which is the problem in the first place). Rest assured, however, before doing any write operation, I will necessarily back up the current image on the chip.[quote author="biosflasher"]That said, can you try holding the board in reset by holding the reset button (or using a jumper to short-circuit the pins of the reset button connector) while you rerun the experiment with the 10k resistor? It might make a difference.[/quote]I tried this, but it gives the same result (though contrary to Ian’s later suggestion, the ATX power supply was not connected)[quote author="biosflasher"]Have you considered the possibility that the pins of the chip and the pins of the SPI connector have a different layout and that you might be mixing up the CS# pin with the WP# pin? A pulldown on WP# would be a pretty normal configuration, and even a pulldown on HOLD# would make some sense in a few circumstances.[/quote]As I said before, I have tested the pin connectivity with a multimeter. The header is in the same orientation on the PCB as the chip (the little circle for pin 1 corresponds to the little circle on the header, etc.). It turns out with further experimentation, however, that all the other pins (except VCC) have the same problem. That is, when I do the same resistor experiment with any of the five other pins, I get around 0.55V.[quote author="ian"]I strongly feel you should be able to program over the header. The chip has to be flashed at the factory, and they need a way to rescue boards. The trick is going to be holding the rest of the PCB in reset. I think it is also likely this is best accomplished by powering the board externally instead of with the Bus Pirate.[/quote]I was on the phone with an ECS tech who does this. They use a programmer called the DediProg SF100. According to the tech, they connect directly to the 2×4 SPI_DEBUG header. There is also a sort of alligator clip connector which physically goes on top of the ROM chip and makes contact with each pin.[attachment=0]Interestingly enough, the tech says that they don’t do anything special hardware-wise beyond that (I specifically asked if she held down reset or connected the ATX power supply). Apparently the SF100 software simply probes the chip and allows you to flash it through the header or alligator clip.

So at this point I am wondering what the SF100 does differently from the Bus Pirate. Does it simply not put any internal resistances on the pins, allowing them to source as much current as they desire? It seems to me that the conclusion is that these other pins are connected to another chip (likely the chip which loads the BIOS off the 25Q64BV in order to run it).  As I stated in my first post, when I connect the 3.3V power line directly to the CS pin on the header, the voltage remains at 3.3V (though I don’t know whether or not this is safe for the chip). I wonder if there is any way to disable the internal resistance on the Bus Pirate (I am not familiar enough with the BP to know how much current the PIC can source from its data pins nor if it is safe to replace certain PCB resistors with solder shorts). I am not even sure if this is the correct way of attacking the problem, but I am much less hesitant about desoldering on the BP than my on my motherboard.

[quote author="ian"]The debug header is interesting, and I would guess it has one of two normal use scenarios:
1. Power the board normally with a ATX supply. Hold the reset button (or maybe there is another reset jumper or something) and then you may be able to access the chip without powering it from the Bus Pirate.
2.A logic analyzer or sniffer of some type connects here to monitor traffic passively.[/quote]As I stated before, I have yet to try scenario 1 with the ATX power supply (but this is contrary to the method described by the tech). I do believe, however, that scenario 2 would work fine with the Bus Pirate in sniffer mode. I just don’t know that it would further my current goal.

I will do some futher experimentation and update you on the results (hopefully once this is resolved, it will be a guide for others trying in situ flashing (though I wonder if someone on seedpeer will sell a Bus Pirate cable terminated with an SOIC-8 alligator clip :)).

Re: Flashing Winbond 25Q64BV Chip

Reply #9
It's indeed possible that the Dediprog SF100 indeed supplies enough current on all pins to get the chip into the operation region. In that case, you'd probably need to chain a buffer between the Bus Pirate and the flash chip.

Another possibility is that e.g. the HOLD# pin or some other pin has a magic function which disables the pulldown if pulled high. Given your problem description, the "NEED MOAR CURRENTZ" variant is way more likely, though.
If you have any flashrom problems, please mail flashrom@flashrom.org and include "Bus Pirate" in the subject line. As an alternative, you can send me a private message.
It is recommended to use at least flashrom 0.9.2 or later, and latest flashrom from svn if you want a 3x speedup.

Re: Flashing Winbond 25Q64BV Chip

Reply #10
[quote author="biosflasher"]It's indeed possible that the Dediprog SF100 indeed supplies enough current on all pins to get the chip into the operation region. In that case, you'd probably need to chain a buffer between the Bus Pirate and the flash chip.[/quote]I am not an EE, but I do have rudimentary circuit knowledge from physics class. Is it possible to do this with N-channel MOSFETs (as I have some available) using common drain configuration? I also have an LM324 quad op-amp, which should be able to do all four pins, but I don’t quite know about the timing above 30kHz.

Is there no way to replace some of the Bus Pirate on board resistors with solder bridges? I don’t think I actually need to supply the extra current if the PIC can’t handle it, I just need the 25Q65 to see the correct voltage (as it should draw negligible current itself). Or am I wrong about that?

Also to clarify this statement:[quote author="osor"]According to the tech, they connect directly to the 2×4 SPI_DEBUG header. There is also a sort of alligator clip connector which physically goes on top of the ROM chip and makes contact with each pin.[/quote]They of course don’t use both the header and the alligator clip at the same time (which perhaps it seemed like from my wording).

Re: Flashing Winbond 25Q64BV Chip

Reply #11
Quote
I kind of figured this out already (simply because the rom image from the website is exactly 4MiB, whereas the chip size is exactly 8MiB).

This is actually pretty common. We have a project that uses 2MiB flash, but 8MiB is WAY cheaper and WAY easier to get, so we use it and only write the first 2 MiB.

Quote
I wonder if there is any way to disable the internal resistance on the Bus Pirate

The PIC pins are rated for 20mA current draw internally, and the power supplies 150mA. I can't really imagine a scenario where 20mA on the pins isn't sufficient. As far as I know nothing can be changed about the internal structure of the Bus Pirate pins.

Quote
Is there no way to replace some of the Bus Pirate on board resistors with solder bridges?

I recommend against this. The pullup resistors are not needed when you interface this 3.3volt chip, and shorting the pullup resistors will short 10mA+ through each pin of the 4066 chip and probably let out the magic smoke.

I think we're still missing a key piece of info.

When the Bus Pirate is attached to the chip and powering the board the CS pin is too low.

This suggests that another chip on the board is pulling it down, really hard. 20mA+ is being sunk through that pin. There is no scenario I can see where 20mA on CS is needed, nor would it be normal (or reasonable IMHO) to power something with 20mA+ on the CS pin. I don't think it's likely that more current is needed on CS, doing so will probably pop whatever chip is holding CS low.

I did try to look at the product spec sheet of the dediprog, but it is corrupted when I try to open the PDF. You're certain the tech said they program the bios without powering the board though ATX?

The 150mA from the Bus Pirate supply is likely insufficient to power the whole mother board, but they may have a diode or something to prevent that. The dediprog is USB powered, so at most it could also only provide 500mA (in general) to power the device. This is testable by powering the header with another 3.3volt supply with at least 500mA output.

I still think something else on the board is trying to use the chip at the same time and trying to hold CS low. CS on the chip would not sink any current (well, a few uA as an input). Any external pullup resistor would also likely pull high, not pull low. If there was a pulldown to low, enough to ground the PIC pin, it would have to be like 0.1ohms, and that seems highly unlikely. When the board is powered it should try to POST and load the bios from the ROM chip. Unless that is prevented somehow I'm not sure how to program it. I have never worked with an insitu bios chip though, biosflasher has all the experience in that area though.
Got a question? Please ask in the forum for the fastest answers.