[flashrom] Can't probe AT26DF321 on OptiPlex 755

[Patrick 'P. J.' McDermott]

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

-- 
Patrick "P. J." McDermott
  http://www.pehjota.net/
Lead Developer, ProteanOS
  http://www.proteanos.com/