April 2016 - flashrom - mail.coreboot.org

80/100/132 column line width policy
by Carl-Daniel Hailfinger Dec. 15, 2018

Dec. 15, 2018

Hi, we're hitting the 80 column limit in our code in ways which actually reduce readability for the code. Examples are various multiline messages and complicated nested code where refactoring to a separate function doesn't make sense. Keeping the old 80 column limit is not really an option anymore. Standard terminal sizes have one of 80, 100 or 132 columns. Given the monitor resolutions many people have nowadays, I think it is safe to say that you can fit two xterms with 100 columns horizonally next to each other. 100 columns should also be sufficient for a msg_p* of roughly 80 columns of text. 132 columns provide more leeway, but IMHO that would be too wide for good readability (and my screen can't fit two xterms side-by-side anymore). Of course some files have sections where any column limit is not acceptable (board lists etc.), but the column limit violations should be limited to the affected file sections, not whole files. Comments? I'd like to get this decided today or tomorrow so we know where we need line breaks in Stefan Tauner's new struct flashchip patch. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 9

Spansion S25FL128P......X
by The Raven April 24, 2017

April 24, 2017

I have a spansion S25FL128P......X chip and can do some tests. The "problem" is that i don't know if its an 0 or an 1. On the chip i see only "FL128PIF" and one line lower i see "00299012 C". Probing works (id1 0x01, id2 0x2018): Calibrating delay loop... OK. serprog: Programmer name is "serprog-duino" Found Spansion flash chip "S25FL128P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128P......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......1" (16384 kB, SPI) on serprog. Multiple flash chip definitions match the detected chip(s): "S25FL128P......0", "S25FL128P......1", "S25FL128S......0", "S25FL128S......1", "S25FL129P......0", "S25FL129P......1" Please specify which chip definition to use with the -c <chipname> option. BTW: Chip was fund on a Dell-Systemboard.

3 6

New SPI NOR Flash product Support
by Victor Lim May 9, 2016

May 9, 2016

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

Re: [flashrom] Giving to -i option some real use
by Salvador Eduardo Tropea April 25, 2016

April 25, 2016

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 April 25, 2016

April 25, 2016

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 April 23, 2016

April 23, 2016

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

Re: [flashrom] [PATCH 1/1] Add support for reading the current flash contents from a file
by Paul Kocialkowski April 23, 2016

April 23, 2016

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 April 23, 2016

April 23, 2016

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 April 21, 2016

April 21, 2016

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 April 21, 2016

April 21, 2016

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