Sync with upstream#15
Open
PLangowski wants to merge 653 commits into
Open
Conversation
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
Change-Id: Iecb6cf3d1f214102a243a3ffa8d0c9301263af0a Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81855 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.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>
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>
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>
MX25L12833F datasheet: https://www.macronix.com/Lists/Datasheet/Attachments/8934/MX25L12833F,%203V,%20128Mb,%20v1.0.pdf Status register: page 30 table 7 (BP0~BP3, SRWD) Configuration register: page 31 table 8 (TB) Security register: page 57 table 12 (WPSEL) MX25L12835F datasheet: https://www.macronix.com/Lists/Datasheet/Attachments/8653/MX25L12835F,%203V,%20128Mb,%20v1.6.pdf Status register: page 31(BP0~BP3, SRWD) Configuration register: page 32 table 7 (TB) Security register: page 61 table 9 (WPSEL) MX25L12845E datasheet: (no CONFIG) https://www.mxic.com.tw/Lists/Datasheet/Attachments/8693/MX25L12845E,%203V,%20128Mb,%20v1.9.pdf Status register: page 17 (BP0~BP3, SRWD) Security register: page 29 (WPSEL) MX25L12865E datasheet: (no CONFIG) https://media.digikey.com/pdf/Data%20Sheets/Macronix/MX25L6465E,_MX25L12865E.pdf Status register: page 19 (BP0~BP3, SRWD) Security register: page 31 (WPSEL) MX25L12873F datasheet: (no hardware WP) https://www.mxic.com.tw/Lists/Datasheet/Attachments/8652/MX25L12873F,%203V,%20128Mb,%20v1.2.pdf Status register: page 31(BP0~BP3, SRWD) Configuration register: page 32 table 7 (TB) Security register: page 60 table 9 (WPSEL) Splits the MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F group into three subgroups: * MX25L12833F: This chip have the configuration register and WP tested * MX25L12835F/MX25L12873F: These chips have the configuration register. * MX25L12845E/MX25L12865E: These chips don't have the configuration register. Tests the write protect functionality on the MX25L12833F chip only. BUG=b:332486637 TEST=Test flashrom --wp-disable with MX25L12833FZNI-10 on ChromeOS Change-Id: I379c833eea3ed3487504126f45c6df672a772ddc Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81792 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As proposed on the mailing list ("RFC: remove the calibrated delay
loop" [1]), this removes the calibrated delay loop and uses OS-based
timing functions for all delays because the calibrated delay loop can
delay for shorter times than intended.
When sleeping this now uses nanosleep() unconditionally, since usleep
was only used on DOS (where DJGPP lacks nanosleep). When busy-looping,
it uses clock_gettime() with CLOCK_MONOTONIC or CLOCK_REALTIME depending
on availability, and gettimeofday() otherwise.
The calibrated delay loop is retained for DOS only, because timer
resolution on DJGPP is only about 50 milliseconds. Since typical delays
in flashrom are around 10 microseconds, using OS timing there would
regress performance by around 500x. The old implementation is reused
with some branches removed based on the knowledge that timer resolution
will not be better than about 50 milliseconds.
Tested by reading and writing flash on several Intel and AMD systems:
* Lenovo P920 (Intel C620, read/verify only)
* "nissa" chromebook (Intel Alder Lake-N)
* "zork" chromebook (AMD Zen+)
[1]: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/HFH6UHPAKA4JDL4YKPSQPO72KXSSRGME/
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I7ac5450d194a475143698d65d64d8bcd2fd25e3f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81545
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
The MX25L3239E 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. MX25L3239E datasheet is available at the following URL: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8613/MX25L3239E,%203V,%2032Mb,%20v1.3.pdf Change-Id: Ic7a848028fe937deb1bf83ef2a9dddf1330334b6 Signed-off-by: DanielZhang <danielzhang@mxic.com.cn> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81563 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25L1633E 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. MX25L1633E datasheet is available at the following URL: https://www.macronix.com/Lists/Datasheet/Attachments/8617/MX25L1633E,%203V,%2016Mb,%20v1.8.pdf Change-Id: I63ee0182ad6e62b7408136285aa0e927d53f7bc8 Signed-off-by: DanielZhang <danielzhang@mxic.com.cn> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81836 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: Ie52f1e051ed215d61d5fb535e3eddeac71f64d13 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82018 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sydney <git@funkeleinhorn.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
flashrom_tester prints hints on how to modify hardware write protect
state as follows:
...
> connect the battery (and/or open the WP screw)
...
> disconnect the battery (and/or open the WP screw)
...
The first advice should be "[...] close the WP screw".
TEST=`flashrom_tester --flashrom_binary=$(which flashrom) \
internal Erase_and_Write Fail_to_verify`
Change-Id: I45f06db51e92e68bf724b13bdf5b31bba511d270
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82083
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Evan Benn <evanbenn@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I found that cross-compiling with GCC 12.2.0 targeting DJGPP from Linux
on x86_64 that meson used my system include directory
(/usr/include/x86_64-linux-gnu/) and pulled in include files that are
incompatible with DJGPP. Setting sys_root prevents meson from assuming
they're compatible between the build and host systems, fixing those
compile-time errors.
TEST=meson setup --cross-file meson_cross/i586_djgpp_dos.txt; ninja
libflashrom.h no longer causes "features.h: No such file or
directory" errors via /usr/include/x86_64-linux-gnu/sys/types.h
Change-Id: Ib9cf70f6f94782c5303fb232aaf4a46192907f66
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
If not static, this causes a compile-time error because it doesn't have a prototype. TEST=meson setup --cross-file meson_cross/i586_djgpp_dos.txt; ninja Change-Id: I1a43d89b9aabea7dab302350b1abf6bf613a3449 Signed-off-by: Peter Marheine <pmarheine@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82213 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This allows the minimum time that default_delay() will choose to sleep for instead of polling to be configured at build-time. The default remains unchanged at 100 milliseconds for now. The test's correctness has been checked by testing with minimum sleep time left at its default and set to a non-default value smaller than 100 microseconds (both pass without sleeping, verified with strace) and with the minimum sleep time set to 0 (causing the test to be skipped). The configured value from the macro needs to be stored in a const to avoid -Werror=type-limits errors when configured to be zero. Change-Id: Ida96e0816ac914ed69d6fd82ad90ebe89cdef1cc Signed-off-by: Peter Marheine <pmarheine@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: If7b06c077b34f73bc6c33f617332dfc32b982c12 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82181 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Waiting a full second is a very long time, especially when default_delay() chooses to busy-loop. This code has been around for a decade, with vague references to user reports: commit 8ab49e7 Date: Wed Aug 19 13:55:34 2009 +0000 Disallow erase/write for known bad chips so people won't try without a clear understanding Still, this logic does not belong in the high-level library logic, used by all programmers and all chips. If there is a timing issue, it should either be encoded in the appropriate programmer or flashchip timing. However, we don't really know what chips were in use, as the above commit doesn't have any links to reports. So in a feeble attempt at avoiding breaking users here, we also surmise that... * SPI chips weren't all that common in 2009; * I'm mostly motivated by flashrom performance on Chromebooks, were SPI chips (and linux_mtd / BUS_PROG) are the rule; and * SPI chips have precise timing requirements and an appropriate BUSY status. So we guess that this "calm down" magic delay wouldn't be necessary there. Thus, we allow this magic delay only on non-SPI (and non-BUG_PROG, used by linux_mtd for one) buses as a compromise. Now, this change has some (hopefully [1] tiny) chance of regression, so we have the following considerations: 1. emergency_help_message() already provides documentation on how to contact support, in case we need to handle any user-reported regressions. 2. If there is any regression here, it's only in the --verify code; so we can always provide workarounds for testing this, to determine whether this change may have been at fault. For example, something like: flashrom --write /my/new/image.bin --noverify sleep 1 flashrom --read /tmp/bar.bin cmp /my/new/image.bin /tmp/bar.bin If such problems occur, we can collect system/programmer/chip info to try to encode a more targeted delay into the appropriate chip/programmer implementation, and avoid penalizing the entire project like this. 3. We already have (embedded in erase_write()) erase verification that performs no such delay. So depending on the type of timing error that this delay was attempting to cover, we may have some proof that this delay is no longer necessary (or at least, that whatever systems were needing this delay in the first place are no longer caring about flashrom). 4. We've retained the delay for buses that were likely common in 2009 (per the above "feeble attempt"). NB: I avoid using the BUS_NONSPI macro, because I want to exclude any future buses from this workaround, even in the event that the BUS_NONSPI category grows in the future. [1] Famous last words. BUG=b:325539928 TEST=`flashrom_tester --flashrom_binary=$(which flashrom) \ internal Erase_and_Write Fail_to_verify`, TEST=`vpd -i RW_VPD -s foo=bar; vpd -i RW_VPD -l; \ vpd -i RW_VPD -d foo; vpd -i RW_VPD -l` TEST=`elogtool list; elogtool add 0xa7; elogtool list` on (at least) 2 systems: #1: Kukui/Kakadu rev2 - MTD programmer / kernel 5.10.215-24542-g0515a679eb42 / CrOS ~ 15857.0.0 #2: Zork/Dirinboz rev2 - chip name: vendor="Winbond" name="W25Q128.JW.DTR" / BIOS: Google_Dirinboz.13434.688.0 / kernel 5.4.267-21940-g67f70e251a74 / CrOS ~ 15753.43.0 Change-Id: Ie09651fede3f9f03425244c94a2da8bae00315fc Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/80807 Reviewed-by: Peter Marheine <pmarheine@chromium.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Failing to disable WP before write/erase doesn't necessarily indicate an error and flashrom doesn't treat it as such. Print a warning instead on an error. BUG=b:336220545 BRANCH=none TEST=build Change-Id: I14c3b55e387443909ca1efab2fc1901f87dd66d6 Signed-off-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82175 Reviewed-by: Hsuan-ting Chen <roccochen@google.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: Ibae0c006b293dad85a9571ec8e7081a6396bc7ce Signed-off-by: Peter Marheine <pmarheine@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82238 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure ChromeOS ebuild (ecargo_test) runs all unit tests, including those under flashrom/src/cmd.rs which were previously being skipped due to not being in the default Cargo workspace. By adding flashrom/ to the [workspace] section of Cargo.toml, these tests will now be consistently included when building and testing flashrom-tester on ChromeOS. References: * ebuild of flashrom-tester: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-apps/flashrom-tester/flashrom-tester-9999.ebuild * ecarg_test: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/eclass/cros-rust.eclass#765 BUG=b:338962302 TEST=(ChromeOS) FEATURES=`test emerge-corsola flashrom-tester` Could see tests like `cmd::tests::decode_io_opt ... ok` TEST=(UPSTREAM) 1. Build flashrom by `meson` 2. Build bindings/rust/libflashrom by `cargo build` 3. Build util/flashrom_tester by `cargo build` `cargo test --workspace` Could see tests like `cmd::tests::decode_io_opt ... ok` Change-Id: Ic23bc35592e6d7d8dd24c71630ea9a2eb2d58573 Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82231 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25R2035F 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. MX25R2035F datasheet is available at the following URL: https://www.macronix.com/Lists/Datasheet/Attachments/8696/MX25R2035F,%20Wide%20Range,%202Mb,%20v1.6.pdf Change-Id: I00e76ef942976e3e102cf71fe695c6287b392b64 Signed-off-by: DanielZhang <danielzhang@mxic.com.cn> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81839 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This allows the CH347 programmer to be used without root permissions. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com> Change-Id: Ia83fa08f6d7c2f449b1a5c0c387c6d4368b99e3a Reviewed-on: https://review.coreboot.org/c/flashrom/+/82162 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default toctree in the index file displays full tree of docs with all the nested levels, and it's too much detail. Besides, left side menu displays the tree anyway, so duplication is not needed. Supported hardware section has the deepest nesting out of all other docs. This patch changes high-level index files to only display flat list of next level subtree. On deeper level, full index is displayed. Change-Id: Ia15e9766cce6f19be1e69fbb1236a327ae3d57b3 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82196 Reviewed-by: Sydney <git@funkeleinhorn.com> Reviewed-by: Peter Marheine <pmarheine@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
memcpy() function expects 2nd parameter to be non-null. Make sure that the pointer is non-null before passing it to the function. Also move allocations under if conditions to avoid allocating memory for a potentially 0 size. Found-by: scan-build, clang v17.0.6 Signed-off-by: Alexander Goncharov <chat@joursoir.net> Change-Id: I99aad4119f9c11bea75e3419926cc833bc1f68c5 Reviewed-on: https://review.coreboot.org/c/flashrom/+/81548 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25L1636E 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. MX25L1636E datasheet is available at the following URL: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8596/MX25L1636E,%203V,%2016Mb,%20v1.3.pdf Change-Id: I415e2d6c89d3d59ba44e22753001c6f69421c39d Signed-off-by: DanielZhang <danielzhang@mxic.com.cn> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81835 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25L3273F 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. MX25L3273F datasheet is available at the following URL: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8661/MX25L3273F,%203V,%2032Mb,%20v1.2.pdf Change-Id: I4adaaa796d1db34702e7b0ed8e6fb167a3a5f6d7 Signed-off-by: DanielZhang <danielzhang@mxic.com.cn> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81562 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Mark XM25QU256C as tested for probe/read/erase/write. Found in a Clevo V560TU, tested with a CH341a programmer. Flashrom log: https://paste.flashrom.org/view.php?id=3732 Change-Id: Ia9226b71e355d2cc736af0ac4e039e8a3b73a84b Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82459 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Since Meteor Lake, configuring region access for FREG9 and higher is necessary. This configuration is determined using BIOS_BM registers: BIOS_BM_RAP (Offset 0x118): BIOS Master Read Access Permissions. Each bit [15:0] corresponds to a region [15:0]. A set bit grants BIOS master read access. BIOS_BM_WAP (Offset 0x11c): BIOS Master Write Access Permissions. Each bit [15:0] corresponds to a region [15:0]. A set bit grants BIOS master write/erase access. Move CHIPSET_METEOR_LAKE to the bottom of the ich_chipset list to ensure that all the newer chipsets in the future will use BIOS_BM check by default. BUG=b:319773700, b:304439294 BUG=b:319336080 TEST=On MTL, use flashrom -VV to see correct FREG9 access TEST=On ADL, use flashrom -VV to see not break anything TEST=On APL, use flashrom -VV to see not break anything Change-Id: I1e06e7b3d470423a6014e623826d9234fdebfbf9 Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/81357 Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com> Reviewed-by: Nikolai Artemiev <nartemiev@google.com> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I1e2039a3dcb958e96c4f1ff7b99a5629c3e83ed1 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82482 Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The B25Q64AS has been tested by ch341a programmer: read, write, erase Datasheet: https://archive.org/details/1912111437-boyamicro-by-25-q-64-assig-c-383793 Change-Id: I05ecf2b118902db974544d86e023a348912371dd Signed-off-by: Malcolm Boyes <boyesmalcolm@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82259 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Adding GD25LF128E to flashchip.c GD25LF128E: 1.8V 128Mbit, QE default fixed at 1. Datasheet link https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230627/DS-00632-GD25LF128E-Rev1.3.pdf Change-Id: I71fdc7ea1aea69d14db6af3bac2da3e7bee8abbe Signed-off-by: Victor Lim <vlim@gigadevice.com> Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/82332 Reviewed-by: Nikolai Artemiev <nartemiev@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current method modifies the optarg string and causes it to not get printed in future debug log. For example writing the log to a file with -o will show "Command line" without the size parameter of the range. Tested by logging the output and reading the log: ./flashrom -p linux_spi:dev=/dev/spidev0.0 -c "W25Q64JV-.Q" \ --wp-range 0x0,0x00001000 -o logfile && grep 'Command line' logfile Change-Id: I77acd49a5fa17a0af69b4fb1371a131a5249d3dc Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88162 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
flashrom_flash_probe marked as deprecated and existing tests are updated to use probing v2 API Change-Id: I88f78ac0c93ce99a555b42f87aa0a695089e0b3f Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88202 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Previously probe_flash had the same return code for the case when no chips were matched, and when some other error happened during probing. However these are two different scenarios and it is useful for the caller to distinguish between them. In fact, the caller (libflashrom it is) wanted to distinguish between "no chips found" and "some other probing error" from the very beginning. libflashrom probe API documented returning special error code for "other error". However it was not possible to know when "other error" happened because probe_flash never returned that back, it could only say "no matched chips found". This patch introduces -2 as "other error" code from probe_flash, while -1 remains as "no chips found". Both libflashrom probe APIs v1 and v2 are now handling "other error" from probe_flash and return it to the API callers as was promised in the documentation. This also adds a unit test for error code propagation for "no chips found" error. Change-Id: I4a271550bea2b36c657c71ce6cb1927082663c3c Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88008 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I9910cd1f5850a6f86e26bb1dc4ff26614f0a0964 Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88270 Reviewed-by: Peter Marheine <pmarheine@chromium.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: Iefe3c3b2bdd62dd6afff97dc3fddef89d60e06ba Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88280 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Building authors/reviewers list (aka Hall of Fame) requires
more modern sphinx version than the rest of documentation. Also
we have separate meson options, `documentation` and
`generate_authors_list`, which both default to `auto`.
Auto mode is expected to check the environment and enable the
option if environment is suitable - or disable otherwise.
The patch check minimun required sphinx version specifically
for building hall of fame, the rest of documentation just checks
that sphinx is present.
So if developer has old version of sphinx, all the documentation
will be built, just without hall of fame.
Without this patch, developer with generate_authors_list=auto
(which is default) and old version of sphinx gets a build error
like this:
Exception occurred:
File "/usr/lib/python3/dist-packages/docutils/nodes.py",
line 652, in __getitem__
return self.attributes[key]
KeyError: 'colwidth'
and a stack trace from sphinx source code
Change-Id: I8f0ae62f33dca04c2c5233ea45c6263f10cbe4f9
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I3d62baf6083a5ae2936ec16771e8e3a5a213181f Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88459 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
We identified somebody whose name was malformed in git history such that they were credited wrong in the hall of fame, so add some code to handle names that manage to be committed with incorrect formatting. Signed-off-by: Peter Marheine <pmarheine@chromium.org> Change-Id: I33b04932403b2d69da4648a3a7016aee57741d0d Reviewed-on: https://review.coreboot.org/c/flashrom/+/88477 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I7067f0756bd7a3e6387039cbc4290526723dc4d8 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88321 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I3561aa49ee7b3c30d40beddcd1457ca9b8e803db Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88548 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I469b1c3da3a8ed4a8a1667705a0ef9d67bdfa3de Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88550 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I741dcb6459f02903f5d6136d3095e0630fb033f2 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88557 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
I tested with an "ch341a" usb adapter. I was able to read, erase and write successfully. Datasheet: https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25QX128A(2V).pdf Change-Id: If6c5c3c37f3d817d93abdbc60c2d9280ff2585c3 Signed-off-by: Andranux <andranux+coding@posteo.de> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88327 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: Ief22cc11df9813a1e08a4f3a6805d2d6d61fd57b Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88493 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Adds support for the PUYA P25D80H flashchip. Tested: Probing RDID, reading, erasing, and writing to a single chip. Programmer: A serprog implementation that was flashed to a Raspbery Pi Pico 2. Parameters: Tested at 1Mhz OS: Raspberry Pi OS 64-bit running kernel version 6.12.38 Datasheet: https://lcsc.com/datasheet/lcsc_datasheet_2304140030_PUYA-P25D80H-SSH-IT_C559199.pdf Change-Id: I48612c369b555fb8c3f3cfe3ce0d00d3fd35a64f Signed-off-by: James Vogenthaler <james.vogenthaler@mantech.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88555 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
TEST=Flashrom is able to detect WCL SPI DID and show chipset name as below: > flashrom --flash-name .... Found chipset "Intel Wildcat Lake". .... > flashrom -p internal --ifd -i fd -i bios -r /tmp/bios.rom .... Found chipset "Intel Wildcat Lake". Reading ich_descriptor... done. Using regions: "bios", "fd". Reading flash... done. SUCCESS Change-Id: Iaf1dc346b215c53cd2a0f6cf6e2cf4a8e6b5c19c Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88048 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
TEST=ich_descriptors_tool is able to detect "wildcat" chipset and show
below information:
> ./util/ich_descriptors_tool/ich_descriptors_tool
Need the file name of a descriptor image to read from.
usage: './util/ich_descriptors_tool/ich_descriptors_tool -f
<image file name> [-c <chipset name>] [-d]'
...
...
To also print the data stored in the descriptor straps you have to
indicate the chipset series with the '-c' parameter and one of the
possible arguments:
- "ich8",
- "ich9",
- "ich10",
- "apollo" for Intel's Apollo Lake SoC.
- "gemini" for Intel's Gemini Lake SoC.
- "jasper" for Intel's Jasper Lake SoC.
- "meteor" for Intel's Meteor Lake SoC.
- "panther" for Intel's Panther Lake SoC.
- "wildcat" for Intel's Wildcat Lake SoC.
...
...
- "300" or "cannon" for Intel's 300 series chipsets.
- "400" or "comet" for Intel's 400 series chipsets.
- "500" or "tiger" for Intel's 500 series chipsets.
- "600" or "alder" for Intel's 600 series chipsets.
Change-Id: I2957eab19d8b8fdd2479f7d1b50ecdb48f491954
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88049
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The main purpose is to run one operation after the other to check that data is carried in flash context correctly. As the most common chains, the first tests perform: probe+read probe+write probe+erase Change-Id: I9b09e04c7dbee7e7658118d66aacb640885f4d23 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88257 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: Id5c254f011fac2ded919c2d86dc443b36b104527 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88647 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The last argument in `prepare_flash_access` function indicates whether verify operation was requested. This information is in the flag `verify_after_write` in flash context, so lets pass it to the function. Previously, the last argument which is called `verify_it` was always `false`. This hasn't been detected because in the current implementation of `prepare_flash_access`, `verify_it` is always checked together with `erase_it`, the latter was passed always true. `verify_it` being false is wrong because we have a flag to decide about verification. Also this false value contradicts reality, because erase operation ignores the flag and always verifies (this has always been the case even with earlier implementations of erase logic). Additional context is in the next commit and ticket https://ticket.coreboot.org/issues/520 Change-Id: Idd7526084e4942b7adbbab57a62f7de84b4a4bb5 Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88733 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This commit adds check for the flag `verify_after_write` after erase operation and does not perfom verification if the flag disabled. From command line, this is set by --noverify option. libflashrom flag is FLASHROM_FLAG_VERIFY_AFTER_WRITE Default stays the same, by default verification is performed. This commit also adds test for the scenario. Previously, erase operation ignored --noverify option and always performed verification. For more details, see Ticket: https://ticket.coreboot.org/issues/520 Change-Id: I9f6cb7210f4dcdc32870f9096657a08b12e77c7f Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88734 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Carly Zlabek <carlyzlabek@gmail.com> Reviewed-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-by: Vincent Fazio <vfazio@gmail.com>
To get a fast and easy feedback on how parameters affect runtime (e.g. clock setting, polling delays, etc). The runtime is measured starting from programmer_init and to programmer_shutdown, inclusive. Message is displayed in debug verbosity level. Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de> Change-Id: I2238b3f3e6c2ab7745994662a88787fa2e86d480 Co-Developed-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/47805 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Big endian architectures don't use the function. This fixes a FTBFS on big endian architectures. Change-Id: Ied3e12352e7fde73355f6a8a226eea0e5b101721 Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88817 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To make it clearer what a #endif matches add a comment. Change-Id: Ie3a251a85f03e4ff6babd71d5df9c6725c187265 Suggested-by: Anastasia Klimchuk <aklm@flashrom.org> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88859 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Some tools, such as Buildroot, will use packed tarballs of cloned git repositories and trigger builds for the sources. This results in flashrom grabbing incorrect git information. The best option is to solely rely on the VERSION file. Change-Id: Iac60ae253263eab42361b0f73a9c9c95cd547eb5 Signed-off-by: Jacob Rothbauer <rothbauerj@hotmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88967 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Vincent Fazio <vfazio@gmail.com> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested via linux_spi [0]. [0]: https://paste.flashrom.org/view.php?id=3774 Change-Id: Ida2ba300adf18280da325c1cf94a2df32f9163c6 Tested-by: Jacob Zarnstorff <jzarnstorff@xes-inc.com> Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88985 Reviewed-by: Anastasia Klimchuk <aklm@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested via linux_spi [0]. [0]: https://paste.flashrom.org/view.php?id=3775 Change-Id: Ied3439b95104e37b7d22547ded883870eb2ab500 Tested-by: Jacob Zarnstorff <jzarnstorff@xes-inc.com> Signed-off-by: Vincent Fazio <vfazio@xes-inc.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88984 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: Ie7ad3e6acaf7fcac93b7542f3b3d65e072858802 Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/88861 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: Iedd0b91ca800373460c35de69427ea4056e6e8b9 Signed-off-by: Michał Iwanicki <michal.iwanicki@3mdeb.com>
|
Merged current upstream/main |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.