August 2014 - flashrom - mail.coreboot.org

Re: [flashrom] Macronix MX25L12835FMI-10G, bus pirate and flashrom support
by Stefan Tauner Aug. 19, 2014

Aug. 19, 2014

On Mon, 18 Aug 2014 17:38:04 +0200 Marli LI <marco.li.li.marco(a)gmail.com> wrote: > Hello all, > > I need some help to get this chip MX25L12835FMI-10G manufactured by > Macronix to work w/ flashrom. > > I already asked for help on #flashrom IRC channel, but I was referred > to ask on this mailing list. > In fact, before I connected everything I asked on IRC if this chip is > "already" supported, and someone from IRC did double-check it and said > that the other MX25L128 chip model that IS supported is very similar > and identifies itself w/ same code/id (he got this info from > spreadsheet that I've linked below). > > So here is my output of flashrom (I've tried both the svn version and > the one shipped with ubuntu packages w/ identical results): > http://paste.flashrom.org/view.php?id=2658 > > > The chip's datasheet should be this one: > http://www.macronix.com/Lists/Datasheet/Attachments/1587/MX25L12835F,%203V,… > On page 7 you can see the pin-out. The chip type I have has 16 (= 8x2) > pins. There are several NC labels in the pin-out therefore I didn't > connect those. > > For the rest of the connections I followed this site: > http://flashrom.org/Bus_Pirate (because I use a bus pirate w/ > hardware version 3.6 ). > The chip itself is directly attached to a pomona 5252 (SOIC-16) test clip. > > What follows are some pics of my setup + chip. > > Any hints and help would be very much appreciated because I am kind of stuck. > > Ps. Today I discovered something interesting in the spreadsheet; the > 10 (from -10g suffix) stands for 10: 104MHz . Do I need to set > spispeed to a higher level b/c of this? > > Thx again > > - - - IMAGES - - - > > Macronix MX25L12835FMI-10G chip (16 pins): http://postimg.org/image/y7ykedq6r/ > Pomona soic-16 test clip 5252 : http://postimg.org/image/gqru9oum7/ > Bus pirate hw version 3.6 : http://postimg.org/image/80a7zp0ub/ > Test clip + chip, direction (where point is): > http://postimg.org/image/koc4h655d/ > Chip attached: http://postimg.org/image/4ywrbnnst/ As discussed on IRC, this is probably caused by bad connections or not enough power supplied to the chip. The frequency stated for flash chip is a maximum and slower programmers work fine (most mainboards do not use more than ~50 MHz either). -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] FAILED: HP ChromeBook 14 (Falco)
by Stefan Tauner Aug. 18, 2014

Aug. 18, 2014

On Mon, 18 Aug 2014 19:35:18 +0200 "Maria Roth" <rothm(a)mail.com> wrote: > Hi, > > I got that while using J. Lewis script to flash an HP Chromebook 14 (Falco) (without screw). > > flashrom v0.9.4 : 14ce0cf : Oct 09 2013 22:16:28 UTC on Linux 3.15.10-200.fc20.x86_64 (x86_64), built with libpci 3.1.10, GCC 4.7.x-google 20130114 (prerelease), little endian Erasing and writing flash chip... spi_block_erase_20 failed during command execution at address 0x0 Verifying flash... VERIFY FAILED at 0x00000062! Expected=0xff, Read=0x0b, failed byte count from 0x00000000-0x007fffff: 0x4 Your flash chip is in an unknown state. Get help on IRC at irc.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with FAILED: your board name in the subject line! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! FAILED > > Can you help ? > > Thanks, > R. As discussed on IRC, and merely in the hope it might help someone in the future: if you see exactly this message (esp. the 0x4 after the range of memory addresses and the 0x0...62 after VERIFY FAILED) then you are safe. It is caused by a difference between the original flash contents and the image John Lewis is providing at his website (https://johnlewis.ie) The difference is in a copy-protected region that is not essential for the rest of the image and both versions are OK - they just can't be changed without an external programmer and that's why one gets the warning when using flashrom with the internal programmer. You have to nag John to get this fixed/changed, but it is in this form only a cosmetic nuisance. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

FAILED: HP ChromeBook 14 (Falco)
by Maria Roth Aug. 18, 2014

Aug. 18, 2014

1 0

Macronix MX25L12835FMI-10G, bus pirate and flashrom support
by Marli LI Aug. 18, 2014

Aug. 18, 2014

Hello all, I need some help to get this chip MX25L12835FMI-10G manufactured by Macronix to work w/ flashrom. I already asked for help on #flashrom IRC channel, but I was referred to ask on this mailing list. In fact, before I connected everything I asked on IRC if this chip is "already" supported, and someone from IRC did double-check it and said that the other MX25L128 chip model that IS supported is very similar and identifies itself w/ same code/id (he got this info from spreadsheet that I've linked below). So here is my output of flashrom (I've tried both the svn version and the one shipped with ubuntu packages w/ identical results): http://paste.flashrom.org/view.php?id=2658 The chip's datasheet should be this one: http://www.macronix.com/Lists/Datasheet/Attachments/1587/MX25L12835F,%203V,… On page 7 you can see the pin-out. The chip type I have has 16 (= 8x2) pins. There are several NC labels in the pin-out therefore I didn't connect those. For the rest of the connections I followed this site: http://flashrom.org/Bus_Pirate (because I use a bus pirate w/ hardware version 3.6 ). The chip itself is directly attached to a pomona 5252 (SOIC-16) test clip. What follows are some pics of my setup + chip. Any hints and help would be very much appreciated because I am kind of stuck. Ps. Today I discovered something interesting in the spreadsheet; the 10 (from -10g suffix) stands for 10: 104MHz . Do I need to set spispeed to a higher level b/c of this? Thx again - - - IMAGES - - - Macronix MX25L12835FMI-10G chip (16 pins): http://postimg.org/image/y7ykedq6r/ Pomona soic-16 test clip 5252 : http://postimg.org/image/gqru9oum7/ Bus pirate hw version 3.6 : http://postimg.org/image/80a7zp0ub/ Test clip + chip, direction (where point is): http://postimg.org/image/koc4h655d/ Chip attached: http://postimg.org/image/4ywrbnnst/

1 0

[PATCH] Bus Pirate UART speedup
by Bernie Innocenti Aug. 18, 2014

Aug. 18, 2014

I'm reposting this patch sent by Stefan Tauner in April, after rebasing it onto flashrom's svn trunk. Compared to the original, there's just one change: the original patch did set the host uart speed back to 115200 (which is a no-op). So I changed the baudrate to 2000000 (2Mbit), making the code agree with the description. I tested the patched flashrom with a Buspirate v3 running the 6.2beta firmware. While I didn't make any accurate measurements, I'd guesstimate a 10x speedup with my 8MB SPI flash. WOAH! --- original description follows ---- Increase PIC/FT232 UART speed to 2 Mbaud (instead of 115200 baud) in firmware 5.5 and newer. Given that UART speed is the biggest bottleneck for Bus Pirate communication (right now 90% of the read time is caused by slow BP<->host communication), this patch is absolutely needed to get any decent speed out of the Bus Pirate. WARNING: This patch may hang flashrom or corrupt data for any non-v3 Bus Pirate model. I haven't tested such models, and it might work without problems. Who knows. We would have to find someone with a v2 (or earlier) Bus Pirate and a firmware version >=v5.5 to test this. For Bus Pirate model v4 this patch may be completely superfluous. Anyway, activating fast UART only for some models is probably the way to go. We already have code to determine the hardware model in the init function, this just needs to be stored in some variable. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> --- buspirate_spi.c | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/buspirate_spi.c b/buspirate_spi.c index d2ebc75..57da63a 100644 --- a/buspirate_spi.c +++ b/buspirate_spi.c @@ -178,7 +178,10 @@ static int buspirate_spi_shutdown(void *data) } /* Reset Bus Pirate (return to user terminal) */ bp_commbuf[0] = 0x0f; - ret = buspirate_sendrecv(bp_commbuf, 1, 0); + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + goto out_shutdown; + if ((ret = serialport_config(sp_fd, 115200))) + goto out_shutdown; out_shutdown: /* Shut down serial port communication */ @@ -365,6 +368,45 @@ int buspirate_spi_init(void) spi_programmer_buspirate.command = buspirate_spi_send_command_v1; } + /* Increase PIC/FT232 UART speed to 2 Mbaud (instead of 115200 baud) in firmware 5.5 and newer. + * Although this is already possible in firmware 5.2, fast UART in combination with the old SPI + * command set causes hangs for bigger transactions. This is caused by a UART buffer overrun + * in the PIC, and all firmware versions up to (hopefully not including) 6.2 are affected. + */ + if (BP_FWVERSION(fw_version_major, fw_version_minor) >= BP_FWVERSION(5, 5)) { + // FIXME: Do this only for USB-based Bus Pirates... unless you're sure the UART can handle more. + int cmdlen; + /* Request setting the UART baud rate. */ + cmdlen = snprintf((char *)bp_commbuf, DEFAULT_BUFSIZE, "b\n"); + if ((ret = buspirate_sendrecv(bp_commbuf, cmdlen, 0))) + return ret; + if ((ret = buspirate_wait_for_string(bp_commbuf, ">"))) + return ret; + /* Request setting the UART clock divisor manually. */ + cmdlen = snprintf((char *)bp_commbuf, DEFAULT_BUFSIZE, "10\n"); + if ((ret = buspirate_sendrecv(bp_commbuf, cmdlen, 0))) + return ret; + if ((ret = buspirate_wait_for_string(bp_commbuf, ">"))) + return ret; + /* Set the UART clock divisor. New clock is 4000000/(divisor+1). */ + cmdlen = snprintf((char *)bp_commbuf, DEFAULT_BUFSIZE, "%i\n", 1); + if ((ret = buspirate_sendrecv(bp_commbuf, cmdlen, 0))) + return ret; + sleep(1); + if (serialport_config(sp_fd, 2000000) != 0) + return 1; + bp_commbuf[0] = ' '; + if ((ret = buspirate_sendrecv(bp_commbuf, 1, 0))) + return ret; + if ((ret = buspirate_wait_for_string(bp_commbuf, "HiZ>"))) + return ret; + msg_pdbg("Using fast 2 Mbaud for Bus Pirate <-> host communication.\n"); + } else { + msg_pinfo("Bus Pirate firmware 5.4 and older does not support fast Bus Pirate <-> host " + "communication. Limiting UART speed to 115200 Baud.\n"); + msg_pinfo("It is recommended to upgrade to firmware 6.2 or newer.\n"); + } + /* 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) { -- _ // Bernie Innocenti \X/ http://codewiz.org

1 0

Re: [flashrom] [PATCH 2/3] Refine handling chips that exceed maximum programmer sizes.
by Carl-Daniel Hailfinger Aug. 15, 2014

Aug. 15, 2014

Am 08.08.2014 16:25 schrieb Stefan Tauner: > - Change check_max_decode() to return the number of (common) busses > where the flash chip exceeds the supported size of the programmer. > - Refine its signature to use a flashctx pointer only. > - Move CLI-related bits to cli_classic.c. > - Rename check_max_decode() to count_max_decode_exceedings() to > better reflect what it (now) really does. > - Refine the messages printed by the caller to better integrate with the new > setup, and simplify them. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> I like it. One small comment below. Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> > diff --git a/flashrom.c b/flashrom.c > index eeed90b..0ff6b63 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -1079,9 +1073,6 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f > continue; > } > > - size = chip->total_size * 1024; > - check_max_decode(buses_common, size); > - > /* Start filling in the dynamic data. */ > flash->chip = calloc(1, sizeof(struct flashchip)); > if (!flash->chip) { > @@ -1091,6 +1082,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f > memcpy(flash->chip, chip, sizeof(struct flashchip)); > flash->mst = mst; > > + size = chip->total_size * 1024; At this point, it might be better to use "flash->chip->total_size * 1024" given that flash->chip is now valid (it wasn't valid at the old location). > base = flashbase ? flashbase : (0xffffffff - size + 1); > flash->virtual_memory = (chipaddr)programmer_map_flash_region("flash chip", base, size); > Regards, Carl-Daniel

2 1

[commit] r1842 - trunk
by repository service Aug. 15, 2014

Aug. 15, 2014

Author: stefanct Date: Fri Aug 15 19:17:59 2014 New Revision: 1842 URL: http://flashrom.org/trac/flashrom/changeset/1842 Log: Refine handling chips that exceed maximum programmer sizes. - Change check_max_decode() to return the number of (common) busses where the flash chip exceeds the supported size of the programmer. - Refine its signature to use a flashctx pointer only. - Move CLI-related bits to cli_classic.c. - Rename check_max_decode() to count_max_decode_exceedings() to better reflect what it (now) really does. - Refine the messages printed by the caller to better integrate with the new setup, and simplify them. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/cli_classic.c trunk/flashrom.c trunk/programmer.h Modified: trunk/cli_classic.c ============================================================================== --- trunk/cli_classic.c Sat Aug 9 01:52:33 2014 (r1841) +++ trunk/cli_classic.c Fri Aug 15 19:17:59 2014 (r1842) @@ -91,7 +91,6 @@ int main(int argc, char *argv[]) { - unsigned long size; /* Probe for up to three flash chips. */ const struct flashchip *chip = NULL; struct flashctx flashes[6] = {{0}}; @@ -501,9 +500,18 @@ print_chip_support_status(fill_flash->chip); - size = fill_flash->chip->total_size * 1024; - if (check_max_decode(fill_flash->mst->buses_supported & fill_flash->chip->bustype, size) && (!force)) { - msg_cerr("Chip is too big for this programmer (-V gives details). Use --force to override.\n"); + unsigned int limitexceeded = count_max_decode_exceedings(fill_flash); + if (limitexceeded > 0 && !force) { + enum chipbustype commonbuses = fill_flash->mst->buses_supported & fill_flash->chip->bustype; + + /* Sometimes chip and programmer have more than one bus in common, + * and the limit is not exceeded on all buses. Tell the user. */ + if ((bitcount(commonbuses) > limitexceeded)) { + msg_pdbg("There is at least one interface available which could support the size of\n" + "the selected flash chip.\n"); + } + msg_cerr("This flash chip is too big for this programmer (--verbose/-V gives details).\n" + "Use --force/-f to override at your own risk.\n"); ret = 1; goto out_shutdown; } Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Sat Aug 9 01:52:33 2014 (r1841) +++ trunk/flashrom.c Fri Aug 15 19:17:59 2014 (r1842) @@ -1009,9 +1009,13 @@ return 0; } -int check_max_decode(enum chipbustype buses, uint32_t size) +/* Returns the number of busses commonly supported by the current programmer and flash chip where the latter + * can not be completely accessed due to size/address limits of the programmer. */ +unsigned int count_max_decode_exceedings(const struct flashctx *flash) { - int limitexceeded = 0; + unsigned int limitexceeded = 0; + uint32_t size = flash->chip->total_size * 1024; + enum chipbustype buses = flash->mst->buses_supported & flash->chip->bustype; if ((buses & BUS_PARALLEL) && (max_rom_decode.parallel < size)) { limitexceeded++; @@ -1045,17 +1049,7 @@ "probe/read/erase/write may fail. ", size / 1024, max_rom_decode.spi / 1024, "SPI"); } - if (!limitexceeded) - return 0; - /* Sometimes chip and programmer have more than one bus in common, - * and the limit is not exceeded on all buses. Tell the user. - */ - if (bitcount(buses) > limitexceeded) - /* FIXME: This message is designed towards CLI users. */ - msg_pdbg("There is at least one common chip/programmer " - "interface which can support a chip of this size. " - "You can try --force at your own risk.\n"); - return 1; + return limitexceeded; } int probe_flash(struct registered_master *mst, int startchip, struct flashctx *flash, int force) @@ -1079,9 +1073,6 @@ continue; } - size = chip->total_size * 1024; - check_max_decode(buses_common, size); - /* Start filling in the dynamic data. */ flash->chip = calloc(1, sizeof(struct flashchip)); if (!flash->chip) { @@ -1091,6 +1082,7 @@ memcpy(flash->chip, chip, sizeof(struct flashchip)); flash->mst = mst; + size = flash->chip->total_size * 1024; base = flashbase ? flashbase : (0xffffffff - size + 1); flash->virtual_memory = (chipaddr)programmer_map_flash_region("flash chip", base, size); Modified: trunk/programmer.h ============================================================================== --- trunk/programmer.h Sat Aug 9 01:52:33 2014 (r1841) +++ trunk/programmer.h Fri Aug 15 19:17:59 2014 (r1842) @@ -513,7 +513,7 @@ extern struct decode_sizes max_rom_decode; extern int programmer_may_write; extern unsigned long flashbase; -int check_max_decode(enum chipbustype buses, uint32_t size); +unsigned int count_max_decode_exceedings(const struct flashctx *flash); char *extract_programmer_param(const char *param_name); /* spi.c */

1 0

Re: [flashrom] Chips requiring 12 volts on VPP for erase and write
by Stefan Tauner Aug. 14, 2014

Aug. 14, 2014

On Thu, 14 Aug 2014 16:35:16 +0200 Daniele Forsi <dforsi(a)gmail.com> wrote: > Hello, > > I have an Intel P28F001 flash memory which flashrom knows as > INTEL_28F001T and lists with .tested = TEST_OK_PR > > I can confirm that reading works with -p internal but erasing and > writing don't work because according to its datasheet it needs 12 > volts on VPP (min 11.4 max 12.6) > > should this fact about 12V VPP recorded somewhere? > > the same for the B variant (which I haven't got) Yes, definitely. flashrom does not handle that yet explicitly. Maybe there are some board enables that enable that on single boards, I dont know... but there is nothing chip-specific AFAIK. I'd suggest a new feature flag for that, what do you think Carl-Daniel? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] [PATCH 1/3] Refine Flash Component descriptor handling.
by Stefan Tauner Aug. 14, 2014

Aug. 14, 2014

On Tue, 12 Aug 2014 17:01:42 -0600 Marc Jones <marcj303(a)gmail.com> wrote: > I tested this branch on CC2: https://github.com/stefanct/flashrom/tree/intel > > See attached logs. > > > Flashrom views both chips as a single flash space. Yes, because the Intel chipsets do not allow the chip select pin to be controlled by software directly. One has to use hardware sequencing and there it does not make much sense to separate the two (although we know the boundaries and could do so), or are there use cases for that in the wild? Like using the first chip for everything but the BIOS region and the second chip for the BIOS region only...? > What is the correct > method for only updating a single descriptor area? There is only one descriptor (area), but I presume you are meaning a region. Using a layout file allows to write only a part, but there are patches that extend the usage to other actions as well. The second (i.e. write) log is more or less useless due to: "Warning: Chip content is identical to the requested image." Although it would be somewhat interesting... because the descriptor tells us that the flash chip has 256 B erase blocks, which is very improbable. Do you know which flash chips are mounted there? (The first one could be determined by forcing software sequencing via the -p internal:ich_spi_mode=swseq). I'd also like to see a -VV log (you could also use the -o <logfile> parameter ;) because with the flashrom prints more detailed information about the descriptor... and I think either the descriptor is wrong or they have changed something about the erase block sizes too... I need to verify that before committing. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

Re: [flashrom] FAILED: Adlink NanoX-TC
by Stefan Tauner Aug. 14, 2014

Aug. 14, 2014

On Thu, 14 Aug 2014 11:52:21 -0300 Ricardo Menzer <ricardomenzer(a)gmail.com> wrote: > (implicit question: is there a parameter to set SPI > frequency for the internal programmer?) Not for the Intel chipsets. But we use the lowest available frequency anyway (20 MHz), so it would probably not help you anyway. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1