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