The MX25R1635F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25R1635F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8702/MX25R1635F,%20Wide%20Range,%2016Mb,%20v1.6.pdf
Change-Id: I6e2b417ab177039618069d8e35132ddbfb814f03
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25R8035F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25R8035F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8749/MX25R8035F,%20Wide%20Range,%208Mb,%20v1.6.pdf
Change-Id: Iec244ffc29278c1f8c3ae47d17af2c4fe5fbe498
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81837
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Region 9 for Intel Meteor Lake; update missing regions.
* Include Region 9 as officially required for Intel Meteor Lake platform.
* Incorporate missing region names from https://github.com/coreboot/coreboot/blob/main/util/ifdtool/ifdtool.c for completeness.
Region 5: Device Expansion (DE or DevExp)
Region 9: Device Expansion 2 (DE2 or DevExp2)
Region 10: Innovation Engine (IE)
Region 11: 10 GbE 0
Region 12: 10 GbE 1
Region 15: PTT
BUG=b:319773700
TEST=Run `flashrom -VV` on MTL and see all the regions are printed out
Change-Id: I3b164ce4ae84bfd523fcd8be416c5d13183ed632
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
When html page is generated, all headers are generated as links on
the page. It is useful to have OS specific instructions as a link
to share with people.
Change-Id: I78645131b1f0acbedcf11964a204a24c45b62cff
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi
`test_build.sh` is used by Jenkins, therefore it should build
everything. Docker container for Jenkins is expected to have all
the dependencies installed, and if some of them are missing, script
should fail.
Recently we had a situation when docker image was missing sphinx
and flashrom Jenkins was silently skipping building man-pages and
documentation. This patch prevents this happening again, because
building man pages and docs will be enforced.
Change-Id: Ib89abddad27d1168cf0a621cf4bdb9f541266165
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81665
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anton Samsonov <avscomputing@gmail.com>
This commit adds two new commands to the serprog protocol which allow
more fine grained control over the SPI bus. This enables more
applications over serprog like e.g. flashing AVR microcontrollers.
This can be tried with my forks of pico-serprog:
https://github.com/funkeleinhorn/pico-serprog/tree/spimode
and avrdude:
https://github.com/funkeleinhorn/avrgirl/tree/serprog-programmer
I announced this change in flashrom and flashprog IRC channels and got
overall positive feedback in the flashprog channel. The same changes
will be sent to flashprog to prevent diverging specs.
Change-Id: Idb5a9a3710fede322def5191d68b7fba0e135292
Signed-off-by: Funkeleinhorn <git@funkeleinhorn.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81428
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25L12850F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25L12850F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8632/MX25L12850F,%203V,%20128Mb,%20v1.0.pdf
Change-Id: I71ac70d273904f94d015401f9d8df587084efad0
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81350
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Perhaps some of the users will be able to follow the instructions
and send a patch to mark chip as tested. The option to send report
to the mailing list remains available as before.
Change-Id: I36105725058f2fecb82408c369b70b3324502ece
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81266
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
By default, we busy-loop (a.k.a., "delay") for most delay values, and
only allow sleeping for large delays. But busy-looping is expensive, as
it wastes CPU cycles.
In a simple program that runs a bunch of samples of [1] over 1000
samples, I find that for 0.1 s (100000 us):
64x2 AMD CPU (CONFIG_HZ=250 / CONFIG_NO_HZ_FULL=y):
min diff: 60 us
max diff: 831 us
mean diff: 135 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=1):
min diff: 70 us
max diff: 1556 us
mean diff: 146 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=0):
min diff: 94 us
max diff: 7222 us
mean diff: 1201 us
i.e., maximum 1.5% error, typically ~0.1% error with high resolution
timers. Max 7% error, typical 1% error with low resolution timers. The
error is always in the positive direction (i.e., sleep longer than the
requested delay, not shorter than the request).
This seems reasonable.
[1] Stripped / pseudocode:
clock_gettime(CLOCK_MONOTONIC, before);
nanosleep({ .tv_nsec = usecs * 1000 }, NULL);
clock_gettime(CLOCK_MONOTONIC, after);
diff = abs((after - before) / 1000 - usecs));
Change-Id: Ifd4821c66c5564f7c975c08769a6742f645e9be0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80808
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
flashrom_init() may run through an expensive delay calibration phase,
depending on the system timer behavior (e.g., if high resolution timers
are disabled). This is wholly unnecessary if we're only going to dump
usage output or similar.
Defer the calibration until we've finished our CLI overhead.
BUG=b:325539928
TEST=`flashrom --help` with `sysctl kernel.timer_highres` == 0
Change-Id: I57949ab511df04c6922008fa8cb12467154e2c5e
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Flashrom has several magic programmer_delay() calls scattered throughout
its codebase (see cli_classic.s/main() and
flashrom.c/flashrom_image_write(), at least). These delays are
superfluous for the linux_mtd programmer, because it's an opaque
programmer in which all protocol details are handled by the kernel
driver.
Stub out the delay function, so we don't waste up to 1.1 seconds of
needless delay time, depending on the operation and CLI vs libflashrom
usage.
BUG=b:325539928
TEST=`elogtool add 0xa7` on a linux_mtd system (such as a Mediatek
Chromebook):
Time improvement - reduces from ~1.5s wall clock to about 0.4s
CPU usage: -90%, as most of the CPU cycles (before this change) are
spent in needless magic-delay busy loops
Change-Id: I3ac69d3fd7cfc689c5b32c130d044516ed846c29
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Same approach as it was before: founder and current project lead.
Change-Id: I1043b9499ab22da5ec981592d7b4311f027c4b5f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81106
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not valid to separately check the major and minor versions. The
proper minor check would be something like:
if (fmap->ver_major == FMAP_VER_MAJOR &&
fmap->ver_minor > FMAP_VER_MINOR)
ERROR();
But this code was alleged (at introduction in [1]) to have come from
cbfstool, and cbfstool doesn't bother with a minor version check. This
check is only for finding the FMAP while searching the flash; it isn't
actually here for integrity and compatibility purpose.
Drop the MINOR version check; align with cbfstool on the MAJOR version
check; and match the cbfstool comments for is_valid_fmap(), to emphasize
the lack of precision.
[1] Commit c82900b66142 ("Add support to get layout from fmap (e.g.
coreboot rom)")
BRANCH=none
BUG=b:288327526
TEST=libflashrom + ChromiumOS flashmap
Change-Id: I984835579d3b257a2462906f1f5091b179891bd0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* serprog.h doesn't exist, so refer to .c source instead
* in the doc, no other command has S_CMD_ prefix either
Change-Id: Ic83e7fd80840f2db0b006935a964721da0388068
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Match the version string for `make` builds to that of `meson` builds
from both Git- and non-Git (release or current snapshot) source trees.
Change-Id: I8694e618878823a9e96b1f2bcfa63f6c71d3c2ed
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Also add link to "How to add new doc" into a collection of
Contributors howtos.
The doc stays in root of docs, and also in the main left-side
menu on the website, so that it is very easy to discover. Everyone
who has even the slightest motivation to update the docs, should
be able to find instructions easily.
Change-Id: I882de0614ab76b8e83b0fafa67296526fecd8a16
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As of version 3.x, `sphinx-build` outputs man pages to "8" directory
instead of "man8" expected by Makefile and doc/meson.build. See:
https://github.com/sphinx-doc/sphinx/issues/7996https://github.com/sphinx-doc/sphinx/issues/9217
Current solution is to rename "8" to "man8" after documentation build.
That enables successful build and installation, as well as dependency
tracking at build-system level, but not on `sphinx-build` own level
upon which `meson` build blindly relies.
Change-Id: I9cd280551a1ba4d17edb2e857d56f80431b61e1b
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
partial_lock_test (Lock_top_quad, Lock_bottom_quad, Lock_bottom_half,
and Lock_top_half) tries to:
1. Disable HWWP
2. Lock partial
3. Enable HWWP
4. Try to write the locked partial and expect a failure
...
The 4th step only works on flashrom binary since the binary will set
FLASHROM_FLAG_VERIFY_AFTER_WRITE=1 by default and it will error out
while verifying.
But libflashrom does not set any flag beforehand, so it has
FLASHROM_FLAG_VERIFY_AFTER_WRITE=0 and thus it will think the write
command works normally and raise no error. This causes the issue that
flashrom_tester with libflashrom has been failed until today.
To solve this issue, there are two solutions:
1. Take care of the default flags in libflashrom
2. Always pass --noverify to flashrom binary and verify it afterwards.
To make both methods more consistent, I fix it with approach 1.
BUG=b:304439294
BRANCH=none
TEST=flashrom_tester internal --libflashrom Lock_top_quad
Change-Id: I7a8ac0c0984fef3cd9e73ed8d8097ddf429e54b2
Signed-off-by: roccochen@chromium.com <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79304
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For reference, link to doc about adding new chip
on the old website:
https://wiki.flashrom.org/Development_Guidelines#Adding/reviewing_a_new_flash_chip
Docs on how to update test status of flashchips never existed before.
Change-Id: I8dde689f2a0430ae10d3fa68bee727c5a9d70aec
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
The test cases from #16 onwards cover the case when layout region is
not aligned with eraseblock region, and therefore either layout start
boundary or end boundary needs to be extended to align with
eraseblock.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I726a30b0e47a966e8093ddc19abf4a65fb1d70ce
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78985
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the case when layout region is not aligned with eraseblock,
end region boundary is extended to match the eraseblock. There is
a special handling of this extended area (between original end of
region and extended one). Fix the offset of this extended area by +1
so that it covers the extended area and not the original region.
Before the patch, the last byte of the original region was failed to
write since it was treated as if an extended area, while it was the
last byte of the normal layout region.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I7f78a0090065cd2a952cba1a5d28179483ba4c55
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
datasheet: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20221129/DS-00562-GD25LQ255E-Rev1.1.pdf
BUG=b:311336475
TEST=Verified on karis
w/o this patch:
$ flashrom_tester --flashrom_binary ./flashrom internal Lock_top_quad
--> Failed
w/ this patch:
$ flashrom_tester --flashrom_binary ./flashrom internal Lock_top_quad
--> Pass
This lock_top_quad test did(copied from partial_lock_test()):
* Disable hardware WP so we can modify the protected range.
* Then enable software WP so the range is enforced and enable
hardware WP so that flashrom does not disable software WP during the
operation.
* Check that we cannot write to the protected region.
* Check that we can write to the non protected region.
Change-Id: I1425e931433c00caceaabc6037a79099d6d5eac5
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79460
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Previously, in the worst-case scenario of erasing region content then
writing new data, three rounds of verification were performed inside of
the `erase_write` function through calls to:
1. `check_erased_range` when erasing with respect to region boundaries
2. `check_erased_range` for the entire erase block after the loop
containing verification 1 completed
3. `verify_range` when all erases/writes were complete
Verification 2 duplicated verification 1 and was orphaned by commit
fa8808595a, which dropped its paired erasefn call but missed this
related step.
Verification 3 duplicated verification which occurs in
`flashrom_image_write` based on `flashctx flags`.
Now, these 2 redundant verifications are removed to improve the
performance of `erase_write`.
This change was tested using the linux_spi programmer to erase and write
to an MT25QL512 chip.
Change-Id: I638835facd9311979c4991cc4ca41a4b9e174bd5
Signed-off-by: Carly Zlabek <carlyzlabek@gmail.com>
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
After WP output format changed, the flashrom_tester will always read
software write protect is disabled.
BUG=b:300300436
TEST=Verify on flashrom_tester
Change-Id: I755891e0d8b5857650febe08c2094733cf1f4c79
Signed-off-by: Scott Chao <scott_chao@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77887
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
When working with low-voltage chips, the internal 10k pull-ups
of the Bus Pirate might be too high. In such cases, it's necessary
to create an external pull-up using lower-value resistors. For this,
you can use the 'hiz' parameter. This way, the Bus Pirate will
operate as an open drain with 'pullups=off'
So, why not just use the 'pullups=on' option for this scenario? I'm
trying to prevent a very typical human error in the training sessions
I conduct.
For example, in the previous session, a user might have left the VPU
(vextern) connected to 5V, and now they need to access a 1.8V chip.
If 'pullups=on' is used, the following will happen:
5V (VPU) --> CD4060 --> 2K (internal Bus Pirate) --> MOSI target chip.
By having the option to set a 'hiz=on', this can be avoided. Since the
pull-ups will remain deactivated while the Bus Pirate will function in
an open-drain mode
Return init error for invalid values of pullups, hiz, psus. Previously,
invalid values of the params pullups, hiz, psus were handled as "off"
(i.e. disabled). This created a potential human error when users were
running flashrom with e.g. pullups=1 and expected pullups to be on,
while the value 1 was handled as invalid and off.
Change-Id: I6d9909b23782ef3fcb1428fd127dae0d6b211855
Signed-off-by: David Reguera Garcia <dreg@rootkit.es>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
If none of "Full name" or "Display name" is set for a Gerrit account,
code reviews emails are sent from "Name of user not set" instead of
a user name. It is worth clarifying explicitly in the docs.
Change-Id: I69b6f5c1c56a2798dd156582cb5fa246b2396ab3
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79250
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Stanislav Ponomarev <me@stasponomarev.com>
CONFIG_INTERNAL depends on raw mem access resulting in the following
build failure on sh4 since version 1.3.0:
/home/thomas/autobuild/instance-3/output-1/per-package/flashrom/host/bin/../lib/gcc/sh4a-buildroot-linux-gnu/12.3.0/../../../../sh4a-buildroot-linux-gnu/bin/ld: libflashrom.a(internal.o): in function `internal_chip_readn':
internal.c:(.text+0x8): undefined reference to `mmio_readn'
Fixes the build raised by buildroot autobuilders with the following
options:
- CONFIG_FT2232_SPI=no
- CONFIG_USBBLASTER_SPI=no
- CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=yes
- CONFIG_ENABLE_LIBPCI_PROGRAMMERS=yes
Here is the target information:
C compiler found: sh4a-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.08-rc1-5515-gf1a47904b63) 12.3.0
Target arch: sh
Target OS: Linux
Target endian: little
Full build log:
- http://autobuild.buildroot.org/results/f74a9d315fb519f284428234713f43fcf4e35fd0
Change-Id: I7610f5f7cc5b114ffa90d5752155acc8b6b7c9f7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Use build system to check header presence:
* getopt.h (from include/cli_classic.h)
* pciutils/pci.h (from include/platform/pci.h)
Tested with <getopt.h> and <pci/pci.h> using GNU Make 4.1, 4.2.1, 4.4.1
and Meson 0.56.0, 1.2.1 against GCC 13.2.1 and GCC 5.5-, 7.3-compatible
(EDG 4.14-, 5.1-based) on openSuSE Tumbleweed and a custom LFS distro.
Change-Id: Ic544963ffd29626ae0a21bdddb1c78850cc43ec6
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77089
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
During the development of an esp32 serprog-compatible SPI programmer,
and implementation of the TCP over Wi-Fi for serprog,
I discovered that sp_flush_incoming() silently fails
if the underlying sp_fd descriptor is a TCP socket.
This patch adds a check for this case - tcflush returns ENOTTY,
meaning tcflush is not supported for not terminal objects,
in this case a fallback serialport_read_nonblock loop is used.
TESTED=esp32-serprog, TCP-over-WiFi mode, ~90% connection attempts fail to synchronize without patch; no synchronization issues with patch applied.
Signed-off-by: Stanislav Ponomarev <me@stasponomarev.com>
Change-Id: I9724a2fcd4a41dede2c15f83877efa6c3b0b7fae
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79112
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Q127C and Q128C are not the same. Q127C doesn't support QPI but Q128C
does. So we need to split the existing GD25Q127C/GD25Q128C into two
separated entries. We also introduce the new flashchip Q128E and merge
it into Q127C.
Datasheets:
Q128E: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00480-GD25Q128E-Rev1.2.pdf
Q127C: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00220-GD25Q127C-Rev2.3.pdf
Q128C: https://www.endrich.com/sixcms/media.php/2/GD25Q128C-Rev2.pdf
Q128E and Q127C/Q128C have compatible main functions, their differences
are:
* Q128E uses 55 nm process, while Q127C/Q128C use 65nm
* Q128E/Q127C does not support QPI
* Q128E/Q127C have OTP: 3072B, while Q128C are 1536B
* Q128E's fast read clock frequency is 133MHz, while Q127C/Q128C are
104MHZ
So we decided to merge Q128E into Q127C.
We also tested that Q128E could pass flashrom_tester while probing it as
127C/128C, so the main functionalities are compatible.
Change the chip name from GD25Q127C/GD25Q128C to two entries
GD25Q127C/GD25Q128E and GD25Q128C to make it more accurate.
Chip revision history:
- The 'GD25Q127C/GD25Q128C' definition was added in
`commit e0c7abf219b81ad049d09a4671ebc9196153d308` as 'GD25Q128C' and
later renamed to 'GD25Q127C/GD25Q128C'
BUG=b:304863141, b:293545382
BRANCH=none
TEST=flashrom_tester with flashrom binary could pass with Q128E,
which contains probe, read, write, erase, and write protect
Signed-off-by: Hsuan Ting Chen <roccochen@google.com>
Change-Id: I3300671b1cf74b3ea0469b9c5a833489ab4914f5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Other chips (at least Winbond) will benefit from this change.
Also, drop the FIXME comment, as it can be misleading. The
"pretty print" functions should only display values from the
Status Register, so using an inappropriate function might only
confuse user.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I7169a2312698343e1065cdca91a3985e00cb3804
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
The test checks that algorithm for erase functions selection
works and there are no regressions.
Specifically, test contains an array of test cases. Each case
initialises a given initial state of the memory for the mock chip,
and layout regions on the chip, and then performs erase and write
operations.
At the end of operation, test asserts the following:
- the state of mock chip memory is as expected, i.e. properly erased
or written
- erase blocks are invoked in expected order and expected number
of them
- chip operation (erase or write) returned 0.
Change-Id: I8f3fdefb76e71f6f8dc295d9dead5f38642aace7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
