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 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;
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 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/
This patch changes the prefix of chip constant #defines in the following way:
AM_nnnnnnn -> AMD_AMnnnnnnn
AT_nnnnnnn -> ATMEL_ATnnnnnnn
EN_nnnnnnn -> EON_ENnnnnnnn
MBMnnnnnnn -> FUJITSU_MBMnnnnnnn
MX_ID -> MACRONIX_ID
MX_nnnnnnn -> MACRONIX_MXnnnnnnn
PMC_nnnnnnn -> PMC_PMnnnnnnn
SST_nnnnnnn -> SST_SSTnnnnnnn
It leaves the Intel #defines alone because there is another pending
patch for that:
http://patchwork.coreboot.org/patch/1937/
Some background discussion here:
http://www.flashrom.org/pipermail/flashrom/2010-July/004059.html
Signed-off-by: Mattias Mattsson <vitplister(a)gmail.com>
Am Mittwoch, den 15.09.2010, 20:14 +0200 schrieb STEMMELIN, FREDERIC
(FREDERIC)** CTR **:
> NOT WORKING is writing from original Tyan BIOS image (Error: Image
> size doesn't match, 2895V106.wph,
> ftp://ftp.tyan.com/bios/S2895_v106.zip)
This is normal for phoenix images (flashed by winphlash or phlash16),
because these images have code containing board and chip specific update
functions appended to the flash image. Taking only the first 1048576
bytes of that file using e.g. head or dd is known to generally work on
phoenix BIOSes
Regards,
Michael Karcher