What is the 9-pin header above the top PCIe x16 slot?

[R5Eandme]

Well, on the plus side, a surface-mounted SOIC isn't going to have thru-hole leads which can connect to anything in other/hidden layers, lol. So soldering a socket or breakout in place is no big deal. (Btw, you can get SOIC8 carriers with black PCBs which would look much better on black gaming mobos, lol.)

I prefer (re)programming chips out of circuit whenever possible. And I prefer swappable socketed packages for these whenever possible. But, to be honest, I tend to swap BIOS very infrequently unless the project is all about tinkering with the board itself - and I haven't seen any of these BIOS chips fail (yet) in "normal" use, so I expect needing to replace "non-replaceable" parts isn't a real issue.

I haven't thought about the SOIC chip connecting only to surface PCB traces but you must be right about that. A surface trace pattern from chip to header (1 2 across, then down, then 3 4 across, then down, etc) would be possible with that chip oriented the way it is. I never understood how multi-layered PCB traces can work reliably but I guess they do most of the time, lol.

I am glad that BIOS chip failure is rare. But I did destroy the backup chip on the R5E simply by using the ASUS BIOS Copy utility! The fact that several vendors supply pre-programmed replacement BIOS chips tells you that it happens to the unlucky more often than getting hit with lightning.

[Korth]

Bad flashes can and do happen from time to time, even under ideal conditions without any apparent causes.
It's a rare occurrence, but I suppose it will always manifest when multiplied by enough users doing enough flashes (often under less-than-ideal conditions), lol, look at how many smartphones and laptops get bricked this way every year.

Redundant dual-BIOS substantially offsets the risk of total failure. But it's still nice to have access to this embedded factory header for BIOS part programming, if it should ever be needed.

[R5Eandme]

Bad flashes can and do happen from time to time, even under ideal conditions without any apparent causes.
It's a rare occurrence, but I suppose it will always manifest when multiplied by enough users doing enough flashes (often under less-than-ideal conditions), lol, look at how many smartphones and laptops get bricked this way every year.

Redundant dual-BIOS substantially offsets the risk of total failure. But it's still nice to have access to this embedded factory header for BIOS part programming, if it should ever be needed.

Absolutely. That flashing header compensates a lot for the inconvenience of having a surface mounted chip go bad. I plan to assemble this flashing cable and use it just to read a copy of the BIOS chip into a bin file using my SPI EEPROM programmer. That way I can write it back to a replacement chip should it become necessary. In addition to the BIOS program, the read bin file should contain the motherboard serial number, primary card mac address and motherboard UUID, not that I am convinced that extra info is really needed. I read that some motherboards won't post without it, but I am guessing that is the exception.

[R5Eandme]

My Crosshair VI Extreme has arrived and I noticed that instead of the Winbond W25Q128FVIG SPI BIOS chip, it uses a 25LB128CSIG (SOIC8 package). I cannot find the datasheet for this part, but a couple of 3rd party vendors of pre-programmed BIOS chips (eBay) say that multiple suppliers are sourced for BIOS chips by ASUS, and that the 25LB128CSIG is compatible with 25Q128 series such as W25Q128FVSG which they provide to owners of Crosshair VI Extreme, and I assume Hero as well.

I found out that the GigaDevice 25LB128 BIOS chip found on my Crosshair VI Extreme, and the similar 25LQ128 are NOT equivalent to the Windbond W25Q128 BIOS chips. The W25Q128 uses a VCC range from 2.7V to 3.6V. The 25LQ128 data sheet designates VCC=1.8V. Elmor did state that the AM4 boards use VCC=1.8V for the BIOS chips. So if you program the BIOS chip 25LB128 on an AMD board such as the C6E, you must use VCC=1.8V to avoid damaging the chip. Also program it with the board powered down.

Here is a chart from the GigaDevice product selection guide that shows the VCC input voltages for SPI chips. Note that "Q" denotes 3V while "LB" and "LQ" denote 1.8V




My GQ4x4 SPI programmer supplies 5V, but they provide an adapter for reducing that VCC down to your choice of 1.8V or 2.4V.

http://www.mcumall.com/comersus/stor...idProduct=4630

[R5Eandme]

I found out that the GigaDevice 25LB128 BIOS chip found on my Crosshair VI Extreme, and the similar 25LQ128 are NOT equivalent to the Windbond W25Q128 BIOS chips. The W25Q128 uses a VCC range from 2.7V to 3.6V. The 25LQ128 data sheet designates VCC=1.8V. Elmor did state that the AM4 boards use VCC=1.8V for the BIOS chips. So if you program the BIOS chip 25LB128 on an AMD board such as the C6E, you must use VCC=1.8V to avoid damaging the chip. Also program it with the board powered down.

Here is a chart from the GigaDevice product selection guide that shows the VCC input voltages for SPI chips. Note that "Q" denotes 3V while "LB" and "LQ" denote 1.8V




My GQ4x4 SPI programmer supplies 5V, but they provide an adapter for reducing that VCC down to your choice of 1.8V or 2.4V.

http://www.mcumall.com/comersus/stor...idProduct=4630

As of June 2018, the GQ4x4 SPI programmer can now program the GD25LQ128 chips, and I assume GD25LB128 found on ASUS Crosshair VI. Previously you needed to provide custom code.

[Korth]

I found out that the GigaDevice 25LB128 BIOS chip found on my Crosshair VI Extreme, and the similar 25LQ128 are NOT equivalent to the Windbond W25Q128 BIOS chips. The W25Q128 uses a VCC range from 2.7V to 3.6V. The 25LQ128 data sheet designates VCC=1.8V. Elmor did state that the AM4 boards use VCC=1.8V for the BIOS chips. So if you program the BIOS chip 25LB128 on an AMD board such as the C6E, you must use VCC=1.8V to avoid damaging the chip. Also program it with the board powered down.

Good to know.

I'd always physically inspect the part markings, of course, that extra minute might be a waste but it can sometimes save you the hassle of bricking a whole ($500+) mainboard, haha.

The SPIFlash chips I work with usually report part IDs to the programmer/software, which then configures voltages/etc (for compatible and listed parts, anyhow) as needed. These parts don't do this?

[R5Eandme]

Good to know.

I'd always physically inspect the part markings, of course, that extra minute might be a waste but it can sometimes save you the hassle of bricking a whole ($500+) mainboard, haha.

The SPIFlash chips I work with usually report part IDs to the programmer/software, which then configures voltages/etc (for compatible and listed parts, anyhow) as needed. These parts don't do this?

Hi Korth,

Yes the GQ4x4 reports the chip ID (see image), but there is a "DEVICES.TXT" file that gives the programmer instructions for each chip type/ID. You can add your own custom code as well. If the chip you have in the ZIF socket differs from the DEVICES.TXT entry that you have chosen you will get an error message and you decide to abort or proceed. You can safely proceed if the VCC and other parameters are the same as the chip you are programming as there are almost identical chips with different IDs. GQ4x4 also includes an adapter for lowering VCC to 1.8v or 2.4v for the AMD4 socket boards.

[moheban79]

Hi,

Was able to use the SPI header on an Asus Z270-WS no problem but on my APEX IX board my usb programmer device just can't get a read on the device. Is this because that is dual bios?

Thanks.

[R5Eandme]

Hi,

Was able to use the SPI header on an Asus Z270-WS no problem but on my APEX IX board my usb programmer device just can't get a read on the device. Is this because that is dual bios?

Thanks.

Hi moheban,

I have only read and programmed BIOS chips out of circuit. I don't know why there was a problem with the dual-BIOS board. Does your SPI EEPROM flash device have the spec data needed to read the chips on your dual BIOS board? On my SPI reader the data set has to contain a spec record for the chip being read. Otherwise it cannot know what voltage to supply, for example. Maybe the voltage supplied by your SPI flash device is not correct for the chip specs? You can get the VCC from an online data sheet. Just some ideas I am curious what is the chip designation on those boards?

Congratulations of being able to use a cable to header connection on that Z270-WS board. Did you read, write or both?

[moheban79]

Hi moheban,

I have only read and programmed BIOS chips out of circuit. I don't know why there was a problem with the dual-BIOS board. Does your SPI EEPROM flash device have the spec data needed to read the chips on your dual BIOS board? On my SPI reader the data set has to contain a spec record for the chip being read. Otherwise it cannot know what voltage to supply, for example. Maybe the voltage supplied by your SPI flash device is not correct for the chip specs? You can get the VCC from an online data sheet. Just some ideas I am curious what is the chip designation on those boards?

Congratulations of being able to use a cable to header connection on that Z270-WS board. Did you read, write or both?

Not only could I read and write to the Z270-WS but to the Apex IX board as well as those 1-2-3 jumper positions did indeed control which bios chip to read and write to. Perhaps before I was using a bad jumper or didn't have a solid connection but after one last try it worked and I was able to flash Dsanke's Z370 Apex X bios mod onto both bios chips and use a 9700K to run the board. This was all accomplished with the Flashcat Classic usb programmer. I do recall however needing to update the onboard rom belonging to the Flashcat first. Maybe thats why it didn't work the first time. Can't be sure but works like a dream now. Had to manually wire it up using motherboard header pitch wire on the corresponding Vcc-Vcc, Si-So, So-Si, Sclk-Sclk, etc connections. Thanks.