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 …
[View More]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/
[View Less]
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" (…
[View More]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.
[View Less]
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.…
[View More]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.
[View Less]
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 …
[View More]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,
®ion_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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]))" 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
[View Less]
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 :…
[View More]-)
>
> 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
[View Less]
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 …
[View More]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
[View Less]