Patchwork Dediprog SF100 support

login
register
about
Submitter Carl-Daniel Hailfinger
Date 2010-01-22 02:44:59
Message ID <4B59112B.1090700@gmx.net>
Download mbox | patch
Permalink /patch/829/
State Accepted
Commit r879
Headers show

Comments

Carl-Daniel Hailfinger - 2010-01-22 02:44:59
On 21.01.2010 21:50, Stefan Reinauer wrote:
> On 1/21/10 10:26 AM, Carl-Daniel Hailfinger wrote:
>   
>> Add write support.
>> Speed up reads by a factor of 64 by switching block size from 4 to 256.
>> Add support for 4 byte RDID.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
>>   
>>     
> Acked-by: Stefan Reinauer <stepan@coresystems.de>
>   

Thanks for the ack, I'll reuse it for the 16 byte variant. It seems that
while Patrick is getting no error messages for 256 byte transfers, they
explode for you. Since Patrick is also seeing corruption with large
transfers, I hope we can use your machine to test the real limits and
actually get error messages from the OS instead of corrupt data.


> MacPro:flashrom stepan$ time ./flashrom -pdediprog -r testread.rom
> flashrom v0.9.1-r878
> Found chip "ST M25P32" (4096 KB, SPI) at physical address 0xffc00000.
> Reading flash... Command Receive SPI failed, ret=-34, expected 256!
>   

Mh. Would be interesting to know when it explodes.


> done.
>
> real    0m31.602s
> user    0m0.924s
> sys    0m0.794s
>
> dd if=/dev/urandom of=testwrite.rom bs=1024 count=$((1024*4))
> time ./flashrom -pdediprog -w testwrite.rom
> flashrom v0.9.1-r878
> Found chip "ST M25P32" (4096 KB, SPI) at physical address 0xffc00000.
> Writing flash chip... Erasing flash before programming... Erasing flash
> chip... Command Receive SPI failed, ret=-34, expected 256!
>   

Yes, the point of failure would be very interesting to know.


> ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00, failed byte count
> from 0x00000000-0x0000ffff: 0x16ea
>   

Ah ok, there it is. So while Patrick was able to log 256 byte read
transfers from the dediprog app, either the method doesn't work in the
newer firmware (and I'd need a hand-crafted transfer log from your
machine to verify) or this is just an effect of Windows having an
inferior USB stack or libusb.


> ERASE FAILED!
> ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00,
> ^C
>
> real    1m17.836s
> user    0m1.948s
> sys    0m2.206s
>
>
>
>
> time ./flashrom -pdediprog -w testwrite.rom -VV
> flashrom v0.9.1-r878
> dediprog_init
> Found USB device (0483:dada).
> Found a SF100   V:3.1.8
> Setting SPI voltage to 3.500 V
> [...]
> Probing for ST M25P32, 4096 KB: dediprog_spi_send_command, writecnt=1,
> readcnt=3
> RDID returned 0x20 0x20 0x16. probe_spi_rdid_generic: id1 0x20, id2 0x2016
> dediprog_spi_send_command, writecnt=1, readcnt=2
> Chip status register is 00
> Chip status register: Status Register Write Disable (SRWD) is not set
> Chip status register: Bit 6 is not set
> Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
> Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
> Chip status register: Bit 3 / Block Protect 1 (BP1) is not set
> Chip status register: Bit 2 / Block Protect 0 (BP0) is not set
> Chip status register: Write Enable Latch (WEL) is not set
> Chip status register: Write In Progress (WIP/BUSY) is not set
> Found chip "ST M25P32" (4096 KB, SPI) at physical address 0xffc00000.
> [...]
> Writing flash chip... dediprog_spi_send_command, writecnt=1, readcnt=2
> Erasing flash before programming... Erasing flash chip... Looking at
> blockwise erase function 0... trying... 0x000000-0x00ffff,
> dediprog_spi_send_command, writecnt=1, readcnt=0
> dediprog_spi_send_command, writecnt=4, readcnt=0
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_read, start=0x0, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> Command Receive SPI failed, ret=-34, expected 256!
>   

Perfect, thanks for the detailed log. Indeed, the very first large read
fails.


> ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00,dediprog_spi_read,
> start=0x100, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x200, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x300, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x400, len=0x100
> [...]
> dediprog_spi_read, start=0xff00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
>   

Very interesting. It seems this read doesn't get any error message but
still fails.


>  failed byte count from 0x00000000-0x0000ffff: 0x16ea
> ERASE FAILED!
>
> Looking at blockwise erase function 1... trying... 0x000000-0x3fffff,
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_send_command, writecnt=1, readcnt=0
> dediprog_spi_send_command, writecnt=1, readcnt=0
> dediprog_spi_send_command, writecnt=1, readcnt=2
> dediprog_spi_read, start=0x0, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
>   

Same here. Silent failure.


> ERASE FAILED at 0x00000000! Expected=0xff, Read=0x00,dediprog_spi_read,
> start=0x100, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x200, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x300, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x400, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x500, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x600, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x700, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x800, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x900, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xa00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xb00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xc00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xd00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xe00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0xf00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1000, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1100, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1200, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1300, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1400, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x1500, len=0x100
> [...]
> dediprog_spi_read, start=0x3ff900, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3ffa00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3ffb00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3ffc00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3ffd00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3ffe00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
> dediprog_spi_read, start=0x3fff00, len=0x100
> dediprog_spi_send_command, writecnt=4, readcnt=256
>  failed byte count from 0x00000000-0x003fffff: 0x58000
> ERASE FAILED!
>
> Looking at blockwise erase function 2... not defined. Looking for
> another erase function.
> Looking at blockwise erase function 3... not defined. Looking for
> another erase function.
> Looking at blockwise erase function 4... not defined. Looking for
> another erase function.
> FAILED!
> ERASE FAILED!
> FAILED!
> dediprog_shutdown
> Setting SPI voltage to 0.000 V
>
> real    1m58.392s
> user    0m2.733s
> sys    0m4.135s
>   

Thanks a lot for the log.
New patch.

Add write support.
Speed up reads by a factor of 4 by switching block size from 4 to 16.
Add support for 4 byte RDID.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Carl-Daniel Hailfinger - 2010-01-22 02:53:45
On 22.01.2010 03:44, Carl-Daniel Hailfinger wrote:
> On 21.01.2010 21:50, Stefan Reinauer wrote:
>   
>> On 1/21/10 10:26 AM, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> Add write support.
>>> Speed up reads by a factor of 64 by switching block size from 4 to 256.
>>> Add support for 4 byte RDID.
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
>>>
>>>       
>> Acked-by: Stefan Reinauer <stepan@coresystems.de>  
>>     
>
> Thanks for the ack, I'll reuse it for the 16 byte variant. It seems that
> while Patrick is getting no error messages for 256 byte transfers, they
> explode for you. Since Patrick is also seeing corruption with large
> transfers, I hope we can use your machine to test the real limits and
> actually get error messages from the OS instead of corrupt data.
> [...]
>
> Add write support.
> Speed up reads by a factor of 4 by switching block size from 4 to 16.
> Add support for 4 byte RDID.
>   

Add USB error decoding via usb_strerror as well.

> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
>   

Thanks for testing. As stated above I'm reusing your ack.

Acked-by: Stefan Reinauer <stepan@coresystems.de>  

and committed in r879.

Regards,
Carl-Daniel
Carl-Daniel Hailfinger - 2010-01-22 03:19:16
On 22.01.2010 03:53, Carl-Daniel Hailfinger wrote:
> On 22.01.2010 03:44, Carl-Daniel Hailfinger wrote:
>   
>> Add write support.
>> Speed up reads by a factor of 4 by switching block size from 4 to 16.
>> Add support for 4 byte RDID.
>>     
>
> Add USB error decoding via usb_strerror as well.
>   
> and committed in r879.
>   

Just FYI. What's currently in the tree may be slow, but it should work
reliably for reads and writes, and be 4x faster than the old code. I
expect 5-10 minutes for read and erase (because erase does a read to
verify), and too long (40 minutes, maybe more, maybe less) for write.
Write hasn't seen any optimization yet.

 >16 byte non-opaque transfers still have to be figured out on the new
SF100 software/firmware. Does the new software/firmware have any size
limitations for user-defined command streams? If not, a USB log of
sending "03 00 00 00" and receiving 32 bytes, and a log of the same
sequence receiving 64 bytes, both with the new firmware, would be very
helpful.

Regards,
Carl-Daniel

Patch

Index: flashrom-dediprog_bigchunks/spi.c
===================================================================
--- flashrom-dediprog_bigchunks/spi.c	(Revision 877)
+++ flashrom-dediprog_bigchunks/spi.c	(Arbeitskopie)
@@ -335,6 +335,9 @@ 
 #if BUSPIRATE_SPI_SUPPORT == 1
 	case SPI_CONTROLLER_BUSPIRATE:
 #endif
+#if DEDIPROG_SUPPORT == 1
+	case SPI_CONTROLLER_DEDIPROG:
+#endif
 		return probe_spi_rdid_generic(flash, 4);
 	default:
 		printf_debug("4b ID not supported on this SPI controller\n");
Index: flashrom-dediprog_bigchunks/dediprog.c
===================================================================
--- flashrom-dediprog_bigchunks/dediprog.c	(Revision 877)
+++ flashrom-dediprog_bigchunks/dediprog.c	(Arbeitskopie)
@@ -145,8 +145,9 @@ 
 
 int dediprog_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len)
 {
-	/* Maximum read length is 4 bytes for now. */
-	return spi_read_chunked(flash, buf, start, len, 4);
+	msg_pspew("%s, start=0x%x, len=0x%x\n", __func__, start, len);
+	/* Chosen read length is 16 bytes for now. */
+	return spi_read_chunked(flash, buf, start, len, 16);
 }
 
 int dediprog_spi_send_command(unsigned int writecnt, unsigned int readcnt,
@@ -154,19 +155,22 @@ 
 {
 	int ret;
 
+	msg_pspew("%s, writecnt=%i, readcnt=%i\n", __func__, writecnt, readcnt);
 	/* Paranoid, but I don't want to be blamed if anything explodes. */
-	if ((writecnt != 1) && (writecnt != 4))
+	if (writecnt > 5) {
 		msg_perr("Untested writecnt=%i, aborting.\n", writecnt);
-	if (readcnt > 4)
+		return 1;
+	}
+	/* 16 byte reads should work. */
+	if (readcnt > 16) {
 		msg_perr("Untested readcnt=%i, aborting.\n", readcnt);
-	if ((readcnt == 0) && (writecnt != 1))
-		msg_perr("Untested writecnt=%i, readcnt=%i combination, "
-			 "aborting.\n", writecnt, readcnt);
+		return 1;
+	}
 	
 	ret = usb_control_msg(dediprog_handle, 0x42, 0x1, 0xff, readcnt ? 0x1 : 0x0, (char *)writearr, writecnt, DEFAULT_TIMEOUT);
 	if (ret != writecnt) {
-		msg_perr("Command Send SPI failed, ret=%i, expected %i!\n",
-			 ret, writecnt);
+		msg_perr("Send SPI failed, expected %i, got %i %s!\n",
+			 writecnt, ret, usb_strerror());
 		return 1;
 	}
 	if (!readcnt)
@@ -174,8 +178,8 @@ 
 	memset(readarr, 0, readcnt);
 	ret = usb_control_msg(dediprog_handle, 0xc2, 0x01, 0xbb8, 0x0000, (char *)readarr, readcnt, DEFAULT_TIMEOUT);
 	if (ret != readcnt) {
-		msg_perr("Command Receive SPI failed, ret=%i, expected %i!\n",
-			 ret, readcnt);
+		msg_perr("Receive SPI failed, expected %i, got %i %s!\n",
+			 readcnt, ret, usb_strerror());
 		return 1;
 	}
 	return 0;