flashrom

flashrom@flashrom.org

3 participants
9188 discussions

[PATCH] Bus Pirate init cleanup and fixes
by Carl-Daniel Hailfinger 17 Aug '12

17 Aug '12

The Bus Pirate firmware (at least v6.1 and earlier) can't handle UART input buffer overflow in BBIO mode, and sending a sequence of 0x00 too fast apparently triggers such an UART input buffer overflow. Wait 10 ms after sending each 0x00 byte during init to give the Bus Pirate enough time to handle the input. This fixes a Bus Pirate hang if the previous flashrom run was aborted by the user. The Bus Pirate firmware v6.1 and earlier use the wrong (too slow) SPI speed if more than 2 MHz are requested. Automatically downgrade SPI speed to 2 MHz for affected firmware versions. Detect Bus Pirate hardware and firmware versions to allow quirk handling. The Bus Pirate init sequence has lots of open-coded sequences which wait for a given string on the serial line. Refactor them into buspirate_wait_for_string(). User-visible changes: Fix hang, use 2 MHz SPI speed on buggy firmware. Note: This patch does _not_ include support for the fast access mode present in firmware 5.5 and later. Tested with Bus Pirate hardware v3a and v3b, firmwares 4.0, 5.2 and 6.2-beta. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-buspirate_initcleanup/buspirate_spi.c =================================================================== --- flashrom-buspirate_initcleanup/buspirate_spi.c (Revision 1546) +++ flashrom-buspirate_initcleanup/buspirate_spi.c (Arbeitskopie) @@ -83,7 +83,8 @@ msg_perr("Zero length command!\n"); return 1; } - msg_pspew("Sending"); + if (writecnt) + msg_pspew("Sending"); for (i = 0; i < writecnt; i++) msg_pspew(" 0x%02x", buf[i]); #ifdef FAKE_COMMUNICATION @@ -103,19 +104,32 @@ if (ret) return ret; #endif - msg_pspew(", receiving"); + if (readcnt) + msg_pspew(", receiving"); for (i = 0; i < readcnt; i++) msg_pspew(" 0x%02x", buf[i]); msg_pspew("\n"); return 0; } -static int buspirate_spi_send_command(struct flashctx *flash, - unsigned int writecnt, - unsigned int readcnt, - const unsigned char *writearr, - unsigned char *readarr); +static int buspirate_wait_for_string(unsigned char *buf, char *key) +{ + unsigned int keylen = strlen(key); + int ret; + ret = buspirate_sendrecv(buf, 0, keylen); + while (!ret) { + if (!memcmp(buf, key, keylen)) + return 0; + memmove(buf, buf + 1, keylen - 1); + ret = buspirate_sendrecv(buf + keylen - 1, 0, 1); + } + return ret; +} + +static int buspirate_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned int readcnt, + const unsigned char *writearr, unsigned char *readarr); + static const struct spi_programmer spi_programmer_buspirate = { .type = SPI_CONTROLLER_BUSPIRATE, .max_data_read = 12, @@ -146,17 +160,15 @@ /* Exit raw SPI mode (enter raw bitbang mode) */ bp_commbuf[0] = 0x00; - ret = buspirate_sendrecv(bp_commbuf, 1, 5); - if (ret) + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) goto out_shutdown; - if (memcmp(bp_commbuf, "BBIO", 4)) { - msg_perr("Entering raw bitbang mode failed!\n"); - ret = 1; + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) goto out_shutdown; - } - msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[4]); - if (bp_commbuf[4] != '1') { - msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[4]); + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + goto out_shutdown; + msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[0]); ret = 1; goto out_shutdown; } @@ -181,18 +193,26 @@ return ret; } +#define BP_FWVERSION(a,b) ((a) << 8 | (b)) + int buspirate_spi_init(void) { char *dev = NULL; char *speed = NULL; + char *tmp; + unsigned int fw_version_major = 0; + unsigned int fw_version_minor = 0; int spispeed = 0x7; int ret = 0; int i; dev = extract_programmer_param("dev"); - if (!dev || !strlen(dev)) { - msg_perr("No serial device given. Use flashrom -p " - "buspirate_spi:dev=/dev/ttyUSB0\n"); + if (dev && !strlen(dev)) { + free(dev); + dev = NULL; + } + if (!dev) { + msg_perr("No serial device given. Use flashrom -p buspirate_spi:dev=/dev/ttyUSB0\n"); return 1; } @@ -209,9 +229,6 @@ } free(speed); - /* This works because speeds numbering starts at 0 and is contiguous. */ - msg_pdbg("SPI speed is %sHz\n", spispeeds[spispeed].name); - /* Default buffer size is 19: 16 bytes data, 3 bytes control. */ #define DEFAULT_BUFSIZE (16 + 3) bp_commbuf = malloc(DEFAULT_BUFSIZE); @@ -235,66 +252,118 @@ return 1; /* This is the brute force version, but it should work. */ - for (i = 0; i < 19; i++) { + for (i = 0; i < 20; i++) { /* Enter raw bitbang mode */ bp_commbuf[0] = 0x00; /* Send the command, don't read the response. */ ret = buspirate_sendrecv(bp_commbuf, 1, 0); if (ret) return ret; - /* Read any response and discard it. */ - sp_flush_incoming(); + /* The old way to handle responses from a Bus Pirate already in BBIO mode was to flush any + * response which came in over serial. Unfortunately that does not work reliably on Linux + * with FTDI USB-serial. + */ + //sp_flush_incoming(); + /* The Bus Pirate can't handle UART input buffer overflow in BBIO mode, and sending a sequence + * of 0x00 too fast apparently triggers such an UART input buffer overflow. + */ + usleep(10000); } - /* 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 - * occasional 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(); + /* We know that 20 commands of \0 should elicit at least one BBIO1 response. */ + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) + return ret; + + /* Reset the Bus Pirate. */ + bp_commbuf[0] = 0x0f; + /* Send the command, don't read the response. */ + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + return ret; + if ((ret = buspirate_wait_for_string(bp_commbuf, "irate "))) + return ret; + /* Read the hardware version string. Last byte of the buffer is reserved for \0. */ + for (i = 0; i < DEFAULT_BUFSIZE - 1; i++) { + if ((ret = buspirate_sendrecv(bp_commbuf + i, 0, 1))) + return ret; + if (strchr("\r\n\t ", bp_commbuf[i])) + break; } + bp_commbuf[i] = '\0'; + msg_pdbg("Detected Bus Pirate hardware %s\n", bp_commbuf); + + if ((ret = buspirate_wait_for_string(bp_commbuf, "irmware "))) + return ret; + /* Read the firmware version string. Last byte of the buffer is reserved for \0. */ + for (i = 0; i < DEFAULT_BUFSIZE - 1; i++) { + if ((ret = buspirate_sendrecv(bp_commbuf + i, 0, 1))) + return ret; + if (strchr("\r\n\t ", bp_commbuf[i])) + break; + } + bp_commbuf[i] = '\0'; + msg_pdbg("Detected Bus Pirate firmware "); + if (bp_commbuf[0] != 'v') + msg_pdbg("(unknown version number format)\n"); + else if (!strchr("0123456789", bp_commbuf[1])) + msg_pdbg("(unknown version number format)"); + else { + fw_version_major = strtoul((char *)bp_commbuf + 1, &tmp, 10); + while ((*tmp != '\0') && !strchr("0123456789", *tmp)) + tmp++; + fw_version_minor = strtoul(tmp, NULL, 10); + msg_pdbg("%u.%u", fw_version_major, fw_version_minor); + } + msg_pdbg2(" (\"%s\")", bp_commbuf); + msg_pdbg("\n"); + + if ((ret = buspirate_wait_for_string(bp_commbuf, "HiZ>"))) + return ret; + + /* Workaround for broken speed settings in firmware 6.1 and older. */ + if (BP_FWVERSION(fw_version_major, fw_version_minor) < BP_FWVERSION(6, 2)) + if (spispeed > 0x4) { + msg_perr("Bus Pirate firmware 6.1 and older does not support SPI speeds above 2 MHz. " + "Limiting speed to 2 MHz.\n"); + msg_pinfo("It is recommended to upgrade to firmware 6.2 or newer.\n"); + spispeed = 0x4; + } + + /* Tell the user about missing SPI binary mode in firmware 2.3 and older. */ + if (BP_FWVERSION(fw_version_major, fw_version_minor) < BP_FWVERSION(2, 4)) { + msg_pinfo("Bus Pirate firmware 2.3 and older does not support binary SPI access.\n"); + msg_pinfo("Please upgrade to the latest firmware (at least 2.4).\n"); + return SPI_PROGRAMMER_ERROR; + } + + /* This works because speeds numbering starts at 0 and is contiguous. */ + msg_pdbg("SPI speed is %sHz\n", spispeeds[spispeed].name); + /* Enter raw bitbang mode */ - bp_commbuf[0] = 0x00; - ret = buspirate_sendrecv(bp_commbuf, 1, 5); - if (ret) + for (i = 0; i < 20; i++) { + bp_commbuf[0] = 0x00; + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + return ret; + } + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) return ret; - if (memcmp(bp_commbuf, "BBIO", 4)) { - msg_perr("Entering raw bitbang mode failed!\n"); - msg_pdbg("Got %02x%02x%02x%02x%02x\n", - bp_commbuf[0], bp_commbuf[1], bp_commbuf[2], - bp_commbuf[3], bp_commbuf[4]); + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + return ret; + msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[0]); return 1; } - msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[4]); - if (bp_commbuf[4] != '1') { - msg_perr("Can't handle raw bitbang mode version %c!\n", - bp_commbuf[4]); - return 1; - } /* Enter raw SPI mode */ bp_commbuf[0] = 0x01; - ret = buspirate_sendrecv(bp_commbuf, 1, 4); - if (ret) + ret = buspirate_sendrecv(bp_commbuf, 1, 0); + if ((ret = buspirate_wait_for_string(bp_commbuf, "SPI"))) return ret; - if (memcmp(bp_commbuf, "SPI", 3)) { - msg_perr("Entering raw SPI mode failed!\n"); - msg_pdbg("Got %02x%02x%02x%02x\n", - bp_commbuf[0], bp_commbuf[1], bp_commbuf[2], - bp_commbuf[3]); + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + return ret; + msg_pdbg("Raw SPI mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw SPI mode version %c!\n", bp_commbuf[0]); return 1; } - msg_pdbg("Raw SPI mode version %c\n", bp_commbuf[3]); - if (bp_commbuf[3] != '1') { - msg_perr("Can't handle raw SPI mode version %c!\n", - bp_commbuf[3]); - return 1; - } /* Initial setup (SPI peripherals config): Enable power, CS high, AUX */ bp_commbuf[0] = 0x40 | 0xb; -- http://www.hailfinger.org/

1 2

[commit] r1576 - trunk
by repository service 17 Aug '12

17 Aug '12

Author: hailfinger Date: Fri Aug 17 19:30:43 2012 New Revision: 1576 URL: http://flashrom.org/trac/flashrom/changeset/1576 Log: Bus Pirate init cleanup and fixes. The Bus Pirate firmware (at least v6.1 and earlier) can't handle UART input buffer overflow in BBIO mode, and sending a sequence of 0x00 too fast apparently triggers such an UART input buffer overflow. Wait 10 ms after sending each 0x00 byte during init to give the Bus Pirate enough time to handle the input. This fixes a Bus Pirate hang if the previous flashrom run was aborted by the user. The Bus Pirate firmware v6.1 and earlier use the wrong (too slow) SPI speed if more than 2 MHz are requested. Automatically downgrade SPI speed to 2 MHz for affected firmware versions. Detect Bus Pirate hardware and firmware versions to allow quirk handling. The Bus Pirate init sequence has lots of open-coded sequences which wait for a given string on the serial line. Refactor them into buspirate_wait_for_string(). Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/buspirate_spi.c Modified: trunk/buspirate_spi.c ============================================================================== --- trunk/buspirate_spi.c Thu Aug 16 01:06:32 2012 (r1575) +++ trunk/buspirate_spi.c Fri Aug 17 19:30:43 2012 (r1576) @@ -84,7 +84,8 @@ msg_perr("Zero length command!\n"); return 1; } - msg_pspew("Sending"); + if (writecnt) + msg_pspew("Sending"); for (i = 0; i < writecnt; i++) msg_pspew(" 0x%02x", buf[i]); #ifdef FAKE_COMMUNICATION @@ -104,18 +105,31 @@ if (ret) return ret; #endif - msg_pspew(", receiving"); + if (readcnt) + msg_pspew(", receiving"); for (i = 0; i < readcnt; i++) msg_pspew(" 0x%02x", buf[i]); msg_pspew("\n"); return 0; } -static int buspirate_spi_send_command(struct flashctx *flash, - unsigned int writecnt, - unsigned int readcnt, - const unsigned char *writearr, - unsigned char *readarr); +static int buspirate_wait_for_string(unsigned char *buf, char *key) +{ + unsigned int keylen = strlen(key); + int ret; + + ret = buspirate_sendrecv(buf, 0, keylen); + while (!ret) { + if (!memcmp(buf, key, keylen)) + return 0; + memmove(buf, buf + 1, keylen - 1); + ret = buspirate_sendrecv(buf + keylen - 1, 0, 1); + } + return ret; +} + +static int buspirate_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned int readcnt, + const unsigned char *writearr, unsigned char *readarr); static const struct spi_programmer spi_programmer_buspirate = { .type = SPI_CONTROLLER_BUSPIRATE, @@ -147,17 +161,15 @@ /* Exit raw SPI mode (enter raw bitbang mode) */ bp_commbuf[0] = 0x00; - ret = buspirate_sendrecv(bp_commbuf, 1, 5); - if (ret) + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) goto out_shutdown; - if (memcmp(bp_commbuf, "BBIO", 4)) { - msg_perr("Entering raw bitbang mode failed!\n"); - ret = 1; + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) goto out_shutdown; - } - msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[4]); - if (bp_commbuf[4] != '1') { - msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[4]); + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + goto out_shutdown; + msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[0]); ret = 1; goto out_shutdown; } @@ -182,18 +194,26 @@ return ret; } +#define BP_FWVERSION(a,b) ((a) << 8 | (b)) + int buspirate_spi_init(void) { char *dev = NULL; char *speed = NULL; + char *tmp; + unsigned int fw_version_major = 0; + unsigned int fw_version_minor = 0; int spispeed = 0x7; int ret = 0; int i; dev = extract_programmer_param("dev"); - if (!dev || !strlen(dev)) { - msg_perr("No serial device given. Use flashrom -p " - "buspirate_spi:dev=/dev/ttyUSB0\n"); + if (dev && !strlen(dev)) { + free(dev); + dev = NULL; + } + if (!dev) { + msg_perr("No serial device given. Use flashrom -p buspirate_spi:dev=/dev/ttyUSB0\n"); return 1; } @@ -210,9 +230,6 @@ } free(speed); - /* This works because speeds numbering starts at 0 and is contiguous. */ - msg_pdbg("SPI speed is %sHz\n", spispeeds[spispeed].name); - /* Default buffer size is 19: 16 bytes data, 3 bytes control. */ #define DEFAULT_BUFSIZE (16 + 3) bp_commbuf = malloc(DEFAULT_BUFSIZE); @@ -236,64 +253,116 @@ return 1; /* This is the brute force version, but it should work. */ - for (i = 0; i < 19; i++) { + for (i = 0; i < 20; i++) { /* Enter raw bitbang mode */ bp_commbuf[0] = 0x00; /* Send the command, don't read the response. */ ret = buspirate_sendrecv(bp_commbuf, 1, 0); if (ret) return ret; - /* Read any response and discard it. */ - sp_flush_incoming(); + /* The old way to handle responses from a Bus Pirate already in BBIO mode was to flush any + * response which came in over serial. Unfortunately that does not work reliably on Linux + * with FTDI USB-serial. + */ + //sp_flush_incoming(); + /* The Bus Pirate can't handle UART input buffer overflow in BBIO mode, and sending a sequence + * of 0x00 too fast apparently triggers such an UART input buffer overflow. + */ + usleep(10000); + } + /* We know that 20 commands of \0 should elicit at least one BBIO1 response. */ + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) + return ret; + + /* Reset the Bus Pirate. */ + bp_commbuf[0] = 0x0f; + /* Send the command, don't read the response. */ + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + return ret; + if ((ret = buspirate_wait_for_string(bp_commbuf, "irate "))) + return ret; + /* Read the hardware version string. Last byte of the buffer is reserved for \0. */ + for (i = 0; i < DEFAULT_BUFSIZE - 1; i++) { + if ((ret = buspirate_sendrecv(bp_commbuf + i, 0, 1))) + return ret; + if (strchr("\r\n\t ", bp_commbuf[i])) + break; } - /* 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 - * occasional 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(); + bp_commbuf[i] = '\0'; + msg_pdbg("Detected Bus Pirate hardware %s\n", bp_commbuf); + + if ((ret = buspirate_wait_for_string(bp_commbuf, "irmware "))) + return ret; + /* Read the firmware version string. Last byte of the buffer is reserved for \0. */ + for (i = 0; i < DEFAULT_BUFSIZE - 1; i++) { + if ((ret = buspirate_sendrecv(bp_commbuf + i, 0, 1))) + return ret; + if (strchr("\r\n\t ", bp_commbuf[i])) + break; } - /* Enter raw bitbang mode */ - bp_commbuf[0] = 0x00; - ret = buspirate_sendrecv(bp_commbuf, 1, 5); - if (ret) + bp_commbuf[i] = '\0'; + msg_pdbg("Detected Bus Pirate firmware "); + if (bp_commbuf[0] != 'v') + msg_pdbg("(unknown version number format)"); + else if (!strchr("0123456789", bp_commbuf[1])) + msg_pdbg("(unknown version number format)"); + else { + fw_version_major = strtoul((char *)bp_commbuf + 1, &tmp, 10); + while ((*tmp != '\0') && !strchr("0123456789", *tmp)) + tmp++; + fw_version_minor = strtoul(tmp, NULL, 10); + msg_pdbg("%u.%u", fw_version_major, fw_version_minor); + } + msg_pdbg2(" (\"%s\")", bp_commbuf); + msg_pdbg("\n"); + + if ((ret = buspirate_wait_for_string(bp_commbuf, "HiZ>"))) return ret; - if (memcmp(bp_commbuf, "BBIO", 4)) { - msg_perr("Entering raw bitbang mode failed!\n"); - msg_pdbg("Got %02x%02x%02x%02x%02x\n", - bp_commbuf[0], bp_commbuf[1], bp_commbuf[2], - bp_commbuf[3], bp_commbuf[4]); - return 1; + + /* Tell the user about missing SPI binary mode in firmware 2.3 and older. */ + if (BP_FWVERSION(fw_version_major, fw_version_minor) < BP_FWVERSION(2, 4)) { + msg_pinfo("Bus Pirate firmware 2.3 and older does not support binary SPI access.\n"); + msg_pinfo("Please upgrade to the latest firmware (at least 2.4).\n"); + return SPI_PROGRAMMER_ERROR; + } + + /* Workaround for broken speed settings in firmware 6.1 and older. */ + if (BP_FWVERSION(fw_version_major, fw_version_minor) < BP_FWVERSION(6, 2)) + if (spispeed > 0x4) { + msg_perr("Bus Pirate firmware 6.1 and older does not support SPI speeds above 2 MHz. " + "Limiting speed to 2 MHz.\n"); + msg_pinfo("It is recommended to upgrade to firmware 6.2 or newer.\n"); + spispeed = 0x4; + } + + /* This works because speeds numbering starts at 0 and is contiguous. */ + msg_pdbg("SPI speed is %sHz\n", spispeeds[spispeed].name); + + /* Enter raw bitbang mode */ + for (i = 0; i < 20; i++) { + bp_commbuf[0] = 0x00; + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + return ret; } - msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[4]); - if (bp_commbuf[4] != '1') { - msg_perr("Can't handle raw bitbang mode version %c!\n", - bp_commbuf[4]); + if ((ret = buspirate_wait_for_string(bp_commbuf, "BBIO"))) + return ret; + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + return ret; + msg_pdbg("Raw bitbang mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw bitbang mode version %c!\n", bp_commbuf[0]); return 1; } /* Enter raw SPI mode */ bp_commbuf[0] = 0x01; - ret = buspirate_sendrecv(bp_commbuf, 1, 4); - if (ret) + ret = buspirate_sendrecv(bp_commbuf, 1, 0); + if ((ret = buspirate_wait_for_string(bp_commbuf, "SPI"))) return ret; - if (memcmp(bp_commbuf, "SPI", 3)) { - msg_perr("Entering raw SPI mode failed!\n"); - msg_pdbg("Got %02x%02x%02x%02x\n", - bp_commbuf[0], bp_commbuf[1], bp_commbuf[2], - bp_commbuf[3]); - return 1; - } - msg_pdbg("Raw SPI mode version %c\n", bp_commbuf[3]); - if (bp_commbuf[3] != '1') { - msg_perr("Can't handle raw SPI mode version %c!\n", - bp_commbuf[3]); + if ((ret = buspirate_sendrecv(bp_commbuf, 0, 1))) + return ret; + msg_pdbg("Raw SPI mode version %c\n", bp_commbuf[0]); + if (bp_commbuf[0] != '1') { + msg_perr("Can't handle raw SPI mode version %c!\n", bp_commbuf[0]); return 1; }

1 0

Re: [flashrom] [PATCH/WIP] AT45DB011D flashing support
by Aidan Thornton 17 Aug '12

17 Aug '12

Let's try that again, this time remembering to svn add the new file. Sorry about that On Fri, Aug 17, 2012 at 5:53 PM, Aidan Thornton <makosoft(a)gmail.com> wrote: > Hi, > > The attached patch is a somewhat messy attempt to add support for the > AT45DB011D and potentially other AT45DBxxxD Atmel DataFlash chips. > I've tested flashing the AT45DB011D-like integrated Flash on the > Xilinx XC3S50AN with it and it appears to work. Not really ready to > merge, but carldani asked me to post this so he could see if it could > be combined with his old incomplete code for non-power-of-2 flash > chips. Should in theory be able to read all AT45DBxxxD chips as-is and > write all chips that have 256/264-byte pages with suitable additions > to flashchips.c. > > Aidan

1 0

[PATCH/WIP] AT45DB011D flashing support
by Aidan Thornton 17 Aug '12

17 Aug '12

Hi, The attached patch is a somewhat messy attempt to add support for the AT45DB011D and potentially other AT45DBxxxD Atmel DataFlash chips. I've tested flashing the AT45DB011D-like integrated Flash on the Xilinx XC3S50AN with it and it appears to work. Not really ready to merge, but carldani asked me to post this so he could see if it could be combined with his old incomplete code for non-power-of-2 flash chips. Should in theory be able to read all AT45DBxxxD chips as-is and write all chips that have 256/264-byte pages with suitable additions to flashchips.c. Aidan

1 0

AT45DB011D / Spartan-3AN SPI flash
by Aidan Thornton 17 Aug '12

17 Aug '12

Hi, So I've got access to a board with an AT45DB011D (or more accurately a XC3S50AN FPGA with integrated SPI flash that's identical to an AT45DB011D down to the ID bytes) hooked up to an FT4232H-based programmer. I've chatted to stefanct in IRC and apparently this is unlikely to be supported by flashrom in the near future, but if at some point someone does want to add support and I still have access to this board I might be able to test it. For anyone that isn't familiar with the AT45DB011D, it's an oddball Atmel DataFlash chip with a non-power-of-two page size (264 bytes per page) and a slightly interesting address space as a result of that. It's also available in a 256-byte page variant that has the same ID and which can only be distinguished by a bit in the status register. One of the read commands supported is mostly standard aside from some weirdness resulting from the odd page size, writing and erasing is probably less so. Aidan

1 0

CHIPSET: AMD CS5536
by Sven Neumann 17 Aug '12

17 Aug '12

Hi, I am trying to flash a new coreboot image to our hardware, which is a "PC Engines ALIX 2C.2" board, see http://pcengines.ch/alix2c2.htm Latest version of flashrom gives me following output, so I am reporting this to you as requested: flashrom v0.9.6.1-r1564 on Linux 3.5.2 (i586) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. coreboot table found at 0xf7c1c00. Found chipset "AMD CS5536". Enabling flash write... OK. WARNING: unexpected second chipset match: "AMD CS5536" ignoring, please report lspci and board URL to flashrom(a)flashrom.org with 'CHIPSET: your board name' in the subject line. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. And here's the output from "lspci -v": 00:01.0 Class 0600: Device 1022:2080 (rev 33) Subsystem: Device 1022:2080 Flags: bus master, 66MHz, medium devsel, latency 64 I/O ports at ac1c [size=4] 00:01.2 Class 1010: Device 1022:2082 Subsystem: Device 1022:2082 Flags: 66MHz, medium devsel, IRQ 11 Memory at fe020000 (32-bit, non-prefetchable) [size=16K] 00:09.0 Class 0200: Device 1106:3053 (rev 96) Subsystem: Device 1106:0106 Flags: bus master, stepping, medium devsel, latency 64, IRQ 10 I/O ports at 1000 [size=256] Memory at fe029000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Kernel driver in use: via-rhine 00:0b.0 Class 0200: Device 1106:3053 (rev 96) Subsystem: Device 1106:0106 Flags: bus master, stepping, medium devsel, latency 64, IRQ 9 I/O ports at 1400 [size=256] Memory at fe029100 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Kernel driver in use: via-rhine 00:0c.0 Class 0200: Device 168c:001b (rev 01) Subsystem: Device 185f:1600 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at fe000000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 Kernel driver in use: ath5k Kernel modules: ath5k 00:0f.0 Class 0601: Device 1022:2090 (rev 03) Subsystem: Device 1022:2090 Flags: 66MHz, medium devsel I/O ports at 20b0 [size=8] I/O ports at 1800 [size=256] I/O ports at 2000 [size=64] I/O ports at 2080 [size=32] I/O ports at 1c00 [size=128] I/O ports at 2040 [size=64] Kernel driver in use: cs5535-mfd 00:0f.2 Class 0101: Device 1022:209a (rev 01) (prog-if 80 [Master]) Subsystem: Device 1022:209a Flags: bus master, 66MHz, medium devsel, latency 248 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) I/O ports at 20a0 [size=16] Kernel driver in use: cs5536 00:0f.4 Class 0c03: Device 1022:2094 (rev 02) (prog-if 10) Subsystem: Device 1022:2094 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 9 Memory at fe026000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Kernel driver in use: ohci_hcd 00:0f.5 Class 0c03: Device 1022:2095 (rev 02) (prog-if 20) Subsystem: Device 1022:2095 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 9 Memory at fe027000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Kernel driver in use: ehci_hcd As flashrom does not appear to find the flash chip, I am now somewhat stuck. Any help would be much appreciated. Regards, Sven -- Sven Neumann Head of RAUMFELD Software Development Lautsprecher Teufel GmbH Gewerbehof Bülowbogen - Aufgang D1 Bülowstr. 66 - 10783 Berlin - Germany Registernummer HRB 20271 beim Amtsgericht Berlin-Charlottenburg Geschäftsführer: Thorsten Reuber, Thomas Stiegler Tel. +49 (0)30 - 300 930 - 0, Direkt -153 neumann(a)teufel.de www.teufel.de www.teufelaudio.com http://blog.teufel.de

1 1

[PATCH] Allow specifying CPPFLAGS
by Carl-Daniel Hailfinger 15 Aug '12

15 Aug '12

The user may know better which CFLAGS/CPPFLAGS are appropriate. Use FLASHROM_CFLAGS for flags which flashrom definitely needs to build. Note: With this patch, automatic Ubuntu Launchpad builds should work again. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-makefile_allow_cppflags/Makefile =================================================================== --- flashrom-makefile_allow_cppflags/Makefile (Revision 1574) +++ flashrom-makefile_allow_cppflags/Makefile (Arbeitskopie) @@ -122,7 +122,7 @@ ifeq ($(TARGET_OS), MinGW) EXEC_SUFFIX := .exe # MinGW doesn't have the ffs() function, but we can use gcc's __builtin_ffs(). -CPPFLAGS += -Dffs=__builtin_ffs +FLASHROM_CFLAGS += -Dffs=__builtin_ffs # libusb-win32/libftdi stuff is usually installed in /usr/local. CPPFLAGS += -I/usr/local/include LDFLAGS += -L/usr/local/lib @@ -201,7 +201,7 @@ endif ifeq ($(TARGET_OS), libpayload) -CPPFLAGS += -DSTANDALONE +FLASHROM_CFLAGS += -DSTANDALONE ifeq ($(CONFIG_DUMMY), yes) UNSUPPORTED_FEATURES += CONFIG_DUMMY=yes else @@ -603,7 +603,7 @@ TAROPTIONS = $(shell LC_ALL=C tar --version|grep -q GNU && echo "--owner=root --group=root") %.o: %.c .features - $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< + $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< # Make sure to add all names of generated binaries here. # This includes all frontends and libflashrom. Index: flashrom-makefile_allow_cppflags/util/ich_descriptors_tool/Makefile =================================================================== --- flashrom-makefile_allow_cppflags/util/ich_descriptors_tool/Makefile (Revision 1574) +++ flashrom-makefile_allow_cppflags/util/ich_descriptors_tool/Makefile (Arbeitskopie) @@ -30,10 +30,10 @@ endif -CPPFLAGS += -MMD -MP -MF $(DEPPATH)/$((a)F).d +FLASHROM_CFLAGS += -MMD -MP -MF $(DEPPATH)/$((a)F).d # enables functions that populate the descriptor structs from plain binary dumps -CPPFLAGS += -D ICH_DESCRIPTORS_FROM_DUMP -CPPFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) +FLASHROM_CFLAGS += -D ICH_DESCRIPTORS_FROM_DUMP +FLASHROM_CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) OBJ = $(OBJATH)/$(SRC:%.c=%.o) @@ -42,15 +42,15 @@ all:$(PROGRAM)$(EXEC_SUFFIX) $(OBJ): $(OBJATH)/%.o : %.c - $(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $< + $(CC) $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) -o $@ -c $< # this enables us to share source files without simultaneously sharing .o files # with flashrom, which would lead to unexpected results (w/o running make clean) $(SHAREDOBJ): $(OBJATH)/%.o : $(SHAREDSRCDIR)/%.c - $(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $< + $(CC) $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) -o $@ -c $< $(PROGRAM)$(EXEC_SUFFIX): $(OBJ) $(SHAREDOBJ) - $(CC) -o $(PROGRAM)$(EXEC_SUFFIX) $(OBJ) $(SHAREDOBJ) + $(CC) $(LDFLAGS) -o $(PROGRAM)$(EXEC_SUFFIX) $(OBJ) $(SHAREDOBJ) clean: rm -f $(PROGRAM) $(PROGRAM).exe -- http://www.hailfinger.org/

1 1

[commit] r1575 - in trunk: . util/ich_descriptors_tool
by repository service 15 Aug '12

15 Aug '12

Author: hailfinger Date: Thu Aug 16 01:06:32 2012 New Revision: 1575 URL: http://flashrom.org/trac/flashrom/changeset/1575 Log: Allow specifying CPPFLAGS The user may know better which CFLAGS/CPPFLAGS are appropriate. Use FLASHROM_CFLAGS for flags which flashrom definitely needs to build. Thanks to Stefan Tauner for pointing out the flaw in r1574. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/Makefile trunk/util/ich_descriptors_tool/Makefile Modified: trunk/Makefile ============================================================================== --- trunk/Makefile Tue Aug 14 23:36:11 2012 (r1574) +++ trunk/Makefile Thu Aug 16 01:06:32 2012 (r1575) @@ -122,7 +122,7 @@ ifeq ($(TARGET_OS), MinGW) EXEC_SUFFIX := .exe # MinGW doesn't have the ffs() function, but we can use gcc's __builtin_ffs(). -CPPFLAGS += -Dffs=__builtin_ffs +FLASHROM_CFLAGS += -Dffs=__builtin_ffs # libusb-win32/libftdi stuff is usually installed in /usr/local. CPPFLAGS += -I/usr/local/include LDFLAGS += -L/usr/local/lib @@ -201,7 +201,7 @@ endif ifeq ($(TARGET_OS), libpayload) -CPPFLAGS += -DSTANDALONE +FLASHROM_CFLAGS += -DSTANDALONE ifeq ($(CONFIG_DUMMY), yes) UNSUPPORTED_FEATURES += CONFIG_DUMMY=yes else @@ -603,7 +603,7 @@ TAROPTIONS = $(shell LC_ALL=C tar --version|grep -q GNU && echo "--owner=root --group=root") %.o: %.c .features - $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< + $(CC) -MMD $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) $(FEATURE_CFLAGS) $(SVNDEF) -o $@ -c $< # Make sure to add all names of generated binaries here. # This includes all frontends and libflashrom. Modified: trunk/util/ich_descriptors_tool/Makefile ============================================================================== --- trunk/util/ich_descriptors_tool/Makefile Tue Aug 14 23:36:11 2012 (r1574) +++ trunk/util/ich_descriptors_tool/Makefile Thu Aug 16 01:06:32 2012 (r1575) @@ -30,10 +30,10 @@ endif -CPPFLAGS += -MMD -MP -MF $(DEPPATH)/$((a)F).d +FLASHROM_CFLAGS += -MMD -MP -MF $(DEPPATH)/$((a)F).d # enables functions that populate the descriptor structs from plain binary dumps -CPPFLAGS += -D ICH_DESCRIPTORS_FROM_DUMP -CPPFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) +FLASHROM_CFLAGS += -D ICH_DESCRIPTORS_FROM_DUMP +FLASHROM_CFLAGS += $(patsubst %,-I%,$(EXTRAINCDIRS)) OBJ = $(OBJATH)/$(SRC:%.c=%.o) @@ -42,15 +42,15 @@ all:$(PROGRAM)$(EXEC_SUFFIX) $(OBJ): $(OBJATH)/%.o : %.c - $(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $< + $(CC) $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) -o $@ -c $< # this enables us to share source files without simultaneously sharing .o files # with flashrom, which would lead to unexpected results (w/o running make clean) $(SHAREDOBJ): $(OBJATH)/%.o : $(SHAREDSRCDIR)/%.c - $(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $< + $(CC) $(CFLAGS) $(CPPFLAGS) $(FLASHROM_CFLAGS) -o $@ -c $< $(PROGRAM)$(EXEC_SUFFIX): $(OBJ) $(SHAREDOBJ) - $(CC) -o $(PROGRAM)$(EXEC_SUFFIX) $(OBJ) $(SHAREDOBJ) + $(CC) $(LDFLAGS) -o $(PROGRAM)$(EXEC_SUFFIX) $(OBJ) $(SHAREDOBJ) clean: rm -f $(PROGRAM) $(PROGRAM).exe

1 0

Re: [flashrom] IBM SurePOS 700 4800-783 support
by Stefan Tauner 15 Aug '12

15 Aug '12

On Wed, 15 Aug 2012 08:56:34 -0400 Jason_Vannest(a)abercrombie.com wrote: Hi Jason! > Sorry Stefan, > > I've been busy and our test lab is being used to do a regression right now > so I've not had time to try and compile and test the patch you provided. NP, i just wanted to get sure you have received my last mail and nothing momentous happened, because your replies were within days or even hours before. > I do intend to do so, give me a little more time and I'll see what I can > do. We have received your other message containing the read out bios image. It sits in the moderation queue at the moment, because we can't publish it (it is copyrighted). Thanks for taking the time to test! What we actually wanted to see is the output that flashrom prints to screen (or saves to a file when one specifies the log file option -o "logfilename"). But since you were able to read the BIOS file correctly the patch seems to have worked at least to some extend. This is great news! Nevertheless please send the verbose output of flashrom too. > On the topic of IBM and help, I have been in discussion with IBM about the > firmware updates and they have been very adamant that we need to insure > that we update all the devices not just the BIOS itself. From looking at > a handful of their update packages, I can see that they frequently include > updates for riser cards, service processors and possibly other devices > with the BIOS updates. So before we implement something with flashrom we > would want to make sure we're not missing something that could later cause > us issues even if the issues are only that IBM is unhappy because we > didn't follow their update procedures. The latter would be the last thing i would worry about, but especially the service processors might interact with the BIOS and if an update changes the protocol that they talk with each other, then this may lead to unbootable machines... It is probably possible to add support for the other device to flashrom as well, but that would certainly not be a single line change and take way more time to implement, even if IBM provides some documentation. Without documentation it would probably be pretty much infeasible. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] IBM SurePOS 700 4800-783 support
by Stefan Tauner 15 Aug '12

15 Aug '12

On Wed, 11 Jul 2012 18:17:19 -0400 Jason_Vannest(a)abercrombie.com wrote: > If I'm reading the flashrom site correctly this is one of the flash chips > that flashrom has support for already. So that might be a plus. Yes, the flash chip itself wont be a problem. There is a service manual for the POS located at ftp://ftp.software.ibm.com/software/retail/pubs/hw/4800_surepos700/btd5_480… and it mentions a "backup bios" in the service processor section. That could complicate things further (or help you out if something fails if you are very lucky, but usually it make things worse for us). The remainder of the document is not very helpful (targeted at users not developers). > > I'd venture a guess that we can do this before IBM can > > even give you a quote. > > What kind of information would you want? I have pretty solid connections > with IBM I may be able to get questions answered about this. A schematic that contains the data path between the southbridge and the flash chip as well as its relation to the Renesas IC would indicate if we have to take care about the Renesas at all. Any additional information regarding the BIOS upgrade process (e.g. if the version of the Renesas' firmware has to be kept in sync with the BIOS) or the service processor's interaction with the flash chip would be very welcome too. Above all we need to work on the support for the VIA chipset (VT8251), but IBM won't be able to help us with that. I have no news regarding that. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom