summaryrefslogtreecommitdiffstats
path: root/sb600spi.c
diff options
context:
space:
mode:
authorCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2009-07-23 01:36:08 +0000
committerCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>2009-07-23 01:36:08 +0000
commitf8555e24a456551de9ce3d89fc648db9034ef517 (patch)
treeb2ed02345452c285f0138e2a2777e1dab46ba617 /sb600spi.c
parent414bd320ac1346db9539625975644bfa7b30281e (diff)
downloadast2050-flashrom-f8555e24a456551de9ce3d89fc648db9034ef517.zip
ast2050-flashrom-f8555e24a456551de9ce3d89fc648db9034ef517.tar.gz
This is a workaround for a bug in SB600 and SB700
If we only send an opcode and no additional data/address, the SPI controller will read one byte too few from the chip. Basically, the last byte of the chip response is discarded and will not end up in the FIFO. It is unclear if the CS# line is set high too early as well. That hardware bug is undocumented as of now, but I'm working with AMD to add a detailed description of it to the errata. Add loads of additional debugging to SB600/SB700 init. Add explanatory comments for unintuitive code flow. Thanks go to Uwe for testing quite a few iterations of the patch. Kill the SB600 flash chip status register special case, which was a somewhat misguided workaround for that hardware erratum. Note for future added features in the SB600 SPI driver: It may be possible to read up to 15 bytes of command response with overlapping reads due to the ring buffer design of the FIFO if the command can be repeated without ill effects. Same for skipping up to 7 bytes between command and response. Corresponding to flashrom svn r661. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> Acked-by: Stefan Reinauer <stepan@coresystems.de>
Diffstat (limited to 'sb600spi.c')
-rw-r--r--sb600spi.c38
1 files changed, 22 insertions, 16 deletions
diff --git a/sb600spi.c b/sb600spi.c
index 865a8c3..2088b08 100644
--- a/sb600spi.c
+++ b/sb600spi.c
@@ -38,7 +38,7 @@
*};
*/
-uint8_t *sb600_spibar;
+uint8_t *sb600_spibar = NULL;
int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len)
{
@@ -46,16 +46,6 @@ int sb600_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len)
return spi_read_chunked(flash, buf, start, len, 8);
}
-uint8_t sb600_read_status_register(void)
-{
- const unsigned char cmd[0x02] = { JEDEC_RDSR, 0x00 };
- unsigned char readarr[JEDEC_RDSR_INSIZE];
-
- /* Read Status Register */
- spi_send_command(sizeof(cmd), sizeof(readarr), cmd, readarr);
- return readarr[0];
-}
-
int sb600_spi_write_1(struct flashchip *flash, uint8_t *buf)
{
int rc = 0, i;
@@ -106,6 +96,7 @@ int sb600_spi_send_command(unsigned int writecnt, unsigned int readcnt,
int count;
/* First byte is cmd which can not being sent through FIFO. */
unsigned char cmd = *writearr++;
+ unsigned int readoffby1;
writecnt--;
@@ -124,8 +115,15 @@ int sb600_spi_send_command(unsigned int writecnt, unsigned int readcnt,
return SPI_INVALID_LENGTH;
}
+ /* This is a workaround for a bug in SB600 and SB700. If we only send
+ * an opcode and no additional data/address, the SPI controller will
+ * read one byte too few from the chip. Basically, the last byte of
+ * the chip response is discarded and will not end up in the FIFO.
+ * It is unclear if the CS# line is set high too early as well.
+ */
+ readoffby1 = (writecnt) ? 0 : 1;
+ mmio_writeb((readcnt + readoffby1) << 4 | (writecnt), sb600_spibar + 1);
mmio_writeb(cmd, sb600_spibar + 0);
- mmio_writeb(readcnt << 4 | (writecnt), sb600_spibar + 1);
/* Before we use the FIFO, reset it first. */
reset_internal_fifo_pointer();
@@ -147,17 +145,25 @@ int sb600_spi_send_command(unsigned int writecnt, unsigned int readcnt,
/*
* After the command executed, we should find out the index of the
- * received byte. Here we just reset the FIFO pointer, skip the
- * writecnt, is there anyone who have anther method to replace it?
+ * received byte. Here we just reset the FIFO pointer and skip the
+ * writecnt.
+ * It would be possible to increase the FIFO pointer by one instead
+ * of reading and discarding one byte from the FIFO.
+ * The FIFO is implemented on top of an 8 byte ring buffer and the
+ * buffer is never cleared. For every byte that is shifted out after
+ * the opcode, the FIFO already stores the response from the chip.
+ * Usually, the chip will respond with 0x00 or 0xff.
*/
reset_internal_fifo_pointer();
+ /* Skip the bytes we sent. */
for (count = 0; count < writecnt; count++) {
- cmd = mmio_readb(sb600_spibar + 0xC); /* Skip the byte we send. */
+ cmd = mmio_readb(sb600_spibar + 0xC);
printf_debug("[ %2x]", cmd);
}
- printf_debug("The FIFO pointer 6 is %d.\n", mmio_readb(sb600_spibar + 0xd) & 0x07);
+ printf_debug("The FIFO pointer after skipping is %d.\n",
+ mmio_readb(sb600_spibar + 0xd) & 0x07);
for (count = 0; count < readcnt; count++, readarr++) {
*readarr = mmio_readb(sb600_spibar + 0xC);
printf_debug("[%02x]", *readarr);
OpenPOWER on IntegriCloud