Flashrom with dediprog is selecting a sub-optimal block_erasers from the
available list.
For example, MX66L51235F in flashchips.c has 4 sizes of block erasers:
4KiB, 32KiB, 64KiB and 64MiB. 4KiB is the default, but also the slowest and
can take 20+ minutes to reprogram a chip. 32KiB and 64KiB are significantly
faster (sometimes up to 10x). 64MiB causes a fault which is a separate
issue entirely.
Currently, I manually edit flashchips.c to comment out the undesired sizes
for this chip (everything except 64KiB), but this can be tedious and not
easy to discover by others.
What would be the best solution here? Would it make sense to submit this
change for this particular chip? I understand there may also be a
speed/wear tradeoff.
I am also interested in the more general case. Do larger erase sizes tend
to reprogram a chip faster? If so, why does flashrom not always use the
larger sizes?
Thanks,
Ryan
Hi all,
the GitHub PR topic popped up from time to time on IRC in the past but
it seems we never discussed it here or came to any conclusion that led
to action.
When we switched to Git, we wrote down three ways to send patches [1]:
o Via our mailing list
o Via gerrit on coreboot.org
o Via pull request on flashrom's github mirror
Now, roughly 2 years later, some PRs have been merged, but some, even
smaller ones, were left unanswered. We also never set a clear process
how to move things to Gerrit.
While I still don't object to reviewing on Github, if somebody wants
to do so, it has some downsides: no global overview of pending patches,
no build testing before moving things to Gerrit, the overhead of moving
things, ofc (IMHO, reviewing on Github is also much harder, maybe I'm
just Gerrit spoiled).
Especially the build-test integration makes it hard for me to come up
with a reasonable process. Hence, I suggest that we just stop accepting
PRs on GitHub and tell contributors to push to Gerrit directly. This
may be more work for the contributors and might even scare some away;
but I don't see any lack of contributions to this project rather a lack
of reviewer resources. So we should make reviewing as easy as possible,
IMO.
Nico
[1] https://www.flashrom.org/Development_Guidelines#Sending_a_patch
I was unable to flash my chipset, so I am including the verbose log as an attachment as your message requested.
Joe Bill Schirtzinger
Beit Eshel President
http://www.beitesheldonate.org | (270) 681-5728
http://www.theroyalrainbow.com
Sent with [ProtonMail](https://protonmail.com) Secure Email.
# flashrom --programmer internal
flashrom v1.1 on Linux 5.3.11-arch1-1 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found chipset "AMD FP4".
Enabling flash write... FCH device found but SMBus revision 0x61 does
not match known values.
Please report this to flashrom(a)flashrom.org and include this log and
the output of lspci -nnvx, thanks!.
Could not determine chipset generation.PROBLEMS, continuing anyway
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
# lspci -nnvx > lspci.txt
I wouldalso like to report that i have found a few flash chips, that when read or attempted do perform any action on, it tells me that there are multiple chips found:
`dps@vulcan:~$ sudo flashrom --programmer ch341a_spi -r backup.bin
flashrom on Linux 5.0.0-36-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on ch341a_spi.
Found Macronix flash chip "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) on ch341a_spi.
Multiple flash chip definitions match the detected chip(s): "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E", "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F"
Please specify which chip definition to use with the -c <chipname> option`
what does this mean?
