Hi,
I have a Dell OptiPlex 755 USFF which has an Atmel AT26DF321 SPI flash chip (which is like an AT25DF321 and has the same device ID except it doesn't have a HOLD# pin). I've used flashrom to read and write the same chip on another board by ISP using a BeagleBone Black, 10-cm jumper cables, a SOIC clip, and an ATX PSU.
However, flashrom with the same ISP setup fails to probe the chip on the OptiPlex. I've tried two different known-working BBBs, different cables, two different Pomona SOIC clips, connecting WP# to 3.3 V, connecting what would be HOLD# on the AT25 to 3.3 V, and different spispeed clock frequencies from 1 kHz to 10 MHz.
I've tried powering the chip (and the rest of the board's 3.3-V rail) with a 3.3-V line of the ATX PSU, and I've tried instead powering the whole board with the computer's 12-V PSU. I've also tried running flashrom while holding down the power button to keep the system in reset. Following some advice on http://flashrom.org/ISP I even tried removing the DIMMs and CPU.
Every time I get only bytes of 0xff from the chip, as in the attached log. In my experience that usually means either the programmer isn't properly connected to the chip or the programmer uses a different data voltage than the chip does. But I've checked and rechecked all of the connections, and I know both the BBB and the AT26DF321 use 3.3-V data signals.
Unfortunately there don't seem to be any schematics available for this board (Dell model number 0HX555, ODM model number HX533 A00, ODM might be Asustek or MiTAC). This system does have an Intel Management Engine in the northbridge, but even if that was running I should at least be able to probe the chip and read its contents.
Does anyone have any ideas of anything else I could try (short of desoldering the chip from the board) or about what the problem may be?
Thanks,
On Wednesday 12 August 2015, Patrick 'P. J.' McDermott wrote:
Hi,
I have a Dell OptiPlex 755 USFF which has an Atmel AT26DF321 SPI flash chip (which is like an AT25DF321 and has the same device ID except it doesn't have a HOLD# pin). I've used flashrom to read and write the same chip on another board by ISP using a BeagleBone Black, 10-cm jumper cables, a SOIC clip, and an ATX PSU.
However, flashrom with the same ISP setup fails to probe the chip on the OptiPlex. I've tried two different known-working BBBs, different cables, two different Pomona SOIC clips, connecting WP# to 3.3 V, connecting what would be HOLD# on the AT25 to 3.3 V, and different spispeed clock frequencies from 1 kHz to 10 MHz.
I've tried powering the chip (and the rest of the board's 3.3-V rail) with a 3.3-V line of the ATX PSU, and I've tried instead powering the whole board with the computer's 12-V PSU. I've also tried running flashrom while holding down the power button to keep the system in reset. Following some advice on http://flashrom.org/ISP I even tried removing the DIMMs and CPU.
Every time I get only bytes of 0xff from the chip, as in the attached log. In my experience that usually means either the programmer isn't properly connected to the chip or the programmer uses a different data voltage than the chip does. But I've checked and rechecked all of the connections, and I know both the BBB and the AT26DF321 use 3.3-V data signals.
Unfortunately there don't seem to be any schematics available for this board (Dell model number 0HX555, ODM model number HX533 A00, ODM might be Asustek or MiTAC). This system does have an Intel Management Engine in the northbridge, but even if that was running I should at least be able to probe the chip and read its contents.
Does anyone have any ideas of anything else I could try (short of desoldering the chip from the board) or about what the problem may be?
Thanks,
Try installing the SERVICE_MODE jumper - it should disable the management engine.
On 2015-08-12 02:26, Ondrej Zary wrote: [...]
Try installing the SERVICE_MODE jumper - it should disable the management engine.
Thanks for the suggestion. I've tried that, and I get the same 0xff output.
---
By the way, the ODM model number I quoted in my first message was wrong. It's HX553 A00.
On 2015-08-11 22:13, Patrick 'P. J.' McDermott wrote:
Hi,
I have a Dell OptiPlex 755 USFF which has an Atmel AT26DF321 SPI flash chip (which is like an AT25DF321 and has the same device ID except it doesn't have a HOLD# pin). I've used flashrom to read and write the same chip on another board by ISP using a BeagleBone Black, 10-cm jumper cables, a SOIC clip, and an ATX PSU.
[...]
Every time I get only bytes of 0xff from the chip, as in the attached log. In my experience that usually means either the programmer isn't properly connected to the chip or the programmer uses a different data voltage than the chip does. But I've checked and rechecked all of the connections, and I know both the BBB and the AT26DF321 use 3.3-V data signals.
Unfortunately there don't seem to be any schematics available for this board (Dell model number 0HX555, ODM model number HX533 A00, ODM might be Asustek or MiTAC). This system does have an Intel Management Engine in the northbridge, but even if that was running I should at least be able to probe the chip and read its contents.
Although I don't have schematics, I see resistors on the board on the CS#, SO, WP#, SCK, NC/HOLD#, and VCC lines, indicating that the board is likely designed for ISP.
damo22 looked at the datasheet [1] (the AT25 datasheet [2] is almost identical) and suggested that maybe the chip is in Deep Power-Down mode, which would explain why it's not responding to commands from flashrom on an external linux_spi programmer.
Is it possible that the AT26DF321 on this board is always put in Deep Power-Down mode by the ICH9 (Intel 82801IO) but the AT26DF321 on the other board I successfully tried (with an Intel 82801IEM ICH9M-E) is normally in standby? Has anyone else ever encountered an SPI flash chip in Deep Power-Down mode?
I looked through the source code to see if flashrom sends or could send a Resume from Deep Power-Down command. The command is a 0xAB opcode while CS# is asserted, followed by a deassertion of CS# and a delay of up to 3 µs. flashrom doesn't send this command, but all of that seems easily doable except for the CS# deassertion. Linux's Documentation/spi/spidev file says that the SPI_IOC_MESSAGE(N) request does not deselect the chip.
Any recommendations on how to proceed?
[1]: http://www.atmel.com/images/doc3633.pdf [2]: http://www.atmel.com/images/doc3669.pdf
On Thu, 13 Aug 2015 16:17:20 -0400 "Patrick 'P. J.' McDermott" pj@baldr1.pehjota.net wrote:
Although I don't have schematics, I see resistors on the board on the CS#, SO, WP#, SCK, NC/HOLD#, and VCC lines, indicating that the board is likely designed for ISP.
Not necessarily. Could be simple pull-ups (and a current limiter on VCC)...?
damo22 looked at the datasheet [1] (the AT25 datasheet [2] is almost identical) and suggested that maybe the chip is in Deep Power-Down mode, which would explain why it's not responding to commands from flashrom on an external linux_spi programmer.
Is it possible that the AT26DF321 on this board is always put in Deep Power-Down mode by the ICH9 (Intel 82801IO) but the AT26DF321 on the other board I successfully tried (with an Intel 82801IEM ICH9M-E) is normally in standby? Has anyone else ever encountered an SPI flash chip in Deep Power-Down mode?
I looked through the source code to see if flashrom sends or could send a Resume from Deep Power-Down command. The command is a 0xAB opcode while CS# is asserted, followed by a deassertion of CS# and a delay of up to 3 µs. flashrom doesn't send this command, but all of that seems easily doable except for the CS# deassertion. Linux's Documentation/spi/spidev file says that the SPI_IOC_MESSAGE(N) request does not deselect the chip.
flashrom DOES send 0xAB (RES) as it is one of the opcodes that can be used to identify flash chips (look for probe_spi_res1 in your log).
Any recommendations on how to proceed?
Unfortunately, I don't have another explanation other than that the board simply does not work with ISP. Have you tried measuring actual voltages on the board while flashrom is running or even using a logic analyzer?
-
Ondrej Zary -
Patrick 'P. J.' McDermott -
Stefan Tauner