flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Re: [flashrom] [PATCH 1/5] Fix FWH IDSEL message printing.
by Stefan Tauner 13 Jul '14

13 Jul '14

On Mon, 9 Jun 2014 14:41:15 +0200 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Self-acked and committed in r1826. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1826 - trunk
by repository service 13 Jul '14

13 Jul '14

Author: stefanct Date: Sun Jul 13 19:06:11 2014 New Revision: 1826 URL: http://flashrom.org/trac/flashrom/changeset/1826 Log: Fix Intel FWH IDSEL message printing. This should get rid of extra and/or missing line breaks in verbose(+) output on Intel chipsets. Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Modified: trunk/chipset_enable.c Modified: trunk/chipset_enable.c ============================================================================== --- trunk/chipset_enable.c Sun Jul 13 16:53:45 2014 (r1825) +++ trunk/chipset_enable.c Sun Jul 13 19:06:11 2014 (r1826) @@ -404,7 +404,7 @@ uint64_t fwh_idsel_old = pci_read_long(dev, fwh_sel1); fwh_idsel_old <<= 16; fwh_idsel_old |= pci_read_word(dev, fwh_sel2); - msg_pdbg("\nSetting IDSEL from 0x%012" PRIx64 " to 0x%012" PRIx64 " for top 16 MB.", + msg_pdbg("Setting IDSEL from 0x%012" PRIx64 " to 0x%012" PRIx64 " for top 16 MB.\n", fwh_idsel_old, fwh_idsel); rpci_write_long(dev, fwh_sel1, (fwh_idsel >> 16) & 0xffffffff); rpci_write_word(dev, fwh_sel2, fwh_idsel & 0xffff); @@ -418,7 +418,7 @@ free(idsel); if (!implemented) { - msg_pdbg2("FWH IDSEL handling is not implemented on this chipset."); + msg_pdbg2("FWH IDSEL handling is not implemented on this chipset.\n"); return 0; } @@ -434,7 +434,7 @@ /* FWH_SEL1 */ for (i = 7; i >= 0; i--) { int tmp = (fwh_conf >> (i * 4)) & 0xf; - msg_pdbg("\n0x%08x/0x%08x FWH IDSEL: 0x%x", + msg_pdbg("0x%08x/0x%08x FWH IDSEL: 0x%x\n", (0x1ff8 + i) * 0x80000, (0x1ff0 + i) * 0x80000, tmp); @@ -448,7 +448,7 @@ fwh_conf = pci_read_word(dev, fwh_sel2); for (i = 3; i >= 0; i--) { int tmp = (fwh_conf >> (i * 4)) & 0xf; - msg_pdbg("\n0x%08x/0x%08x FWH IDSEL: 0x%x", + msg_pdbg("0x%08x/0x%08x FWH IDSEL: 0x%x\n", (0xff4 + i) * 0x100000, (0xff0 + i) * 0x100000, tmp); @@ -465,7 +465,7 @@ fwh_conf |= pci_read_byte(dev, fwh_dec_en_lo); for (i = 7; i >= 0; i--) { int tmp = (fwh_conf >> (i + 0x8)) & 0x1; - msg_pdbg("\n0x%08x/0x%08x FWH decode %sabled", + msg_pdbg("0x%08x/0x%08x FWH decode %sabled\n", (0x1ff8 + i) * 0x80000, (0x1ff0 + i) * 0x80000, tmp ? "en" : "dis"); @@ -477,7 +477,7 @@ } for (i = 3; i >= 0; i--) { int tmp = (fwh_conf >> i) & 0x1; - msg_pdbg("\n0x%08x/0x%08x FWH decode %sabled", + msg_pdbg("0x%08x/0x%08x FWH decode %sabled\n", (0xff4 + i) * 0x100000, (0xff0 + i) * 0x100000, tmp ? "en" : "dis"); @@ -488,7 +488,7 @@ } } max_rom_decode.fwh = min(max_decode_fwh_idsel, max_decode_fwh_decode); - msg_pdbg("\nMaximum FWH chip size: 0x%x bytes", max_rom_decode.fwh); + msg_pdbg("Maximum FWH chip size: 0x%x bytes\n", max_rom_decode.fwh); return 0; }

1 0

Re: [flashrom] Help read/writing ATMEL 120 25020N SI27 A
by Stefan Tauner 13 Jul '14

13 Jul '14

On Tue, 1 Jul 2014 08:44:20 +0200 Markus Moser <mosimobile(a)googlemail.com> wrote: > Hey, > > i've just played around with your software, and so far i'm pretty excited :) > i couldn't get the GUI to compile, but the console version works fine :) > i use it on a raspberry pi but i can't read from a chip i have on hand > here... > Because i need to preserve the data on the chip, i can't test writing right > now, > but i hope you can help me though :) > > Attatched you'll find a picture of the EEPROM, and the log file - but i > doubt you can get anything useful from it, at least i couldn't :D > > I really hope you can help me with this - i struggle with this thing for > days now x) Hello Markus, looks like the chip is not responding at all. From the picture it looks like it is still soldered in another system. In that case you might have problems like those mentioned in the wiki: http://flashrom.org/ISP -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] Add support for Micronix MX29F022(N)T
by Stefan Tauner 13 Jul '14

13 Jul '14

On Fri, 4 Jul 2014 23:30:39 +0200 Daniele Forsi <dforsi(a)gmail.com> wrote: > Hello, Hello Daniele, thanks for your patch! > I successfully tested the following patch with read, erase and write > but I don't know how do I choose a value for .page_size? you don't if you dont have to, and i think it is not necessary in your case. that field will be removed in the future. i suggest that you use ".page_size = 0, /* unused */" There is only one major problem with your patch: it got mangled before sending (probably by your MUA). Can you please resend it properly? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

[commit] r1825 - trunk
by repository service 13 Jul '14

13 Jul '14

Author: stefanct Date: Sun Jul 13 16:53:45 2014 New Revision: 1825 URL: http://flashrom.org/trac/flashrom/changeset/1825 Log: Add support for Macronix MX29F022(N)B and MX29F022(N)T. The MX29F022(N)T definition was successfully tested by Daniele. Signed-off-by: Daniele Forsi <dforsi(a)gmail.com> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Modified: trunk/flashchips.c trunk/flashchips.h Modified: trunk/flashchips.c ============================================================================== --- trunk/flashchips.c Sun Jul 13 14:52:15 2014 (r1824) +++ trunk/flashchips.c Sun Jul 13 16:53:45 2014 (r1825) @@ -7036,6 +7036,70 @@ { .vendor = "Macronix", + .name = "MX29F022(N)B", + .bustype = BUS_PARALLEL, + .manufacture_id = MACRONIX_ID, + .model_id = MACRONIX_MX29F022B, + .total_size = 256, + .page_size = 0, /* unused */ + .feature_bits = FEATURE_ADDR_2AA | FEATURE_SHORT_RESET, + .tested = TEST_UNTESTED, + .probe = probe_jedec, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { + {16 * 1024, 1}, + {8 * 1024, 2}, + {32 * 1024, 1}, + {64 * 1024, 3}, + }, + .block_erase = erase_sector_jedec, + }, { + .eraseblocks = { {256 * 1024, 1} }, + .block_erase = erase_chip_block_jedec, + } + }, + .write = write_jedec_1, + .read = read_memmapped, + .voltage = {4500, 5500}, + }, + + { + .vendor = "Macronix", + .name = "MX29F022(N)T", + .bustype = BUS_PARALLEL, + .manufacture_id = MACRONIX_ID, + .model_id = MACRONIX_MX29F022T, + .total_size = 256, + .page_size = 0, /* unused */ + .feature_bits = FEATURE_ADDR_2AA | FEATURE_SHORT_RESET, + .tested = TEST_OK_PREW, + .probe = probe_jedec, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { + {64 * 1024, 3}, + {32 * 1024, 1}, + {8 * 1024, 2}, + {16 * 1024, 1}, + }, + .block_erase = erase_sector_jedec, + }, { + .eraseblocks = { {256 * 1024, 1} }, + .block_erase = erase_chip_block_jedec, + } + }, + .write = write_jedec_1, + .read = read_memmapped, + .voltage = {4500, 5500}, + }, + + { + .vendor = "Macronix", .name = "MX29F040", .bustype = BUS_PARALLEL, .manufacture_id = MACRONIX_ID, Modified: trunk/flashchips.h ============================================================================== --- trunk/flashchips.h Sun Jul 13 14:52:15 2014 (r1824) +++ trunk/flashchips.h Sun Jul 13 16:53:45 2014 (r1825) @@ -456,6 +456,7 @@ #define MACRONIX_MX29F002T 0xB0 /* Same as MX29F002NT; N has reset pin n/c. */ #define MACRONIX_MX29F004B 0x46 #define MACRONIX_MX29F004T 0x45 +#define MACRONIX_MX29F022B 0x37 /* Same as MX29F022NB */ #define MACRONIX_MX29F022T 0x36 /* Same as MX29F022NT */ #define MACRONIX_MX29F040 0xA4 /* Same as MX29F040C */ #define MACRONIX_MX29F080 0xD5

1 0

Re: [flashrom] [PATCH] Fix garbage handling in DMI strings.
by Stefan Tauner 13 Jul '14

13 Jul '14

On Fri, 11 Jul 2014 22:15:17 +0200 Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> wrote: > Previously we tried to replace garbage characters with <space> directly in > the read-only memory-mapped SMBIOS area(!). This could never have > worked for any DMI strings with garbage and results in a segfault on > machines with such strings. > > With this patch the strings are duplicated within dmi_string() already, > just before we sanitize them. Also, the limit variable used everywhere > points to the first invalid byte address. Refine respective checks > accordingly. > > Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Hi, a refined version (using isprint() instead of explicit limits) was committed in r1824. Thanks to Carl-Daniel for the review and Brian for testing the preliminary patch. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

[commit] r1824 - trunk
by repository service 13 Jul '14

13 Jul '14

Author: stefanct Date: Sun Jul 13 14:52:15 2014 New Revision: 1824 URL: http://flashrom.org/trac/flashrom/changeset/1824 Log: Fix garbage handling in DMI strings. Previously we tried to replace garbage characters with <space> directly in the read-only memory-mapped SMBIOS area(!). This could never have worked for any DMI strings with garbage and results in a segfault on machines with such strings. Thanks to Brian Rak (Supermicro X10SLE-F) and John Pohlman (HP XW9400) for reporting this issue. With this patch the strings are duplicated within dmi_string() already, just before we sanitize them. Also, the limit variable used everywhere points to the first invalid byte address. Refine respective checks accordingly. 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/dmi.c Modified: trunk/dmi.c ============================================================================== --- trunk/dmi.c Sun Jul 13 02:05:07 2014 (r1823) +++ trunk/dmi.c Sun Jul 13 14:52:15 2014 (r1824) @@ -23,6 +23,7 @@ #include <strings.h> #include <string.h> +#include <ctype.h> #include <stdio.h> #include <stdlib.h> @@ -105,7 +106,16 @@ return (sum == 0); } -static char *dmi_string(uint8_t *buf, uint8_t string_id, uint8_t *limit) +/** Retrieve a DMI string. + * + * See SMBIOS spec. section 6.1.3 "Text strings". + * The table will be unmapped ASAP, hence return a duplicated & sanitized string that needs to be freed later. + * + * \param buf the buffer to search through (usually appended directly to a DMI structure) + * \param string_id index of the string to look for + * \param limit pointer to the first byte beyond \em buf + */ +static char *dmi_string(const char *buf, uint8_t string_id, const char *limit) { size_t i, len; @@ -113,26 +123,33 @@ return "Not Specified"; while (string_id > 1 && string_id--) { - if (buf > limit) { + if (buf >= limit) { msg_perr("DMI table is broken (string portion out of bounds)!\n"); return "<OUT OF BOUNDS>"; } - buf += strnlen((char *)buf, limit - buf) + 1; + buf += strnlen(buf, limit - buf) + 1; } if (!*buf) /* as long as the current byte we're on isn't null */ return "<BAD INDEX>"; - len = strnlen((char *)buf, limit - buf); - if (len > DMI_MAX_ANSWER_LEN) - len = DMI_MAX_ANSWER_LEN; + len = strnlen(buf, limit - buf); + char *newbuf = malloc(len + 1); + if (newbuf == NULL) { + msg_perr("Out of memory!\n"); + return NULL; + } /* fix junk bytes in the string */ - for (i = 0; i < len; i++) - if (buf[i] < 32 || buf[i] >= 127) - buf[i] = ' '; + for (i = 0; i < len && buf[i] != '\0'; i++) { + if (isprint(buf[i])) + newbuf[i] = buf[i]; + else + newbuf[i] = ' '; + } + newbuf[i] = '\0'; - return (char *)buf; + return newbuf; } static void dmi_chassis_type(uint8_t code) @@ -167,7 +184,7 @@ * - uint8_t length; // data section w/ header w/o strings * - uint16_t handle; */ - while (i < num && data + 4 <= limit) { + while (i < num && data + 4 < limit) { /* - If a short entry is found (less than 4 bytes), not only it * is invalid, but we cannot reliably locate the next entry. * - If the length value indicates that this structure spreads @@ -175,15 +192,16 @@ * Better stop at this point, and let the user know his/her * table is broken. */ - if (data[1] < 4 || data + data[1] > limit) { + if (data[1] < 4 || data + data[1] >= limit) { msg_perr("DMI table is broken (bogus header)!\n"); break; } if(data[0] == 3) { - if (data + 5 <= limit) + if (data + 5 < limit) dmi_chassis_type(data[5]); - /* else the table is broken, but laptop detection is optional, hence continue. */ + else /* the table is broken, but laptop detection is optional, hence continue. */ + msg_pwarn("DMI table is broken (chassis_type out of bounds)!\n"); } else for (j = 0; j < ARRAY_SIZE(dmi_strings); j++) { uint8_t offset = dmi_strings[j].offset; @@ -192,13 +210,13 @@ if (data[0] != type) continue; - if (data[1] <= offset || data+offset > limit) { + if (data[1] <= offset || data + offset >= limit) { msg_perr("DMI table is broken (offset out of bounds)!\n"); goto out; } - /* Table will be unmapped, hence fill the struct with duplicated strings. */ - dmi_strings[j].value = strdup(dmi_string(data + data[1], data[offset], limit)); + dmi_strings[j].value = dmi_string((const char *)(data + data[1]), data[offset], + (const char *)limit); } /* Find next structure by skipping data and string sections */ data += data[1];

1 0

[PATCH] MX25U12835F
by Martin Roth 13 Jul '14

13 Jul '14

Here's a patch for supporting the MX25U12835F part Datasheet is here: http://www.macronix.com/Lists/DataSheet/Attachments/1653/MX25U12835F,%201.8… The ID was already in flashchips.h 1702 stefanct #define MACRONIX_MX25U12835E 0x2538 /* Same as MX25U12835F */ Martin

2 3

[commit] r1823 - trunk
by repository service 13 Jul '14

13 Jul '14

Author: stefanct Date: Sun Jul 13 02:05:07 2014 New Revision: 1823 URL: http://flashrom.org/trac/flashrom/changeset/1823 Log: Add support for Macronix MX25U12835F. Signed-off-by: Martin Roth <gaumless(a)gmail.com> Signed-off-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Acked-by: Stefan Tauner <stefan.tauner(a)alumni.tuwien.ac.at> Modified: trunk/flashchips.c Modified: trunk/flashchips.c ============================================================================== --- trunk/flashchips.c Tue Jun 17 00:36:17 2014 (r1822) +++ trunk/flashchips.c Sun Jul 13 02:05:07 2014 (r1823) @@ -6866,6 +6866,46 @@ { .vendor = "Macronix", + .name = "MX25U12835F", + .bustype = BUS_SPI, + .manufacture_id = MACRONIX_ID, + .model_id = MACRONIX_MX25U12835E, + .total_size = 16384, + .page_size = 256, + /* OTP: 512B total; enter 0xB1, exit 0xC1 */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI, + .tested = TEST_UNTESTED, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 4096} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 512} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 256} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + /* TODO: security register */ + .printlock = spi_prettyprint_status_register_bp3_srwd, /* bit6 is quad enable */ + .unlock = spi_disable_blockprotect_bp3_srwd, + .write = spi_chip_write_256, /* Multi I/O supported */ + .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ + .voltage = {1650, 2000}, + }, + + { + .vendor = "Macronix", .name = "MX29F001B", .bustype = BUS_PARALLEL, .manufacture_id = MACRONIX_ID,

1 0

Test result of ARM-USB-OCD-H
by Ruud Schramp 12 Jul '14

12 Jul '14

For archive purposes and recording of my email: The test result I posted on IRC. Best regards, Ruud Schramp <ruud> sudo ./flashrom -p ft2232_spi:divisor=16,type=ARM-USB-OCD-H -w test.bin flashrom v0.9.7-r1822 on Linux 3.2.0-60-generic (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found SST flash chip "SST25VF016B" (2048 kB, SPI) on ft2232_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED. [23:05] <ruud> I Noticed that ARM-USB-OCD-H is still noted as "untested". [23:05] <ruud> Now it isn't untested any more: It works! [23:08] <ruud> But please note that I used a rather high divisor. Using the default (2) resulted in the chip not being detected, the bits seemed to be shifted one position, so the ARM-USB-OCS-H seemed to read the value of the previous clock-cycle. [23:09] <ruud> It may be caused by the long wires of my breadboard.. but it seems more like a timing issue than a noise issue. [23:16] <carldani> yes, timing due to either long wires or a slow chip [23:17] <carldani> capacitance of the wires can mess with the timing a lot, e.g. by making flanks less steep and thus needing more time until a level change is reached [23:18] <carldani> and other funny business [23:18] <carldani> ruud: thanks for the report! [23:18] <carldani> ruud: would you please send the report by email to flashrom(a)flashrom.org as well? That way we have your e-mail address in case we ever need retesting for that programmer [23:19] <carldani> ruud: and please mention the problems with the default divisor in your mail, preferably also with noting the wire length (rough estimate or measurement in cm) [23:20] <ruud> Will do. [23:21] <ruud> I used a standard small breadboard (5cm x 8cm approx) [23:22] <carldani> stefanct: If I had known about this two weeks ago, I would have been able to do something about it. [23:22] <ruud> Standard olimex provided ribon cable between Olimix ARM-USB-OCD-H of about 15cm [23:22] <ruud> Wiring on the breadboard <4cm [23:23] <ruud> Power decoupled using a 100uF elco [23:23] <carldani> do you know what frequency you get with a divisor of 2? [23:24] <ruud> Power supply: 2 big 1.5 Volt batteries in series (3V) [23:24] <ruud> Unfortunately I do not have a scope or frequency counter.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom