flashrom

flashrom@flashrom.org

5 participants
9161 discussions

SST26VF032B support
by Peter Hall 10 May '16

10 May '16

Hi, I got the flashrom working on a BeagleBone programming a SST26VF032B with some modifications to 0.9.9. Do you want me to upload the modifications? I mostly copied the changes from another post, but I can't remember where that was from and I made some tweaks myself. These changes definitely work, I've test this multiple times on multiple boards. Let me know if you want the source Regards Peter Hall Software Development Manager Raster Vision Ltd. Tel: 01892 722228 / +44 1892 722228. www.rvl.co.uk <http://www.rvl.co.uk/> Raster Vision Ltd is a company registered in England and Wales, number: 02753356. Registered office: Unit 1, Crundalls, Gedges Hill, Matfield, Tonbridge, Kent, TN12 7EA, UK. C2- Restricted

1 0

Re: [flashrom] New SPI NOR Flash product Support
by Victor Lim 10 May '16

10 May '16

Thanks, David, For Gigadevice part numbers, we do keep ID, read, erase, write opcodes, sector protection, and architecture the same. I am wondering if Flashrom program needs to call out the new part numbers so that users know which part number to choose from. Regards, Victor From: David Hendricks [mailto:dhendrix@google.com] Sent: Sunday, May 8, 2016 7:43 PM To: Victor Lim <vlim(a)gigadevice.com> Cc: Hatim Kanchwala <hatim(a)hatimak.me>; flashrom <flashrom(a)flashrom.org>; Katherine (GigaDevice//US) <ksong(a)gigadevice.com> Subject: Re: [flashrom] New SPI NOR Flash product Support Hello Victor, Chips with same ID and read, erase, and write opcodes are supported. For ChromeOS platforms it is also important that new revision chips have identical block protection capabilities as the older parts (I've had difficulties with other vendors regarding this...). On Fri, May 6, 2016 at 4:55 PM, Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > wrote: Hi, Hatim, We have new revision chips that share the same ID as the previous revision, will they be considered supported because they share the same basic Erase and program command. New part # GD25LQ64C: manufacturer ID: 0x6017 Currently supported part # GD25LQ64: manufacturer ID: 0x6017 New part # GD25LQ128C: manufacturer ID: 0x6018 Currently supported part # GD25LQ128: manufacturer ID: 0x6018 Do you need new samples for verification? We do keep the same ID for new revision release, so the SW should work for new revision parts. Regards, Victor -----Original Message----- From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] Sent: Friday, March 25, 2016 1:27 PM To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ; ksong(a)gigadevice.com <mailto:ksong@gigadevice.com> Subject: Re: [flashrom] New SPI NOR Flash product Support Hello Victor, I am doing fine, thanks :) The following chips have been tested successfully - GD25D05B/10B, GD25LQ10B/20B/40B/80B, GD25Q21B/41B and GD25VQ41B (reported by David Hendrix). Test logs for the first 8 of these chips can be found here - https://www.flashrom.org/pipermail/flashrom/2016-March/014537.html. The patches for all these chips and additionally GD25Q80C/16C have been sent and are waiting for further review. I have ordered some IC clips, so I will test the remaining chips as soon as those arrive. Unfortunately, one of the chips you explicitly requested support for, GD25Q128C was not included in the samples so was not tested. But support for it has already been added ;) Apologies for the late reply. :) On Tuesday 22 March 2016 01:20 AM, Victor Lim wrote: > Hi, Hatim, > > How are you doing? Hope all the sample test results are good. > Can you please update the status so that I can ask customer to try out. > > Regards, > > Victor > > > > -----Original Message----- > From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] > Sent: Wednesday, February 24, 2016 9:02 AM > To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > > Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ; ksong(a)gigadevice.com <mailto:ksong@gigadevice.com> > Subject: Re: [flashrom] New SPI NOR Flash product Support > > Hello Victor, > > Support for two chips you requested was added some time ago in r1937 > (look here https://tracker.coreboot.org/trac/flashrom/changeset/1937). > I am waiting for samples to perform tests. FedEx was in touch > regarding documents for customs clearance, so delivery should be in a > day or two. In the meanwhile I am working on support for other > GigaDevice chips (http://www.gigadevice.com/product-series/12.html). > > On Wednesday 24 February 2016 04:47 AM, Victor Lim wrote: >> Hi, Hatim, >> >> How is the new program to include these two part #? >> I have sent the samples to you, but they are held up at the Fedex >> facility at New Delhi. >> Can you please give Fedex the instruction for delivery? >> The tracking # is 806824856677 >> >> Regards, >> >> Victor >> >> >> >> >> -----Original Message----- >> From: Victor Lim [mailto:vlim@gigadevice.com <mailto:vlim@gigadevice.com> ] >> Sent: Tuesday, February 9, 2016 3:02 PM >> To: 'Hatim Kanchwala' <hatim(a)hatimak.me <mailto:hatim@hatimak.me> > >> Cc: 'flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> ' <flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> > >> Subject: RE: [flashrom] New SPI NOR Flash product Support >> >> Thanks, Hatim, >> >> Please help me on these two part #s, datasheets are attached. >> 1) GD25VQ41B >> 2) GD25Q128C >> >> Can you provide the ship to address, I will send you same samples. >> What package type do you prefer? >> >> Regards, >> >> Victor >> >> >> >> -----Original Message----- >> From: Hatim Kanchwala [mailto:hatim@hatimak.me <mailto:hatim@hatimak.me> ] >> Sent: Tuesday, February 9, 2016 12:27 PM >> To: Victor Lim <vlim(a)gigadevice.com <mailto:vlim@gigadevice.com> > >> Cc: flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> >> Subject: Re: [flashrom] New SPI NOR Flash product Support >> >> Hello Victor, >> >> I have recently started looking at flashrom and have contributed by >> adding a few SPI flashchip definitions. I would be glad to add >> support for the SPI chips. Usually datasheets are sufficient for >> adding flashchip support (as long as datasheets convey full >> information on functionality). However, the chips remain untested. I >> would be glad to test them as well if you are willing to provide >> samples (I am at a University, so I have access to a lab with equipment for testing). >> >> On Wednesday 10 February 2016 12:18 AM, Victor Lim wrote: >>> Hi, Flashrom team, >>> >>> >>> >>> I am the FAE manager for Gigadevice and would like to know how I can >>> work >> with you to add our part # to your support list. >>> >>> A customer of mine is looking to program our GD25VQ41B with your >>> tool and >> found that it is not supported by your tools. >>> >>> It would like grateful if you can support our entire SPI NOR portfolio. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Victor Lim(Gigadevice/MK IV/FAE Manager) >>> >>> >>> >>> Gigadevice Semiconductor Inc. >>> >>> Tel: 408-855-8336 <tel:408-855-8336> >>> Mobile: 408-883-3856 <tel:408-883-3856> >>> >>> Website: www.gigadevice.com <http://www.gigadevice.com> <http://www.gigadevice.com/> >>> >>> 2975 Bowers Ave,Suite 323 >>> >>> Santa Clara, CA 95051, USA >>> >>> >>> >>> This email was sent to you by GigaDevice, A Global Innovative Memory >> Architect >>> >>> >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> --------------------------------------------------------------------- >> - >> ------ >> -- >>> >>> The information contained in this e-mail message (and any attachment >> transmitted herewith) is privileged and confidential and is intended >> for the exclusive use of the addressee(s). If you are not an intended >> addressee, any disclosure, reproduction, distribution or other >> dissemination or use of this communication is strictly prohibited. If >> you have received this communication in error, please delete this >> communication and contact us by replying to this e-mail immediately. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> flashrom mailing list >>> flashrom(a)flashrom.org <mailto:flashrom@flashrom.org> >>> http://www.flashrom.org/mailman/listinfo/flashrom >>> >> > > -- > Kind Regards, > Hatim Kanchwala > http://hatimak.me > B. Tech. Electrical Engineering > Indian Institute of Technology Patna > > -- Kind Regards, Hatim Kanchwala http://hatimak.me B. Tech. Electrical Engineering Indian Institute of Technology Patna _______________________________________________ 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.

2 1

New SPI NOR Flash product Support
by Victor Lim 09 May '16

09 May '16

Hi, Flashrom team, I am the FAE manager for Gigadevice and would like to know how I can work with you to add our part # to your support list. A customer of mine is looking to program our GD25VQ41B with your tool and found that it is not supported by your tools. It would like grateful if you can support our entire SPI NOR portfolio. Regards, Victor Lim(Gigadevice/MK IV/FAE Manager) Gigadevice Semiconductor Inc. Tel: 408-855-8336 Mobile: 408-883-3856 Website: <http://www.gigadevice.com/> www.gigadevice.com 2975 Bowers Ave,Suite 323 Santa Clara, CA 95051, USA This email was sent to you by GigaDevice, A Global Innovative Memory Architect _____ The information contained in this e-mail message (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this communication in error, please delete this communication and contact us by replying to this e-mail immediately.

4 12

Support
by Pera Peric 08 May '16

08 May '16

As instructed, I'm sending an email with verbose parameter included. The chip in question is w25q64fvsig. Also, please advise if something can be done about flashing with the descriptor locked (other than using an external programmer). Best

1 0

[PATCH 1/2] dediprog: Reimplement target chip option
by Nico Huber 07 May '16

07 May '16

Signed-off-by: Nico Huber <nico.huber(a)secunet.com> --- dediprog.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/dediprog.c b/dediprog.c index 019de46..b7276e5 100644 --- a/dediprog.c +++ b/dediprog.c @@ -942,7 +942,7 @@ int dediprog_init(void) int spispeed_idx = 1; int millivolt = 3500; long usedevice = 0; - long target = 1; + long target = FLASH_TYPE_APPLICATION_FLASH_1; int i, ret; spispeed = extract_programmer_param("spispeed"); @@ -1014,7 +1014,18 @@ int dediprog_init(void) free(target_str); return 1; } - msg_pinfo("Using target %li.\n", target); + switch (target) { + case 1: + msg_pinfo("Using target %s.\n", "FLASH_TYPE_APPLICATION_FLASH_1"); + target = FLASH_TYPE_APPLICATION_FLASH_1; + break; + case 2: + msg_pinfo("Using target %s.\n", "FLASH_TYPE_APPLICATION_FLASH_2"); + target = FLASH_TYPE_APPLICATION_FLASH_2; + break; + default: + break; + } } free(target_str); @@ -1073,7 +1084,7 @@ int dediprog_init(void) dediprog_set_leds(LED_ALL); /* Select target/socket, frequency and VCC. */ - if (set_target_flash(FLASH_TYPE_APPLICATION_FLASH_1) || + if (set_target_flash(target) || dediprog_set_spi_speed(spispeed_idx) || dediprog_set_spi_voltage(millivolt)) { dediprog_set_leds(LED_ERROR); -- 2.7.0

2 3

My current libflashrom/layout branch
by Nico Huber 04 May '16

04 May '16

Hi all, this is my current work on layout support and libflashrom. I don't have the time currently to clean it more up / respond to a review, as I will be on vacation for about three weeks. Most things are pretty clean though. So I sent it in, in case anyone wants to look at it or just play with it. One note on layout semantics: It's clear from other patches that there are different concepts of a don't-read-all option. It's either read only the flash parts that are not included (shall be kept intact) or read only those parts that are included (will be changed). I implemented the latter. It's quite useful for systems with a locked ME region.

1 14

GUI for Flashrom in Kodi
by C. Butz 01 May '16

01 May '16

Dear team, Looking for a cheap and reliable flash-programmer, I came across Flashrom and its functionality on Raspberry. In the process of playing around with this combination I discovered Kodi and wrote a GUI for Kodi to use Flashrom there. Source code and additional information can be found @ http://forum.kodi.tv/showthread.php?tid=272150 Let me know if there is any issue with licenses or anything else that requires correction! Thanks & best regards Chris Butz

1 0

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

25 Apr '16

Hi Michael: I see your point, and see it can be confusing if the interpretation is changed. What about reading the whole erase regions affected by each interval? (like David points out) I mean this: /** * Look for the starting address of the erase region that contains @addr. * The size of this region is returned in @sz */ int find_page_start(unsigned int addr, struct eraseblock *blocks, unsigned int *sz) { unsigned int page_start, i, size, count, group_size; /* Look for the beggining of the erase region containing start address */ page_start = 0; for (i = 0; i < NUM_ERASEREGIONS; i++) { size = blocks[i].size; count = blocks[i].count; group_size = size * count; if (page_start + group_size > addr) { /* The address is inside one of these erase regions */ *sz = size; return page_start + ((addr - page_start) / size) * size; } else {/* Not here */ page_start += group_size; } } msg_gerr("ERROR: address out of memory!?\n"); exit(1); return -1; } /** * Read all the erase regions containing the @start-@end interval. * Returns the last address fetched in @real_end_p */ int read_pages(struct flashctx *flash, uint8_t *oldcontents, unsigned int start, unsigned int end, unsigned int *real_end_p) { int k; unsigned int real_start, real_end, size; k = find_erase_function(flash); if (k == -1) { msg_gerr("ERROR: No erase function available.\n"); return -1; } real_start = find_page_start(start, flash->chip->block_erasers[k].eraseblocks, &size); msg_gdbg("Start of range 0x%X rounded to page boundary: 0x%X\n", start, real_start); real_end = find_page_start(end, flash->chip->block_erasers[k].eraseblocks, &size); real_end += size - 1; msg_gdbg("End of range 0x%X rounded to page boundary: 0x%X\n", end, real_end); *real_end_p = real_end; return flash->chip->read(flash, oldcontents + real_start, real_start, real_end - real_start + 1); } /** * Fill the @oldcontents buffer with data from the memory. The regions not included by the user are filled * with data from @newcontents instead of the actual memory content. It forces to skip them. * This function is used only when @oldcontents is empty. * Is also mandatory that at least one region was specified by the user. */ int read_cur_content(struct flashctx *flash, uint8_t *oldcontents, const uint8_t *newcontents) { unsigned int start = 0; romentry_t *entry; unsigned int size = flash->chip->total_size * 1024; unsigned int region_end; int ret = 0; /* We will read from memory only the regions indicated by the user. * The rest will contain the same as the newcontents */ memcpy(oldcontents, newcontents, size); /* Catch a missuse */ if (num_include_args == 0) { msg_perr("Internal error! build_old_image() invoked, but no regions specified.\n"); return 1; } /* Non-included romentries are ignored. * The union of all included romentries is fetched from memory. */ while (start < size) { entry = get_next_included_romentry(start); /* No more romentries for remaining region? */ if (!entry) break; /* For included regions, read memory content content. */ msg_gdbg("Read a chunk 0x%06x-0x%06x.\n", entry->start, entry->end); ret = read_pages(flash, oldcontents, entry->start, entry->end, &region_end); if (ret != 0) { msg_gerr("Failed to read chunk 0x%06x-0x%06x.\n", entry->start, entry->end); break; } start = region_end + 1; /* Catch overflow. */ if (!start) break; } return ret; } The find_erase_function() is in flashrom.c and is like this: /* Look for the first valid erase function. Returns -1 if none. */ int find_erase_function(struct flashctx *flash) { int k; msg_cdbg("\nLooking for an erase function.\n"); for (k = 0; k < NUM_ERASEFUNCTIONS; k++) { if (k != 0) msg_cdbg("Looking for another erase function.\n"); msg_cdbg("Trying erase function %i... ", k); if (!check_block_eraser(flash, k, 1)) { msg_cdbg("OK\n"); return k; } msg_cdbg("INVALID\n"); } msg_cdbg("No usable erase functions left.\n"); return -1; } In the case of the range I'm using I get: (with -VV) ... Reading old flash chip contents... Read a chunk 0x000000-0x007e2b. Looking for an erase function. Trying erase function 0... OK Start of range 0x0 rounded to page boundary: 0x0 End of range 0x7E2B rounded to page boundary: 0x7FFF ... In this way we know the content of the blocks that we'll erase. The values look ok, since the first eraser have 4k pages. Note: this code uses the first usable erase function, erase_and_write_flash will try the same eraser. If this eraser fails we will need more data, but in this case erase_and_write_flash reads all the memory again. Regards, SET El 20/04/16 a las 15:23, Michael Karcher escribió: > On 04/20/2016 12:07 PM, Salvador Eduardo Tropea wrote: >> /** >> * Fill the @oldcontents buffer with data from the memory. The regions >> not included by the user are filled >> * with data from @newcontents instead of the actual memory content. >> It forces to skip them. >> * This function is used only when @oldcontents is empty. >> * Is also mandatory that at least one region was specified by the user. >> */ >> >> My intention was to use the same (nasty) tricks that the code already >> uses. By forcing areas to match the rest of the code avoids touching it. > My concern is still valid. The claim "It forces to skip them" appears > wrong. If the area of the new and the old image match, the code tries to > optimize by not touching the area, but there is no guarantee that the > area is indeed untouched. If the old contents of the chip has been read, > flashrom "hides" the fact that it touched an area that did not need to > be touched by reflashing the old contents after erasing. This hiding > breaks down if flashrom doesn't know the real contents. > > Here is an example of what I mean: Assume a flash chip containing four > nibbles (used instead of bytes for presentation purposes; nibbles are > represented in hex digits); the chip contains two independently erasable > areas of two nibbles each, and I use a layout file like this (the erased > state is the nibble value F). > > 0:2 please_flash > 3:3 please_keep > > Assume the flash chip contains 0127, and the new image contains 1230. > Without -A, and selecting the image "please_flash" the following steps > are taken: > > 1) The file is loaded, newcontents is "1230". > 2) ROM contents are read. oldcontents is "0127" > 3) build_new_image/modify_new_image_from_old copies the last nibble from > oldcontents to newcontents, because it is in "please_keep", not in > "please_flash". newcontents is now "1237" > 4) The first two nibbles are erased, because the old value "01" does not > match "12". Now they are "FF" > 5) The first two nibbles are programmed to "12" > 6) The second *two* nibbles are erased because "27" does not match "37". > Now they are "FF" > 7) The second two nibbles are programmed to "37". > The flash chip now contains 1237. > > With -A, the following steps are taken: > > 1) The file is loaded, newcontents is "1230" > 2) read_cur_content loads the first three nibbles from the flash memory, > and takes the last one from newcontents. oldcontents is "0120". > 3) The first two nibbles are erased, because the old value "01" does not > match "12". Now they are "FF" > 4) The first two nibbles are programmed to "12" > 5) The second *two* nibbles are erased because "20" does not match "30". > Now they are "FF" > 6) The second two nibbles are programmed to "30". > The flash chip now contains 1230. > > As you see, the last nibble is modified to "0" instead of being kept at > "7". There might be situations in which it doesn't matter that a nibble > outside of the requested area is changed, but it definitely is different > from how we handled layout files and partial flashing up to now. Note > especially how copying the last nibble (the zero with -A, the 7 without > -A) from newcontents to oldcontents did not force the nibble to be > untouched in either case, but in the first case flashrom knew what to > write so the 7 appears to be unmodified while in fact it was erased and > rewritten. > > Regards, > Michael Karcher > -- 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 4

Results of "flashrom -V -p internal" on Dell Optiplex 9010
by Przemek Klosowski 25 Apr '16

25 Apr '16

flashrom v0.9.7-r1850 on Linux 4.3.5-300.fc23.x86_64 (x86_64) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.3.1, GCC 5.1.1 20150612 (Red Hat 5.1.1-3), little endian Command line (3 args): flashrom -V -p internal Calibrating delay loop... OS timer resolution is 1 usecs, 3871M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 997 us, 10000 myus = 9977 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. Using External DMI decoder. DMI string chassis-type: "Mini Tower" DMI string system-manufacturer: "Dell Inc." DMI string system-product-name: "OptiPlex 9010" DMI string system-version: "01" DMI string baseboard-manufacturer: "Dell Inc." DMI string baseboard-product-name: "0M9KCM" DMI string baseboard-version: "A00" Found chipset "Intel Q77" with PCI ID 8086:1e47. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x0a: BIOS Lock Enable: enabled, BIOS Write Enable: disabled Warning: Setting Bios Control at 0xdc from 0x0a to 0x09 failed. New value is 0x0a. SPIBAR = 0x00007f9404c22000 + 0x3800 0x04: 0xe009 (HSFS) HSFS: FDONE=1, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 Warning: SPI Configuration Lockdown activated. Reading OPCODES... done 0x06: 0x0004 (HSFC) HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0 0x50: 0x00000a0b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x0a, BRRA 0x0b 0x54: 0x00000000 FREG0: Warning: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x0bff0600 FREG1: BIOS region (0x00600000-0x00bfffff) is read-write. 0x5C: 0x05ff0005 FREG2: Warning: Management Engine region (0x00005000-0x005fffff) is locked. 0x60: 0x00040001 FREG3: Gigabit Ethernet region (0x00001000-0x00004fff) is read-write. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see http://flashrom.org/ME for details. Writes have been disabled for safety reasons. You can enforce write support with the ich_spi_force programmer option, but you will most likely harm your hardware! If you force flashrom you will get no support if something breaks. On a few mainboards it is possible to enable write access by setting a jumper (see its documentation or the board itself). 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xf84010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=0 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05200302 (OPMENU) 0x9C: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x00802005 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002005 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x00000800 (FPB) Enabling hardware sequencing due to multiple flash chips detected. PROBLEMS, continuing anyway The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Found 2 attached SPI flash chips with a combined density of 12288 kB. The flash address space (0x000000 - 0xbfffff) is divided at address 0x800000 in two partitions. The first partition ranges from 0x000000 to 0x7fffff. In that range are 2048 erase blocks with 4096 B each. The second partition ranges from 0x800000 to 0xbfffff. In that range are 1024 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0xff, id2 0xff, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x7f9404c258a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

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

23 Apr '16

Here is an example script that I'm using to read the flash contents to a file once and update it as I flash newer versions of the software: #!/bin/sh flashrom="flashrom" programmer="ft2232_spi:type=openmoko,divisor=8" contents="/home/paulk/embedded-freedom/Devices/G505s/kb9012/flashrom/flash-contents.img" image="$1" if [ -z $image ] then echo "Reading initial flash contents" timeb=$( date +%s ) $flashrom -p $programmer -r $contents timea=$( date +%s ) echo "Time: "$(( $timea - $timeb ))" seconds" else echo "Writing new flash contents" timeb=$( date +%s ) $flashrom -p $programmer -w $image -C $contents --noverify rc=$? timea=$( date +%s ) if [ "$rc" -eq "0" ] then echo "Copying new flash contents" cp $image $contents fi echo "Time: "$(( $timea - $timeb ))" seconds" fi

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom