flashrom

flashrom@flashrom.org

5 participants
9161 discussions

Re: [flashrom] [PATCH 1/1] Add support for reading the current flash contents from a file
by Paul Kocialkowski 23 Apr '16

23 Apr '16

Le mercredi 20 avril 2016 à 16:54 -0700, David Hendricks a écrit : > Looks pretty good to me. FWIW, we implemented something nearly identical in > the chromiumos branch a few years ago: https://chromium-review.googlesource.co > m/#/c/10180/ (we called it "--diff"). It's been quite useful for development, > especially when working with large chips and slow external programmers. This has been my use case as well, in particular with the kb9012 embedded controller flash. Nice to see that this use case is shared with others and that we came up with a quite similar implementation independently! > On Tue, Apr 19, 2016 at 12:25 PM, Paul Kocialkowski <contact(a)paulk.fr> wrote: > > Hi, > > > > Could we get the review moving on this patch? I first sent it over 4 months > > ago > > and got no feedback. I'd really like to have this feature merged, as I'm > > using > > it very often! > > > > Thanks > > > > Le lundi 29 février 2016 à 19:44 +0100, Paul Kocialkowski a écrit : > > > When developing software that has to be flashed to a flash chip to be > > > executed, > > > it often takes a long time to read the current flash contents (for > > flashrom to > > > know what pages to erase and reprogram) each time, when writing the new > > image. > > > However, when the flash was just reprogrammed, its current state is known > > to > > > be > > > the previous image that was flashed (assuming it was verified). > > > > > > Thus, it makes sense to provide that image as a file for the flash > > contents > > > instead of wasting valuable time read the whole flash each time. > > > > > > Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> > > > --- > > > cli_classic.c | 46 ++++++++++++++++++++++++++++------------------ > > > flash.h | 2 +- > > > flashrom.c | 14 +++++++++++--- > > > 3 files changed, 40 insertions(+), 22 deletions(-) > > > > > > diff --git a/cli_classic.c b/cli_classic.c > > > index a2c2014..dc0164d 100644 > > > --- a/cli_classic.c > > > +++ b/cli_classic.c > > > @@ -44,24 +44,25 @@ static void cli_classic_usage(const char *name) > > > "[-E|(-r|-w|-v) <file>] [-l <layoutfile> [-i <imagename>]...] > > > [-n] [-f]]\n" > > > "[-V[V[V]]] [-o <logfile>]\n\n", name); > > > > > > - printf(" -h | --help print this help text\n" > > > - " -R | --version print version > > > (release)\n" > > > - " -r | --read <file> read flash and save to > > > <file>\n" > > > - " -w | --write <file> write <file> to flash\n" > > > - " -v | --verify <file> verify flash against > > > <file>\n" > > > - " -E | --erase erase flash memory\n" > > > - " -V | --verbose more verbose output\n" > > > - " -c | --chip <chipname> probe only for specified > > > flash chip\n" > > > - " -f | --force force specific > > operations > > > (see man page)\n" > > > - " -n | --noverify don't auto-verify\n" > > > - " -l | --layout <layoutfile> read ROM layout from > > > <layoutfile>\n" > > > - " -i | --image <name> only flash image <name> > > > from flash layout\n" > > > - " -o | --output <logfile> log output to > > > <logfile>\n" > > > - " -L | --list-supported print supported > > > devices\n" > > > + printf(" -h | --help print this help > > text\n" > > > + " -R | --version print version > > > (release)\n" > > > + " -r | --read <file> read flash and save to > > > <file>\n" > > > + " -w | --write <file> write <file> to > > > flash\n" > > > + " -v | --verify <file> verify flash against > > > <file>\n" > > > + " -E | --erase erase flash memory\n" > > > + " -V | --verbose more verbose output\n" > > > + " -c | --chip <chipname> probe only for > > > specified flash chip\n" > > > + " -f | --force force specific > > > operations (see man page)\n" > > > + " -n | --noverify don't auto-verify\n" > > > + " -l | --layout <layoutfile> read ROM layout from > > > <layoutfile>\n" > > > + " -i | --image <name> only flash image > > <name> > > > from flash layout\n" > > > + " -o | --output <logfile> log output to > > > <logfile>\n" > > > + " -C | --flash-contents <contentsfile> assume flash contents > > > to be <contentsfile>\n" > > > + " -L | --list-supported print supported > > > devices\n" > > > #if CONFIG_PRINT_WIKI == 1 > > > - " -z | --list-supported-wiki print supported devices > > > in wiki syntax\n" > > > + " -z | --list-supported-wiki print supported > > devices > > > in wiki syntax\n" > > > #endif > > > - " -p | --programmer <name>[:<param>] specify the programmer > > > device. One of\n"); > > > + " -p | --programmer <name>[:<param>] specify the programmer > > > device. One of\n"); > > > list_programmers_linebreak(4, 80, 0); > > > printf(".\n\nYou can specify one of -h, -R, -L, " > > > #if CONFIG_PRINT_WIKI == 1 > > > @@ -106,7 +107,7 @@ int main(int argc, char *argv[]) > > > enum programmer prog = PROGRAMMER_INVALID; > > > int ret = 0; > > > > > > - static const char optstring[] = "r:Rw:v:nVEfc:l:i:p:Lzho:"; > > > + static const char optstring[] = "r:Rw:v:nVEfc:l:i:C:p:Lzho:"; > > > static const struct option long_options[] = { > > > {"read", 1, NULL, 'r'}, > > > {"write", 1, NULL, 'w'}, > > > @@ -118,6 +119,7 @@ int main(int argc, char *argv[]) > > > {"force", 0, NULL, 'f'}, > > > {"layout", 1, NULL, 'l'}, > > > {"image", 1, NULL, 'i'}, > > > + {"flash-contents", 1, NULL, 'C'}, > > > {"list-supported", 0, NULL, 'L'}, > > > {"list-supported-wiki", 0, NULL, 'z'}, > > > {"programmer", 1, NULL, 'p'}, > > > @@ -128,6 +130,7 @@ int main(int argc, char *argv[]) > > > }; > > > > > > char *filename = NULL; > > > + char *contentsfile = NULL; > > > char *layoutfile = NULL; > > > #ifndef STANDALONE > > > char *logfile = NULL; > > > @@ -221,6 +224,9 @@ int main(int argc, char *argv[]) > > > cli_classic_abort_usage(); > > > } > > > break; > > > + case 'C': > > > + contentsfile = strdup(optarg); > > > + break; > > > case 'L': > > > if (++operation_specified > 1) { > > > fprintf(stderr, "More than one operation " > > > @@ -332,6 +338,9 @@ int main(int argc, char *argv[]) > > > if (layoutfile && check_filename(layoutfile, "layout")) { > > > cli_classic_abort_usage(); > > > } > > > + if (contentsfile && check_filename(contentsfile, "contents")) { > > > + cli_classic_abort_usage(); > > > + } > > > > > > #ifndef STANDALONE > > > if (logfile && check_filename(logfile, "log")) > > > @@ -542,7 +551,7 @@ int main(int argc, char *argv[]) > > > * Give the chip time to settle. > > > */ > > > programmer_delay(100000); > > > - ret |= doit(fill_flash, force, filename, read_it, write_it, > > erase_it, > > > verify_it); > > > + ret |= doit(fill_flash, force, filename, contentsfile, read_it, > > > write_it, erase_it, verify_it); > > > > > > unmap_flash(fill_flash); > > > out_shutdown: > > > @@ -554,6 +563,7 @@ out: > > > layout_cleanup(); > > > free(filename); > > > free(layoutfile); > > > + free(contentsfile); > > > free(pparam); > > > /* clean up global variables */ > > > free((char *)chip_to_probe); /* Silence! Freeing is not modifying > > > contents. */ > > > diff --git a/flash.h b/flash.h > > > index dc5c140..2cf7ca6 100644 > > > --- a/flash.h > > > +++ b/flash.h > > > @@ -284,7 +284,7 @@ void print_buildinfo(void); > > > void print_banner(void); > > > void list_programmers_linebreak(int startcol, int cols, int paren); > > > int selfcheck(void); > > > -int doit(struct flashctx *flash, int force, const char *filename, int > > > read_it, int write_it, int erase_it, int verify_it); > > > +int doit(struct flashctx *flash, int force, const char *filename, const > > char > > > *contentsfile, int read_it, int write_it, int erase_it, int verify_it); > > > int read_buf_from_file(unsigned char *buf, unsigned long size, const char > > > *filename); > > > int write_buf_to_file(const unsigned char *buf, unsigned long size, const > > > char *filename); > > > > > > diff --git a/flashrom.c b/flashrom.c > > > index d5c3238..d11f89d 100644 > > > --- a/flashrom.c > > > +++ b/flashrom.c > > > @@ -1978,8 +1978,9 @@ int chip_safety_check(const struct flashctx *flash, > > int > > > force, int read_it, int > > > * but right now it allows us to split off the CLI code. > > > * Besides that, the function itself is a textbook example of abysmal > > code > > > flow. > > > */ > > > -int doit(struct flashctx *flash, int force, const char *filename, int > > > read_it, > > > - int write_it, int erase_it, int verify_it) > > > +int doit(struct flashctx *flash, int force, const char *filename, > > > + const char *contentsfile, int read_it, int write_it, int erase_it, > > > + int verify_it) > > > { > > > uint8_t *oldcontents; > > > uint8_t *newcontents; > > > @@ -2068,7 +2069,14 @@ int doit(struct flashctx *flash, int force, const > > char > > > *filename, int read_it, > > > * preserved, but in that case we might perform unneeded erase which > > > * takes time as well. > > > */ > > > - if (read_all_first) { > > > + if (contentsfile) { > > > + msg_cinfo("Reading old flash chip contents from file... "); > > > + if (read_buf_from_file(oldcontents, size, contentsfile)) { > > > + ret = 1; > > > + msg_cinfo("FAILED.\n"); > > > + goto out; > > > + } > > > + } else if (read_all_first) { > > > msg_cinfo("Reading old flash chip contents... "); > > > if (flash->chip->read(flash, oldcontents, 0, size)) { > > > ret = 1; > > > > _______________________________________________ > > flashrom mailing list > > flashrom(a)flashrom.org > > https://www.flashrom.org/mailman/listinfo/flashrom > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc.

1 0

not able to flash W25Q64.W (cherry trail Atom z8300)
by Piotr Kasprzak 23 Apr '16

23 Apr '16

my log http://pastebin.com/ZEreZnm0 <http://pastebin.com/ZEreZnm0> and i found in windows program for flashing bios this file Maybe thats help Thanks for any help. Im brick my miniPC box … i dont have picture on TV but i have still working linux there and connection over SSH - so im able to flash bios, but „flashroom” dont work yet with this chipset :( Let me know about any news ! I will be greatefull Thanks Best Regards Piotr Kasprzak ; For ME8.x and older platforms and Bay Trail platforms ; ; rev 2.7.8 ; ; These settings are not part recommendations, nor are they an indication these parts are supported on Intel platforms. ; ; All parts on this list have NOT been validated, and it is the responsibility of the customer to validate the flash parts used on their platform. ; ; Flash parts may change opcodes and architectures so please refer to the respective flash datasheet and errata/application note and flash vendor to confirm. ; ; ; ;Description of fields: ; 1) Display name ; 2) Device ID (2 or 3 bytes) ; 3) Device Size (in bits in hexadecimal (0x) notation, For example 8 Mbit = (8*1024*1024) = (8,388,608) convert to hex 0x800000 ; 16Mbit=0x1000000, 32Mbit=0x2000000, 64Mbit=0x4000000, 128Mbit=0x8000000, 256Mbit=0x10000000, 512Mbit=0x20000000 ; 4) Block Erase Size (in bytes - 256, 4K, 64K) ; 5) Block Erase Command ; 6) Write Granularity (1 or 64) ; 7) Enable Write Status Register Command (1- True, 0- False) ; 8) Chip Erase Command ; 9) Chip Erase Timeout (in milliseconds) ; ; Winbond W25X80V, 0xEF3014, 0x800000, 0x10000, 0xD8, 64, 0, 0xc7, 80000 W25X16BV, 0xEF3015, 0x1000000, 0x10000, 0xD8, 64, 0, 0xc7, 80000 W25X32BV, 0xEF3016, 0x2000000, 0x10000, 0xD8, 64, 0, 0xc7, 80000 W25X64BV, 0xEF3017, 0x4000000, 0x10000, 0xD8, 64, 0, 0xc7, 80000 W25Q40BV, 0XEF4013, 0x400000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q80BV, 0xEF4014, 0x800000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q16BV(CV), 0xEF4015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q32BV, 0xEF4016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q64BV(CV)(FV), 0xEF4017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q128BV(FV), 0xEF4018, 0x8000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q64DW, 0XEF6017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q128FW, 0xEF6018, 0x8000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 W25Q64FW, 0XEF6017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 ; Macronix MX25L1605A(D)(36E)(06E), 0xC22015, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L3205A(D)(06E), 0xC22016, 0x2000000, 0x10000, 0xD8, 64, 0, 0xC7, 80000 MX25L6405D(45E)(36E)(06E)(73E), 0xC22017, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L12805D(45E)(36E)(35E), 0xC22018, 0x8000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L8005(35E)(06E)(36E), 0xC22014, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L3225D(35D)(36D), 0xC25E16, 0x2000000, 0x10000, 0xD8, 64, 0, 0xC7, 80000 MX25L25635E(L25735E), 0xC22019, 0x10000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L1635D, 0xC22415, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L6455E, 0xC22617, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX2L12855E, 0xC22618, 0x8000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25L4006E, 0xC22013, 0x400000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25U6435F, 0xC22537, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 MX25U12835F, 0xC22538, 0x8000000, 0x1000, 0x20, 64, 0, 0x60, 80000 ; Micron/Numonyx M25PE10, 0x208011, 0x100000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PE20, 0x208012, 0x200000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PE40, 0x208013, 0x400000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PE80, 0x208014, 0x800000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PE16, 0x208015, 0x1000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PX80, 0x207114, 0x800000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PX16, 0x207115, 0x1000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PX32, 0x207116, 0x2000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 M25PX64, 0x207117, 0x4000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 N25Q16, 0x20BA15, 0x1000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 N25Q128, 0x20BA18, 0x8000000, 0x10000, 0xD8, 64, 0, 0xC7, 80000 N25Q032, 0x20BA16, 0x2000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 N25Q064, 0x20BA17, 0x4000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 ; Atmel/Adesto AT26DF081, 0x1F4500, 0x800000, 0x1000, 0x20, 1, 0, 0x60, 20000 AT25/26DF081A, 0x1F4501, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 20000 AT25DF081, 0x1F4502, 0x800000, 0x1000, 0x20, 64, 0, 0X60, 20000 AT26DF161, 0x1F4600, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 35000 AT26DF161A, 0x1F4601, 0x1000000, 0x1000, 0X20, 64, 0, 0x60, 35000 AT25DF161, 0x1F4602, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 35000 AT25DQ161, 0x1F8600, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 35000 AT25/26DF321, 0x1F4700, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 60000 AT25DF321A, 0x1F4701, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 60000 AT25DF641(A), 0x1F4800, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 120000 AT25DQ641, 0x1F8800, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 120000 ; SST/Microchip SST25VF016B, 0xBF2541, 0x1000000, 0x1000, 0x20, 1, 0, 0x60, 50 SST25VF032B, 0XBF254A, 0x2000000, 0x1000, 0x20, 1, 0, 0x60, 50 SST25VF040B, 0xBF258D, 0x400000, 0x1000, 0x20, 1, 0, 0x60, 50 SST25VF080B, 0xBF258E, 0x800000, 0x1000, 0x20, 1, 0, 0x60, 50 SST25VF064C, 0xBF254B, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 50 ; Chingis Pm25LV080B, 0x9D7F13, 0x800000, 0x1000, 0x20, 64, 0, 0xc7, 80000 Pm25LV016B, 0x9D7F14, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 Pm25LQ080, 0x7F9D44, 0x800000, 0x1000, 0x20, 64, 0, 0xC7, 80000 Pm25LQ016, 0x7F9D45, 0x1000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 Pm25LQ032, 0x7F9D46, 0x2000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 Pm25LD512C2, 0x7F9D20, 0x20000000, 0x1000, 0x20, 64, 0, 0xC7, 80000 ; EON EN25Q40, 0x1C3013, 0x400000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25F80, 0x1C3114, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25Q80A, 0x1C3014, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25F16, 0x1C3115, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25F32, 0x1C3116, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25Q32B, 0x1C3016, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25Q64, 0x1C3017, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25Q128, 0x1C3018, 0x8000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25Q16(A), 0x1C3015, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH16, 0x1C7015, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH32, 0x1C7016, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH256, 0x1C7019, 0x10000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH128, 0x1C7018, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH64, 0x1C7017, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25QH80, 0x1C7014, 0x800000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25F64, 0x1C3117, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 EN25S64, 0x1C3817, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 80000 ; AMIC A25L016, 0x373015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25L032, 0x373016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25LQ32A, 0x374016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25LQ16, 0x374015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25L040, 0x373013, 0x400000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25L080, 0x373014, 0x800000, 0x1000, 0x20, 64, 0, 0xc7, 80000 A25LQ64, 0x374017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 ; GigaDeivce GD25Q80, 0xC84014, 0x800000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25Q16, 0xC84015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25Q32, 0xC84016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25Q64, 0xC84017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25Q128, 0xC84018, 0x8000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25LQ16, 0xC86015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25LQ32C, 0xC86016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25LQ64, 0xC86017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25LQ128C, 0xC86018, 0x8000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 GD25LQ256C, 0xC86019, 0x10000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 ; Spansion S25FL016K, 0xEF4015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 S25FL032K, 0xEF4016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 S25FL064K, 0xEF4017, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 ; Fidelix FM25Q16, 0xF83215, 0x1000000, 0x1000, 0x20, 64, 0, 0x60, 50000 FM25Q32, 0xF83216, 0x2000000, 0x1000, 0x20, 64, 0, 0x60, 80000 FM25Q64, 0xF83217, 0x4000000, 0x1000, 0x20, 64, 0, 0x60, 100000 FM25Q128, 0xF83218, 0x8000000, 0x1000, 0x20, 64, 0, 0x60, 150000 ; ESMT F25L32PA(2S), 0x8C2116, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 F25L64PA, 0x8C2117, 0x4000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 F225L16PA, 0x8C2015, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 F25L04PA, 0x8C3013, 0x400000, 0x1000, 0x20, 64, 0, 0x60, 80000 F25L08PA, 0x8C3014, 0x800000, 0x1000, 0x20, 64, 0, 0xc7, 80000 F25L16PA(2S), 0x8C2115, 0x1000000, 0x1000, 0x20, 64, 0, 0xc7, 80000 F25L32PA, 0x8C2016, 0x2000000, 0x1000, 0x20, 64, 0, 0xc7, 80000

1 0

Re: [flashrom] Giving to -i option some real use
by Salvador Eduardo Tropea 22 Apr '16

22 Apr '16

Hi David! El 21/04/16 a las 18:19, David Hendricks escribió: > > > On Thu, Apr 21, 2016 at 1:41 PM, Salvador Eduardo Tropea > <salvador(a)inti.gob.ar <mailto:salvador@inti.gob.ar>> wrote: > > Hi David: > > Thanks for your comments. > > > El 20/04/16 a las 20:42, David Hendricks escribió: > > Hello Salvador, > Yes, this is a very useful feature - we've had it in the > chromiumos branch for a while now :-) > > I need to read your implementation. Ours is called > "fast-verify" which will read and only verify portions of the > flash specified with -i arguments. > > > What about writes? My problem is that I have a 4 MiB flash and > that usually need to use 32kB from it. > > > Yes, it works for writes as well. Using your layout file as an example: > 00000000:00007e2b fpga > 00007e2c:003fffff free > > If the eraseblock size is 4KB and you run /"/flashrom -p <programmer> > -l layout -i fpga -w foo.bin --fast-verify/"/, chromium's flashrom will: > 1. Detect the flash chip. > 2. Parse the -i argument > 3. Do a partial read. This is broken into a multiple steps. > 3a. Determine the "required_erase_size", for example, 4KB. Right now > the mechanism is crude and chooses the smallest block size that is > eraseable. > 3b. Align regions that are read based on required_erase_size. 0000 is > already aligned, but 7e2b will be aligned up to 7fff. > 3c. Read the aligned region content, which is 0000:7fff instead of > 0000:7e2b, into the new content buffer. > 4. Copy the new content from the "fpga" region into the new content > buffer. > 5. Erase and write 0000:7fff > 6. Verify from 0000:7fff > > Overall it looks pretty similar to what you posted. Yes. > Here's the original implementation: > https://chromium-review.googlesource.com/#/c/240176/ > <https://chromium-review.googlesource.com/#/c/240176/4>. There are a > couple of follow-up patches as well, in case you're interested. I taked a look at this. The patch have a lot in common. In my patch I use the first "usable" eraser, just like erase_and_write_flash. If this eraser fails the code will try to recover reading the whole memory. So I think this is ok. So assuming that the first "usable" eraser is a good choice I compute the alignments using *all* the eraseblocks information. My intention is to support cases like it: .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, }, }, Here the first eraser is "erase_sector_jedec", but it have really complex "block size", is not one size, but a crazy list of sizes: 16 kiB, 8 kiB, 8 kiB, 32 kiB, 64 kiB, 64 kiB, 64 kiB So I walk the list computing the beggining of each block and checking if the address is inside it. From what I see in the link above your patch uses a single size, the smallest. > > One more thing to note - Be careful about interactions with the > proposed patch to read the current contents of flash from a file: > https://www.flashrom.org/pipermail/flashrom/2015-December/014034.html. > Specifically, make sure that the aligned offsets are used for reading > old content no matter if the old content is in a flash chip or a file. Thanks. It looks compatible. Regards, SET -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

1 0

Re: [flashrom] Giving to -i option some real use
by Salvador Eduardo Tropea 21 Apr '16

21 Apr '16

Hi David: Thanks for your comments. El 20/04/16 a las 20:42, David Hendricks escribió: > Hello Salvador, > Yes, this is a very useful feature - we've had it in the chromiumos > branch for a while now :-) > > I need to read your implementation. Ours is called "fast-verify" which > will read and only verify portions of the flash specified with -i > arguments. What about writes? My problem is that I have a 4 MiB flash and that usually need to use 32kB from it. > It will also restore content surrounding regions (to address Michael's > concern) by aligning the bytes read with the erase size. So if you > wish to change a small amount of content within an eraseable block, > the entire block will be read and erased. The region specified with -i > will be written with new content, and the remaining bytes within the > block will have the old content restored. > > Here's our tree in case you'd like to take a look: > https://chromium.googlesource.com/chromiumos/third_party/flashrom/ Thanks for the link. Regards, SET > > > On Tue, Apr 19, 2016 at 10:48 AM, Salvador Eduardo Tropea > <salvador(a)inti.gob.ar <mailto:salvador@inti.gob.ar>> wrote: > > Hi All! > > Now I'm using an FPGA board with 4 MiB of flash, was using one > with 128 kiB. So now the time to read/write/verify the whole > memory is enough to annoy me ;-) > So I tried creating a layout like this: > > <-- > 00000000:00007e2b fpga > 00007e2c:003fffff free > <-- > > Note: yes only 32300 bytes used, the rest can be used for other > purposes (0,77%). > > And then I used "-i fpga". > But it didn't help ... flashrom read the 4 MiB twice (one at the > beggining and another for the verification). > Looking at the code I found a variable named read_all_first with a > comment about the lack of implementation. > So I implemented the needed code to: > 1) Add a command line option to make it 0 (avoiding the big > reads). This option can be used only when at least one image is > indicated with -i > 2) Skip the big read when read_all_first is 0. Only the regions > indicated by the user are actually fetched from the memory. > 3) Same for the verification stage. > > Additionally I added a command line option to show the progress, > very usefull for big memories (and impatient users ;-). > > Are these additions desired in the project? If yes: I want to > discuss the implementation details. If no: I'll just keep them for > my use. > > Regards, SET > > -- > Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ > INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ > Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 > Tel: (+54 11) 4724 6300 ext. 6919 > <tel:%28%2B54%2011%29%204724%206300%20ext.%206919> San Martín > - B1650KNA > FAX: (+54 11) 4754 5194 <tel:%28%2B54%2011%29%204754%205194> > Buenos Aires * Argentina > > > > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> > https://www.flashrom.org/mailman/listinfo/flashrom > > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

2 1

Re: [flashrom] unknown chip
by Idwer Vollering 21 Apr '16

21 Apr '16

Hi, I think you meant MX25U12835F. This fork of flashrom code seems to have done the work for us: https://github.com/rjarzmik/flashrom2/blob/master/src/chips/mx25u12835f.c HTH, Idwer 2016-04-19 15:34 GMT+02:00 John Bork <johnbork023(a)gmail.com>: > Hi, > > got this probe result from a MX25U12845F chip, if you want to add it to your > support list. > > BR > John Bork > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://www.flashrom.org/mailman/listinfo/flashrom

1 0

Giving to -i option some real use
by Salvador Eduardo Tropea 21 Apr '16

21 Apr '16

Hi All! Now I'm using an FPGA board with 4 MiB of flash, was using one with 128 kiB. So now the time to read/write/verify the whole memory is enough to annoy me ;-) So I tried creating a layout like this: <-- 00000000:00007e2b fpga 00007e2c:003fffff free <-- Note: yes only 32300 bytes used, the rest can be used for other purposes (0,77%). And then I used "-i fpga". But it didn't help ... flashrom read the 4 MiB twice (one at the beggining and another for the verification). Looking at the code I found a variable named read_all_first with a comment about the lack of implementation. So I implemented the needed code to: 1) Add a command line option to make it 0 (avoiding the big reads). This option can be used only when at least one image is indicated with -i 2) Skip the big read when read_all_first is 0. Only the regions indicated by the user are actually fetched from the memory. 3) Same for the verification stage. Additionally I added a command line option to show the progress, very usefull for big memories (and impatient users ;-). Are these additions desired in the project? If yes: I want to discuss the implementation details. If no: I'll just keep them for my use. Regards, SET -- Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/ INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/ Unidad Técnica Sistemas Inteligentes Av. General Paz 5445 Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

3 3

[PATCH v3 1/2] Add support for selecting the erased bit value with a flag
by Paul Kocialkowski 19 Apr '16

19 Apr '16

Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- flash.h | 5 ++++- flashrom.c | 39 +++++++++++++++++++++------------------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/flash.h b/flash.h index da049d1..dc5c140 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,9 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) + +#define ERASED_VALUE(flash) (((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff) enum test_state { OK = 0, @@ -275,7 +278,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index 25e53f2..d5c3238 100644 --- a/flashrom.c +++ b/flashrom.c @@ -696,12 +696,13 @@ int check_erased_range(struct flashctx *flash, unsigned int start, { int ret; uint8_t *cmpbuf = malloc(len); + const uint8_t erased_value = ERASED_VALUE(flash); if (!cmpbuf) { msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased_value, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -754,7 +755,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, const uint8_t erased_value) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -764,7 +765,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased_value) return 1; } return 0; @@ -784,7 +785,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value) { int result = 0; unsigned int i; @@ -799,31 +800,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased_value)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased_value); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased_value); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased_value); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased_value); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased_value); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased_value); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased_value); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1470,6 +1471,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + const uint8_t erased_value = ERASED_VALUE(flash); /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1477,7 +1479,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased_value)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) @@ -1487,7 +1489,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased_value, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1984,6 +1986,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + const uint8_t erased_value = ERASED_VALUE(flash); if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -2010,15 +2013,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased_value, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased_value, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 2.6.4

1 2

unknown chip
by John Bork 19 Apr '16

19 Apr '16

Hi, got this probe result from a MX25U12845F chip, if you want to add it to your support list. BR John Bork

1 0

Re: [flashrom] using DLP-USB1232H/MinnowboardMAX, verification error. is it due to DP_IO3L in SPI header not connected ?
by Sathish Kumar Balasubramaniam -ERS, HCL Tech 19 Apr '16

19 Apr '16

I got the problem. It's since I provided 1.8v to SPI chip VCC while the CS,SCLK,SI,SO logic levels (from DLP-USB1232H) are higher than 1.8v which also needs to be down to 1.8v to work. Regards, B.Sathish Kumar -----Original Message----- From: Sathish Kumar Balasubramaniam -ERS, HCL Tech Sent: 19 April 2016 00:59 To: flashrom(a)flashrom.org Subject: RE: using DLP-USB1232H/MinnowboardMAX, verification error. is it due to DP_IO3L in SPI header not connected ? forgot to add env info OS: Ubuntu 14.04.4 64bit flashrom version - 0.9.9 ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

1 0

Re: [flashrom] using DLP-USB1232H/MinnowboardMAX, verification error. is it due to DP_IO3L in SPI header not connected ?
by Sathish Kumar Balasubramaniam -ERS, HCL Tech 18 Apr '16

18 Apr '16

forgot to add env info OS: Ubuntu 14.04.4 64bit flashrom version - 0.9.9 ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ----------------------------------------------------------------------------------------------------------------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom