flashrom

flashrom@flashrom.org

5 participants
9161 discussions

issue with using a flashrom with Dediprog (SF100) programmer
by Ansbacher, Nadav 23 Feb '15

23 Feb '15

Hi, We're using flashrom app with a Dediprog (SF100) programmer. Our OS is SLES11. Sometimes, I'm getting the "Dediprog_BAD" log after disconnecting and reconnecting the SF100, I'm getting the "dediprog_GOOD" log. Any idea? Nadav --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [flashrom] [coreboot] New flashrom logo
by Stefan Tauner 22 Feb '15

22 Feb '15

On Sun, 22 Feb 2015 02:16:57 +0100 Peter Stuge <peter(a)stuge.se> wrote: > either make the > lightning bolt smaller or perhaps just remove it, because the > connection between lightning and memory chips isn't so obvious. Removing it (without replacement) is not an option... that would make it simply a chip icon. That by no means qualifies as a good logo for a software project :) The logo's background idea does not have to be obvious (i.e. if one doesn't know it is related to flashrom, one does not necessarily need to derive that relationship), but it should be recognizable and clear once you know it to make the whole logo<->project relation memorable... and I really think that a flash and a rom/chip qualifies to represent flashrom in such a way :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [coreboot] New flashrom logo
by Stefan Tauner 22 Feb '15

22 Feb '15

On Sun, 22 Feb 2015 02:26:19 +0100 Peter Stuge <peter(a)stuge.se> wrote: > Peter Stuge wrote: > > Stefan Tauner wrote: > > > What do you think about my suggestions and the whole matter? > > > > soic8_30degrees is really good. I would only suggest to perhaps > > rotate > > clockwise > > > around the X axis a little bit, > > to view the chip more from the side, rather than from above. I am not sure where your X axis and origin is, but I have rotated it 30° "back" around the Y axis now :) Is that what you meant? That makes the flash look a bit stupid and makes the whole thing way less recognizable IMHO. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[PATCH v2] Added support to control the GPIOs in the ft222_spi driver from the command line
by Reggie McMurtrey 22 Feb '15

22 Feb '15

Quick Test --- flashrom.8.tmpl | 17 ++++++++++++ ft2232_spi.c | 81 ++++++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 80 insertions(+), 18 deletions(-) diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl index 8b5f98c..40d8d84 100644 --- a/flashrom.8.tmpl +++ b/flashrom.8.tmpl @@ -681,6 +681,23 @@ parameter with the .B " flashrom \-p ft2232_spi:divisor=div" .sp syntax. +.sp +If the ft2232_spi device has been integrated into a custom board, or you are using a breakout cable +like the C232HM cable from FTDI you can control the upper bits of the port ( bits 7-4 ) via the +.sp +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" +.sp +syntax where +.B dir +is a mask defining the directions of the port's upper bits. +.B value +is the value of the bits for the port. Only bits defined as outputs with the +.B dir +argument are affected. For example +.B gpio_dir=0xf0,gpio_value=0x80 +would set the four upper bits of the port as outputs with bit 7 as high, and bits 6 through 4 as +low. This could be useful for controlling write protects, muxing options, or other in +circuit programming related features. .SS .BR "serprog " programmer A mandatory parameter specifies either a serial diff --git a/ft2232_spi.c b/ft2232_spi.c index 4e23797..75cb772 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { */ static uint8_t cs_bits = 0x08; static uint8_t pindir = 0x0b; +static uint8_t gpio_dir = 0x00; +static uint8_t gpio_value = 0x00; +static uint8_t adapter_mask = 0x00; static struct ftdi_context ftdic_context; static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) @@ -204,10 +207,11 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -224,8 +228,9 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -235,10 +240,11 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_PID; channel_count = 2; /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -248,8 +254,9 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -262,6 +269,38 @@ int ft2232_spi_init(void) } free(arg); + arg = extract_programmer_param("gpio_dir"); + if (arg && strlen(arg)) { + unsigned int temp = 0; + char *endptr; + temp = strtoul(arg, &endptr, 16); + if (*endptr || temp > 0xFF) { + msg_perr("Error: Invalid GPIO direction mask \"%s\".\n" + "Valid values are between 0x0 and 0xff (the lower four bits are ignored).\n", arg); + free(arg); + return -2; + } else { + gpio_dir = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_dir; + } + } + free(arg); + + arg = extract_programmer_param("gpio_value"); + if (arg && strlen(arg)) { + unsigned int temp = 0; + char *endptr; + temp = strtoul(arg, &endptr, 16); + if (*endptr || temp > 0xFF) { + msg_perr("Error: Invalid GPIO value mask \"%s\".\n" + "Valid values are between 0x0 and 0xff (the lower four bits are ignored).\n", arg); + free(arg); + return -2; + } else { + gpio_value = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_value; + } + } + free(arg); + arg = extract_programmer_param("port"); if (arg) { switch (toupper((unsigned char)*arg)) { @@ -391,9 +430,11 @@ int ft2232_spi_init(void) } msg_pdbg("Set data bits\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; - buf[2] = pindir; + buf[1] = cs_bits | gpio_value; + buf[2] = pindir | gpio_dir; if (send_buf(ftdic, buf, 3)) { ret = -8; goto ftdi_err; @@ -446,9 +487,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, * operations. */ msg_pspew("Assert CS#\n"); + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ - buf[i++] = pindir; + buf[i++] = ~cs_bits & gpio_value; /* assertive */ + buf[i++] = pindir | gpio_dir; if (writecnt) { buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; @@ -487,9 +530,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, } msg_pspew("De-assert CS#\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; - buf[i++] = pindir; + buf[i++] = cs_bits | gpio_value; + buf[i++] = pindir | gpio_dir; ret = send_buf(ftdic, buf, i); failed |= ret; if (ret) -- 1.9.1

1 0

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 22 Feb '15

22 Feb '15

On Sat, 21 Feb 2015 15:19:42 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Not sure why patch seems mangled. I looked at the mailing list archive to > see what happened and it shows up ok there. I was informed I should have > bumped the subject to [PATCH v2]. I'll make sure to do that in the > future. I'll be glad to post patch again if needed. Focus on the line breaks and number of tabs/spaces after the + signs... clearly some kind of mangling happened. > > Programmer inits don't seem to have any specific meaning other than > pass/fail. Why -2 then? :) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 21 Feb '15

21 Feb '15

On Sat, 21 Feb 2015 09:34:23 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Thanks for the feedback Stefan, Trying again :) Thanks, but the patch got mangled by your email client apparently. BTW I am not sure what -2 means in programmer inits from the top of my head... if there is a macro name for that please use it. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Antony Pavlov 21 Feb '15

21 Feb '15

On Sat, 21 Feb 2015 09:34:23 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > Thanks for the feedback Stefan, Trying again :) You have submitted version 2 of your patch. So please note this fact in the Subject. E.g. use "[PATCH v2]" instead of "[PATCH]" in the message's subject. You can use git-format-patch '--subject-prefix' option or just edit subject by hand. > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > --- > flashrom.8.tmpl | 17 ++++++++++++ > ft2232_spi.c | 81 > ++++++++++++++++++++++++++++++++++++++++++++------------- > 2 files changed, 80 insertions(+), 18 deletions(-) > > diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl > index 8b5f98c..40d8d84 100644 > --- a/flashrom.8.tmpl > +++ b/flashrom.8.tmpl > @@ -681,6 +681,23 @@ parameter with the > .B " flashrom \-p ft2232_spi:divisor=div" > .sp > syntax. > +.sp > +If the ft2232_spi device has been integrated into a custom board, or you > are using a breakout cable > +like the C232HM cable from FTDI you can control the upper bits of the port > ( bits 7-4 ) via the > +.sp > +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" > +.sp > +syntax where > +.B dir > +is a mask defining the directions of the port's upper bits. > +.B value > +is the value of the bits for the port. Only bits defined as outputs with > the > +.B dir > +argument are affected. For example > +.B gpio_dir=0xf0,gpio_value=0x80 > +would set the four upper bits of the port as outputs with bit 7 as high, > and bits 6 through 4 as > +low. This could be useful for controlling write protects, muxing options, > or other in > +circuit programming related features. > .SS > .BR "serprog " programmer > A mandatory parameter specifies either a serial > diff --git a/ft2232_spi.c b/ft2232_spi.c > index 4e23797..75cb772 100644 > --- a/ft2232_spi.c > +++ b/ft2232_spi.c > @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { > */ > static uint8_t cs_bits = 0x08; > static uint8_t pindir = 0x0b; > +static uint8_t gpio_dir = 0x00; > +static uint8_t gpio_value = 0x00; > +static uint8_t adapter_mask = 0x00; > static struct ftdi_context ftdic_context; > > static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) > @@ -204,10 +207,11 @@ int ft2232_spi_init(void) > ft2232_type = AMONTEC_JTAGKEY_PID; > channel_count = 2; > /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 > - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low > - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ > - cs_bits = 0x18; > - pindir = 0x1b; > + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) > + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) */ > + gpio_dir = 0x10; > + gpio_value = 0x10; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "picotap")) { > ft2232_vid = GOEPEL_VID; > ft2232_type = GOEPEL_PICOTAP_PID; > @@ -224,8 +228,9 @@ int ft2232_spi_init(void) > /* In its default configuration it is a jtagkey clone */ > ft2232_type = FTDI_FT2232H_PID; > channel_count = 2; > - cs_bits = 0x18; > - pindir = 0x1b; > + gpio_dir = 0x10; > + gpio_value = 0x10; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "openmoko")) { > ft2232_vid = FIC_VID; > ft2232_type = OPENMOKO_DBGBOARD_PID; > @@ -235,10 +240,11 @@ int ft2232_spi_init(void) > ft2232_type = OLIMEX_ARM_OCD_PID; > channel_count = 2; > /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by > pulling ADBUS4 low. > - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low > - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ > - cs_bits = 0x08; > - pindir = 0x1b; > + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) > + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), > Reserved (SK) */ > + gpio_dir = 0x10; > + gpio_value = 0x00; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "arm-usb-tiny")) { > ft2232_vid = OLIMEX_VID; > ft2232_type = OLIMEX_ARM_TINY_PID; > @@ -248,8 +254,9 @@ int ft2232_spi_init(void) > ft2232_type = OLIMEX_ARM_OCD_H_PID; > channel_count = 2; > /* See arm-usb-ocd */ > - cs_bits = 0x08; > - pindir = 0x1b; > + gpio_dir = 0x10; > + gpio_value = 0x00; > + adapter_mask = 0x10; > } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { > ft2232_vid = OLIMEX_VID; > ft2232_type = OLIMEX_ARM_TINY_H_PID; > @@ -262,6 +269,38 @@ int ft2232_spi_init(void) > } > free(arg); > > + arg = extract_programmer_param("gpio_dir"); > + if (arg && strlen(arg)) { > + unsigned int temp = 0; > + char *endptr; > + temp = strtoul(arg, &endptr, 16); > + if (*endptr || temp > 0xFF) { > + msg_perr("Error: Invalid GPIO direction mask \"%s\".\n" > + "Valid values are between 0x0 and 0xff (the lower four bits are > ignored).\n", arg); > + free(arg); > + return -2; > + } else { > + gpio_dir = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_dir; > + } > + } > + free(arg); > + > + arg = extract_programmer_param("gpio_value"); > + if (arg && strlen(arg)) { > + unsigned int temp = 0; > + char *endptr; > + temp = strtoul(arg, &endptr, 16); > + if (*endptr || temp > 0xFF) { > + msg_perr("Error: Invalid GPIO value mask \"%s\".\n" > + "Valid values are between 0x0 and 0xff (the lower four bits are > ignored).\n", arg); > + free(arg); > + return -2; > + } else { > + gpio_value = ((uint32_t) temp & (0xf0 & ~adapter_mask)) | gpio_value; > + } > + } > + free(arg); > + > arg = extract_programmer_param("port"); > if (arg) { > switch (toupper((unsigned char)*arg)) { > @@ -391,9 +430,11 @@ int ft2232_spi_init(void) > } > > msg_pdbg("Set data bits\n"); > + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[0] = SET_BITS_LOW; > - buf[1] = cs_bits; > - buf[2] = pindir; > + buf[1] = cs_bits | gpio_value; > + buf[2] = pindir | gpio_dir; > if (send_buf(ftdic, buf, 3)) { > ret = -8; > goto ftdi_err; > @@ -446,9 +487,11 @@ static int ft2232_spi_send_command(struct flashctx > *flash, > * operations. > */ > msg_pspew("Assert CS#\n"); > + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[i++] = SET_BITS_LOW; > - buf[i++] = 0 & ~cs_bits; /* assertive */ > - buf[i++] = pindir; > + buf[i++] = ~cs_bits & gpio_value; /* assertive */ > + buf[i++] = pindir | gpio_dir; > > if (writecnt) { > buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; > @@ -487,9 +530,11 @@ static int ft2232_spi_send_command(struct flashctx > *flash, > } > > msg_pspew("De-assert CS#\n"); > + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); > + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); > buf[i++] = SET_BITS_LOW; > - buf[i++] = cs_bits; > - buf[i++] = pindir; > + buf[i++] = cs_bits | gpio_value; > + buf[i++] = pindir | gpio_dir; > ret = send_buf(ftdic, buf, i); > failed |= ret; > if (ret) > -- > 1.9.1 > > > On Sat, Feb 21, 2015 at 4:20 AM, Stefan Tauner < > stefan.tauner(a)alumni.tuwien.ac.at> wrote: > > > On Fri, 20 Feb 2015 18:21:09 -0600 > > Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > > > > > This is my first time submitting a patch to a project, so let me know > > > if I have done something wrong here. > > > > > > > > > I commonly use the C232HM cable from FTDI to program various parts of > > > boards I design. This one cable allows me to program SPI, I2C, and > > > JTAG parts. Simply adding some muxes to the design I have a single > > > header to attach this cable to. The patch below allows control of the > > > muxes from the GPIOL3-GPIOL0 signals on the cable and disable write > > > protection. I figured other people may like this capability if they > > > are using a similar breakout cable of have designed the ft2232 chip > > > into their design. > > > > > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > > > > > @@ -262,6 +269,18 @@ int ft2232_spi_init(void) > > > } > > > free(arg); > > > > > > + arg = extract_programmer_param("gpio_dir"); > > > + if (arg) { > > > + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) > > | gpio_dir; > > > + } > > > + free(arg); > > > + > > > + arg = extract_programmer_param("gpio_value"); > > > + if (arg) { > > > + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & > > ~adapter_mask)) | gpio_value; > > > + } > > > + free(arg); > > > + > > > arg = extract_programmer_param("port"); > > > if (arg) { > > > switch (toupper((unsigned char)*arg)) { > > > > Hello Reggie, > > > > thanks for your patch! I had no time to review it in detail but we > > definitely want some error/wrong input handling for the parameter > > parsing above. There are various similar checks throughout the code > > base that you may wanna look at... not all are perfect yet though. If > > you have any doubts then please refer to the strtol(3) manpage. > > > > A more detailed review will follow when that's fixed. > > -- > > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > -- -- Best regards, Antony Pavlov

1 0

Re: [flashrom] [PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Stefan Tauner 21 Feb '15

21 Feb '15

On Fri, 20 Feb 2015 18:21:09 -0600 Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote: > This is my first time submitting a patch to a project, so let me know > if I have done something wrong here. > > > I commonly use the C232HM cable from FTDI to program various parts of > boards I design. This one cable allows me to program SPI, I2C, and > JTAG parts. Simply adding some muxes to the design I have a single > header to attach this cable to. The patch below allows control of the > muxes from the GPIOL3-GPIOL0 signals on the cable and disable write > protection. I figured other people may like this capability if they > are using a similar breakout cable of have designed the ft2232 chip > into their design. > > Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> > > @@ -262,6 +269,18 @@ int ft2232_spi_init(void) > } > free(arg); > > + arg = extract_programmer_param("gpio_dir"); > + if (arg) { > + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_dir; > + } > + free(arg); > + > + arg = extract_programmer_param("gpio_value"); > + if (arg) { > + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_value; > + } > + free(arg); > + > arg = extract_programmer_param("port"); > if (arg) { > switch (toupper((unsigned char)*arg)) { Hello Reggie, thanks for your patch! I had no time to review it in detail but we definitely want some error/wrong input handling for the parameter parsing above. There are various similar checks throughout the code base that you may wanna look at... not all are perfect yet though. If you have any doubts then please refer to the strtol(3) manpage. A more detailed review will follow when that's fixed. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

[PATCH] Added support to control the GPIOs in the ft222_spi driver from the command line
by Reggie McMurtrey 21 Feb '15

21 Feb '15

This is my first time submitting a patch to a project, so let me know if I have done something wrong here. I commonly use the C232HM cable from FTDI to program various parts of boards I design. This one cable allows me to program SPI, I2C, and JTAG parts. Simply adding some muxes to the design I have a single header to attach this cable to. The patch below allows control of the muxes from the GPIOL3-GPIOL0 signals on the cable and disable write protection. I figured other people may like this capability if they are using a similar breakout cable of have designed the ft2232 chip into their design. Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> *--- flashrom.8.tmpl | 17 ++++++++++++++++ ft2232_spi.c | 61 ++++++++++++++++++++++++++++++++++++++++----------------- 2 files changed, 60 insertions(+), 18 deletions(-) diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl index 8b5f98c..40d8d84 100644 --- a/flashrom.8.tmpl +++ b/flashrom.8.tmpl @@ -681,6 +681,23 @@ parameter with the .B " flashrom \-p ft2232_spi:divisor=div" .sp syntax. +.sp +If the ft2232_spi device has been integrated into a custom board, or you are using a breakout cable +like the C232HM cable from FTDI you can control the upper bits of the port ( bits 7-4 ) via the +.sp +.B " flashrom \-p ft2232_spi:gpio_dir=dir,gpio_value=value" +.sp +syntax where +.B dir +is a mask defining the directions of the port's upper bits. +.B value +is the value of the bits for the port. Only bits defined as outputs with the +.B dir +argument are affected. For example +.B gpio_dir=0xf0,gpio_value=0x80 +would set the four upper bits of the port as outputs with bit 7 as high, and bits 6 through 4 as +low. This could be useful for controlling write protects, muxing options, or other in +circuit programming related features. .SS .BR "serprog " programmer A mandatory parameter specifies either a serial diff --git a/ft2232_spi.c b/ft2232_spi.c index 4e23797..c7a78fe 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -93,6 +93,9 @@ const struct dev_entry devs_ft2232spi[] = { */ static uint8_t cs_bits = 0x08; static uint8_t pindir = 0x0b; +static uint8_t gpio_dir = 0x00; +static uint8_t gpio_value = 0x00; +static uint8_t adapter_mask = 0x00; static struct ftdi_context ftdic_context; static const char *get_ft2232_devicename(int ft2232_vid, int ft2232_type) @@ -204,10 +207,11 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x10 OE=high, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -224,8 +228,9 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x10; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -235,10 +240,11 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_PID; channel_count = 2; /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. - * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + * value: 0x00 #OE=low, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) + * dir: 0x10 #OE=output, Reserved (CS), Reserved (DI), Reserved (DO), Reserved (SK) */ + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -248,8 +254,9 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + gpio_dir = 0x10; + gpio_value = 0x00; + adapter_mask = 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -262,6 +269,18 @@ int ft2232_spi_init(void) } free(arg); + arg = extract_programmer_param("gpio_dir"); + if (arg) { + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_dir; + } + free(arg); + + arg = extract_programmer_param("gpio_value"); + if (arg) { + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_value; + } + free(arg); + arg = extract_programmer_param("port"); if (arg) { switch (toupper((unsigned char)*arg)) { @@ -391,9 +410,11 @@ int ft2232_spi_init(void) } msg_pdbg("Set data bits\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; - buf[2] = pindir; + buf[1] = cs_bits | gpio_value; + buf[2] = pindir | gpio_dir; if (send_buf(ftdic, buf, 3)) { ret = -8; goto ftdi_err; @@ -446,9 +467,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, * operations. */ msg_pspew("Assert CS#\n"); + msg_pspew("Value: 0x%02x\n", ~cs_bits & gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ - buf[i++] = pindir; + buf[i++] = ~cs_bits & gpio_value; /* assertive */ + buf[i++] = pindir | gpio_dir; if (writecnt) { buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; @@ -487,9 +510,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, } msg_pspew("De-assert CS#\n"); + msg_pspew("Value: 0x%02x\n", cs_bits | gpio_value); + msg_pspew("Dir: 0x%02x\n", pindir | gpio_dir); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; - buf[i++] = pindir; + buf[i++] = cs_bits | gpio_value; + buf[i++] = pindir | gpio_dir; ret = send_buf(ftdic, buf, i); failed |= ret; if (ret) -- 1.9.1*

1 0

Re: [flashrom] Unknown SPI chip on Google Falco with linux_spi
by David Hendricks 19 Feb '15

19 Feb '15

The ID bytes are reading as FF's. Double check your connections <http://flashrom.org/RaspberryPi> and ensure that the C720 is completely powered off (disconnect both the battery and the AC power). On Wed, Feb 18, 2015 at 9:09 PM, Remigijus Jarmalavičius < remigijus(a)jarmalavicius.lt> wrote: > Hi, > > I am trying to unbrick latest Acer C720 with flashrom. What I have already > done: > > > - Created ROM image successfully for writing with flashrom; > - Connected wires from Raspberry Pi to EEPROM chip on C720. > - Enabled kernel modules and tested with spidev_test (it returns data, > looks normal - not all 00's or FF's) > - Download latest flashrom from svn and compiled. > - Then executed: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > > After a lot output it said to me: > > Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on > linux_spi. > Probing for Generic unknown SPI chip (REMS), 0 kB: REMS returned 0xff > 0xff. probe_spi_rems: id1 0xff, id2 0xff > Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI). > === > This flash part has status NOT WORKING for operations: PROBE READ ERASE > WRITE > The test status of this chip may have been updated in the latest > development > version of flashrom. If you are running the latest development version, > please email a report to flashrom(a)flashrom.org if any of the above > operations > work correctly for you with this flash chip. Please include the flashrom > log > file for all operations you tested (see the man page for details), and > mention > which mainboard or programmer you tested in the subject line. > Thanks for your help! > No operations were specified. > > I saw that sometimes chip numbers are not entered to the flashrom source, > maybe it's the same case? I think I have read all sites I found on Google > about unbricking acer c720. What I should try next? > > Some details: > > > - Ubuntu 14 OS on Raspberry Pi B version. > - Acer chromebook c720 (model no: zhn) > > Please help me solve the issue. I am attaching complete log > command: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > log > > > > -- > > *Remigijus Jarmalavičius* > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom