Thanks to Johannes Sjölund for reporting that the Bus Pirate init could
not deal with a Bus Pirate which is already in binary Bitbang mode. This
is caused by a combination of the slowness of the Bus Pirate, the
slowness of USB and a fast serial port flush routine which just flushes
the buffer contents and does not wait until data arrival stops.
Make the Bus Pirate init more robust by running the flush command 10
times with 1.5 ms delay in between.
This code development was sponsored by …
[View More]Mattias Mattsson. Thanks!
Tested a few dozen times, should work reliably.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-buspirate_resilient_init/buspirate_spi.c
===================================================================
--- flashrom-buspirate_resilient_init/buspirate_spi.c (Revision 1099)
+++ flashrom-buspirate_resilient_init/buspirate_spi.c (Arbeitskopie)
@@ -22,6 +22,7 @@
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
+#include <unistd.h>
#include "flash.h"
#include "chipdrivers.h"
#include "spi.h"
@@ -140,6 +141,20 @@
/* Read any response and discard it. */
sp_flush_incoming();
}
+ /* USB is slow. The Bus Pirate is even slower. Apparently the flush
+ * action above is too fast or too early. Some stuff still remains in
+ * the pipe after the flush above, and one additional flush is not
+ * sufficient either. Use a 1.5 ms delay inside the loop to make
+ * mostly sure that at least one USB frame had time to arrive.
+ * Looping only 5 times is not sufficient and causes the
+ * ocassional failure.
+ * Folding the delay into the loop above is not reliable either.
+ */
+ for (i = 0; i < 10; i++) {
+ usleep(1500);
+ /* Read any response and discard it. */
+ sp_flush_incoming();
+ }
/* Enter raw bitbang mode */
buf[0] = 0x00;
ret = buspirate_sendrecv(buf, 1, 5);
@@ -147,6 +162,8 @@
return ret;
if (memcmp(buf, "BBIO", 4)) {
msg_perr("Entering raw bitbang mode failed!\n");
+ msg_pdbg("Got %02x%02x%02x%02x%02x\n",
+ buf[0], buf[1], buf[2], buf[3], buf[4]);
return 1;
}
msg_pdbg("Raw bitbang mode version %c\n", buf[4]);
@@ -158,8 +175,12 @@
/* Enter raw SPI mode */
buf[0] = 0x01;
ret = buspirate_sendrecv(buf, 1, 4);
+ if (ret)
+ return ret;
if (memcmp(buf, "SPI", 3)) {
msg_perr("Entering raw SPI mode failed!\n");
+ msg_pdbg("Got %02x%02x%02x%02x\n",
+ buf[0], buf[1], buf[2], buf[3]);
return 1;
}
msg_pdbg("Raw SPI mode version %c\n", buf[3]);
Index: flashrom-buspirate_resilient_init/serial.c
===================================================================
--- flashrom-buspirate_resilient_init/serial.c (Revision 1099)
+++ flashrom-buspirate_resilient_init/serial.c (Arbeitskopie)
@@ -199,8 +199,10 @@
#else
tmp = write(sp_fd, buf, writecnt);
#endif
- if (tmp == -1)
+ if (tmp == -1) {
+ msg_perr("Serial port write error!\n");
return 1;
+ }
if (!tmp)
msg_pdbg("Empty write\n");
writecnt -= tmp;
@@ -220,8 +222,10 @@
#else
tmp = read(sp_fd, buf, readcnt);
#endif
- if (tmp == -1)
+ if (tmp == -1) {
+ msg_perr("Serial port read error!\n");
return 1;
+ }
if (!tmp)
msg_pdbg("Empty read\n");
readcnt -= tmp;
--
http://www.hailfinger.org/
[View Less]
Author: hailfinger
Date: Fri Sep 17 00:34:25 2010
New Revision: 1178
URL: http://flashrom.org/trac/flashrom/changeset/1178
Log:
Thanks to Johannes Sjölund for reporting that the Bus Pirate init could
not deal with a Bus Pirate which is already in binary Bitbang mode. This
is caused by a combination of the slowness of the Bus Pirate, the
slowness of USB and a fast serial port flush routine which just flushes
the buffer contents and does not wait until data arrival stops.
Make the Bus Pirate …
[View More]init more robust by running the flush command 10
times with 1.5 ms delay in between.
This code development was sponsored by Mattias Mattsson. Thanks!
Tested a few dozen times, should work reliably.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Acked-by: Mattias Mattsson <vitplister(a)gmail.com>
Modified:
trunk/buspirate_spi.c
trunk/serial.c
Modified: trunk/buspirate_spi.c
==============================================================================
--- trunk/buspirate_spi.c Fri Sep 17 00:09:18 2010 (r1177)
+++ trunk/buspirate_spi.c Fri Sep 17 00:34:25 2010 (r1178)
@@ -22,6 +22,7 @@
#include <string.h>
#include <stdlib.h>
#include <ctype.h>
+#include <unistd.h>
#include "flash.h"
#include "chipdrivers.h"
#include "programmer.h"
@@ -141,6 +142,20 @@
/* Read any response and discard it. */
sp_flush_incoming();
}
+ /* USB is slow. The Bus Pirate is even slower. Apparently the flush
+ * action above is too fast or too early. Some stuff still remains in
+ * the pipe after the flush above, and one additional flush is not
+ * sufficient either. Use a 1.5 ms delay inside the loop to make
+ * mostly sure that at least one USB frame had time to arrive.
+ * Looping only 5 times is not sufficient and causes the
+ * ocassional failure.
+ * Folding the delay into the loop above is not reliable either.
+ */
+ for (i = 0; i < 10; i++) {
+ usleep(1500);
+ /* Read any response and discard it. */
+ sp_flush_incoming();
+ }
/* Enter raw bitbang mode */
buf[0] = 0x00;
ret = buspirate_sendrecv(buf, 1, 5);
@@ -148,6 +163,8 @@
return ret;
if (memcmp(buf, "BBIO", 4)) {
msg_perr("Entering raw bitbang mode failed!\n");
+ msg_pdbg("Got %02x%02x%02x%02x%02x\n",
+ buf[0], buf[1], buf[2], buf[3], buf[4]);
return 1;
}
msg_pdbg("Raw bitbang mode version %c\n", buf[4]);
@@ -159,8 +176,12 @@
/* Enter raw SPI mode */
buf[0] = 0x01;
ret = buspirate_sendrecv(buf, 1, 4);
+ if (ret)
+ return ret;
if (memcmp(buf, "SPI", 3)) {
msg_perr("Entering raw SPI mode failed!\n");
+ msg_pdbg("Got %02x%02x%02x%02x\n",
+ buf[0], buf[1], buf[2], buf[3]);
return 1;
}
msg_pdbg("Raw SPI mode version %c\n", buf[3]);
Modified: trunk/serial.c
==============================================================================
--- trunk/serial.c Fri Sep 17 00:09:18 2010 (r1177)
+++ trunk/serial.c Fri Sep 17 00:34:25 2010 (r1178)
@@ -200,8 +200,10 @@
#else
tmp = write(sp_fd, buf, writecnt);
#endif
- if (tmp == -1)
+ if (tmp == -1) {
+ msg_perr("Serial port write error!\n");
return 1;
+ }
if (!tmp)
msg_pdbg("Empty write\n");
writecnt -= tmp;
@@ -221,8 +223,10 @@
#else
tmp = read(sp_fd, buf, readcnt);
#endif
- if (tmp == -1)
+ if (tmp == -1) {
+ msg_perr("Serial port read error!\n");
return 1;
+ }
if (!tmp)
msg_pdbg("Empty read\n");
readcnt -= tmp;
[View Less]
I noticed that our patch queue is growing too fast to keep up, and it
will be almost impossible to merge all patches before 0.9.3 unless we're
willing to delay 0.9.3 for a few more months. Such a delay would also
mean that many distributions won't have a reasonably current flashrom
version.
If you have any patches that need to be reviewed/merged, please reply to
this mail with a link to the patch in patchwork:
http://patchwork.coreboot.org/project/flashrom/list/
Priority will be given to …
[View More]patches which fix bugs, mark stuff as tested,
or add new chips/boards. Speedup patches should get a chance as well,
especially if they are tested. Features like ITE EC support, Nuvoton EC
support, partial flashing and other fun stuff are better dealt with
after 0.9.3.
My hope is to tag flashrom 0.9.3 this week, and write release notes
early next week, then officially release it.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
[View Less]