On 2015-08-11 22:13, Patrick 'P. J.' McDermott wrote:
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
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  (the AT25 datasheet  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?
Patrick "P. J." McDermott
Lead Developer, ProteanOS