Anastasia Klimchuk has submitted this change. ( https://review.coreboot.org/c/flashrom/+/85156?usp=email )
Change subject: doc: Release notes for v1.5.0 ......................................................................
doc: Release notes for v1.5.0
Change-Id: I0663779020e84cd6d89d33f23a7b5514f8efa2f4 Signed-off-by: Anastasia Klimchuk aklm@flashrom.org Reviewed-on: https://review.coreboot.org/c/flashrom/+/85156 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Peter Marheine pmarheine@chromium.org --- M doc/release_notes/devel.rst M doc/release_notes/index.rst A doc/release_notes/v_1_5.rst 3 files changed, 240 insertions(+), 186 deletions(-)
Approvals: build bot (Jenkins): Verified Peter Marheine: Looks good to me, approved
diff --git a/doc/release_notes/devel.rst b/doc/release_notes/devel.rst index 7b21a99..bb2b73d 100644 --- a/doc/release_notes/devel.rst +++ b/doc/release_notes/devel.rst @@ -16,189 +16,3 @@ not currently supported.
https://ticket.coreboot.org/issues/370 - -Build only supported with Meson -=============================== - -As documented in the :doc:`v1.4 release notes <v_1_4>`, support for building -flashrom with make has been removed; all Makefiles have been deleted. Meson is -now the only supported tool for building flashrom from source. - -New Feature -=========== - -Libpci 3.13.0 and onwards support ECAM to access pci registers. Flashrom will -be moved to ECAM from IO port 0xcf8/0xcfc if the libpci version is >= 3.13.0. -The ECAM has been supported for a very long time, most platforms should support -it. For those platforms don't support ECAM, libpci will terminate the process by -exit. - -Progress display -================ - -Progress display feature is now working for all operations: read, erase, write. - -Command-line option to sacrifice unchanged blocks for speed -=========================================================== - -New command line option ``sacrifice-ratio`` handles the following situation: - -There is a region which is requested to be erased (or written, because -the write operation uses erase too). Some of the areas inside this -region don't need to be erased, because the bytes already have expected -value. Such areas can be skipped. - -The logic selects eraseblocks that can cover the areas which need to be -erased. Suppose there is a region which is partially covered by -eraseblocks of size S (partially because remaining areas don't need to -be erased). Now suppose we can cover the whole region with eraseblock -of larger size, S+1, and erase it all at once. This will run faster: -erase opcode will only be sent once instead of many smaller opcodes. -However, this will run erase over some areas of the chip memory that -didn't need to be erased. Which means the physical chip will wear out -faster. - -This new option sets the maximum % of memory that is allowed for -redundant erase. Default is 0, S+1 size block only selected if all the -area needs to be erased in full. 50 means that if more than a half of -the area needs to be erased, a S+1 size block can be selected to cover -the entire area with one block. - -The tradeoff is the speed of programming operation VS the longevity of -the chip. Default is longevity. - -RPMC support added -================== - -Adding support for RPMC commands as specified by JESD260 to the cli_client. Main -implementation is in rpmc.c. Also adds new parsing capabilities for the sfdp -page carrying the necessary information. All the features are optional and -depend on libcrypto. -It currently uses automatic feature detection through the corresponding -sfdp page. - -Programmer updates -=================== - -* ch347_spi: Add spi clock frequency selection ("spispeed" option) -* dummyflasher: Enable higher frequency emulation, add docs and tests -* ichspi: Change the opcode position for reprogramming on the fly 2->4 -* ichspi: Merge spi_master implementations for Intel ich - -Bugs fixed -========== - -* Modified bytes would sometimes not be verified after writing - - In some situations an off-by-one error would cause the last byte - of memory that was modified by an operation to not be verified. - This could prevent some erase or write errors from being detected, - or in other cases could make verification appear false-negative. - - Fixed by https://review.coreboot.org/c/flashrom/+/84078. - -* Possible crashes while preparing erase operations - - An out-of-bounds memory read was found in the algorithm that selects methods - to erase memory, which could cause flashrom to crash. This issue was first - introduced in release 1.4, and crashes were observed when running on OpenBSD. - - See https://ticket.coreboot.org/issues/555, and fixed by - https://review.coreboot.org/c/flashrom/+/84234. - -* Crash when attempting to erase FEATURE_NO_ERASE chips - - When attempting to erase a chip that doesn't need to be erased before - being written, flashrom could attempt to read through a null pointer - and crash. The only supported chip that is affected is the M95M02 - EEPROM. - - See https://ticket.coreboot.org/issues/553, and fixed by - https://review.coreboot.org/c/flashrom/+/84203. - -* install failures related to libcmocka - - In some configurations, the install target provided by the buildsystem (like - meson install) would fail to execute successfully due to a missing libcmocka - file. This is fixed by not installing libcmocka, because it is a third-party - library used by flashrom only for testing. - - See https://ticket.coreboot.org/issues/561, and fixed by - https://review.coreboot.org/c/flashrom/+/84557. - -* Excess erase of automatically-probed chips on Intel chipsets - - When erasing some chips using the ichspi programmer (for Intel ICH chipsets), - the entire chip would be erased and rewritten even when the hardware supported - erasing smaller blocks, causing operations to take longer to complete and - negatively impacting chip longevity. This issue was first introduced in version - 1.4. - - See https://ticket.coreboot.org/issues/556, and fixed by - https://review.coreboot.org/c/flashrom/+/84253. - -* Unnecessary erases - - When erasing parts of a memory, some blocks could be erased and rewritten - unnecessarily or erased multiple times which could hurt the longevity of - the memory chip. This behavior was introduced in version 1.4. - - Fixed by https://review.coreboot.org/c/flashrom/+/84614 and - https://review.coreboot.org/c/flashrom/+/84686. - -Chipset support -=============== - -Added Raptor Point PCH support. - -Chip model support added -======================== - -* FM25Q04 -* FM25Q64 -* FM25Q128 - -* GD25B128E -* GD25B256E -* GD25B512MF -* GD25F64F -* GD25F256F -* GD25R128E -* GD25R256E -* GD25R512MF -* GD25LB256F -* GD25LB512ME -* GD25LB512MF -* GD25LR256F -* GD25LR512MF -* GD25LF256F -* GD25LF512MF - -* MX25U25645G -* MX77U51250F - -* W25Q32JV_M - -* XM25LU64C -* XM25QH32C -* XM25QH32D -* XM25QH64D -* XM25QH128D -* XM25QH256D -* XM25QH512C -* XM25QH512D -* XM25QU16C -* XM25QU32C -* XM25QU128D -* XM25QU256D -* XM25QU512C -* XM25QU512D - -Misc -========= - -* reduce DELAY_MINIMUM_SLEEP_US to 100 by default -* tests: Add assert for eraseblocks order of invocations for write op -* VERSION: Change name pattern to match tag name from now on -* writeprotect: Fix inaccurate return code -* erasure_layout: Fix unreachable error message diff --git a/doc/release_notes/index.rst b/doc/release_notes/index.rst index fe12d34..ea48b1f 100644 --- a/doc/release_notes/index.rst +++ b/doc/release_notes/index.rst @@ -5,5 +5,6 @@ :maxdepth: 1
devel + v_1_5 v_1_4 v_1_3 diff --git a/doc/release_notes/v_1_5.rst b/doc/release_notes/v_1_5.rst new file mode 100644 index 0000000..6e81353 --- /dev/null +++ b/doc/release_notes/v_1_5.rst @@ -0,0 +1,239 @@ +==================== +v1.5 (Dec 2024) +==================== + +This document describes the major changes in flashrom version v1.5.0, +from more than 80 patches contributed by more than 20 authors (thank you!). + +And we all did it in just ~4 months since previous release. + +Download +======== + +flashrom v1.5.0 can be downloaded in various ways: + +Anonymous checkout from the git repository at https://review.coreboot.org/flashrom.git +(tag v1.5.0) + +A tarball is available for download at <TODO add tarball> +(signature <TODO add signature>) + +fingerprint: <TODO add fingerprint> + +Known issues +============ + +AMD-based PCs with FCH are unable to read flash contents for internal (BIOS +flash) chips larger than 16 MB, and attempting to do so may crash the system. +Systems with AMD "Promontory" IO extenders (mostly "Zen" desktop platforms) are +not currently supported. + +https://ticket.coreboot.org/issues/370 + +Build only supported with Meson +=============================== + +As documented in the :doc:`v1.4 release notes <v_1_4>`, support for building +flashrom with make has been removed; all Makefiles have been deleted. Meson is +now the only supported tool for building flashrom from source. + +New Features +============ + +Support for ECAM +---------------- + +Libpci 3.13.0 and onwards support ECAM to access pci registers. flashrom will +be moved to ECAM from IO port 0xcf8/0xcfc if the libpci version is >= 3.13.0. +The ECAM has been supported for a very long time, most platforms should support +it. For those platforms don't support ECAM, libpci will terminate the process by +exit. + +Progress bar +------------ + +Progress bar feature is now working for all operations: read, erase, write. + +To display progress bar, add ``--progress`` option on the command line. + +Option to choose between speed and longevity of the chip +-------------------------------------------------------- + +New command line option ``--sacrifice-ratio`` handles the following situation: + +There is a region which is requested to be erased (or written, because +the write operation uses erase too). Some of the areas inside this +region don't need to be erased, because the bytes already have expected +value. Such areas can be skipped. + +The logic selects eraseblocks that can cover the areas which need to be +erased. Suppose there is a region which is partially covered by +eraseblocks of size S (partially because remaining areas don't need to +be erased). Now suppose we can cover the whole region with eraseblock +of larger size, S+1, and erase it all at once. This will run faster: +erase opcode will only be sent once instead of many smaller opcodes. +However, this will run erase over some areas of the chip memory that +didn't need to be erased. Which means the physical chip will wear out +faster. + +This new option sets the maximum % of memory that is allowed for +redundant erase. Default is 0, S+1 size block only selected if all the +area needs to be erased in full. 50 means that if more than a half of +the area needs to be erased, a S+1 size block can be selected to cover +the entire area with one block. + +The tradeoff is the speed of programming operation VS the longevity of +the chip. Default is longevity. + +RPMC support added +------------------ + +Adding support for RPMC commands as specified by JESD260 to the cli_client. + +Main implementation is in ``rpmc.c``. Also adds new parsing capabilities for the SFDP +page carrying the necessary information. All the features are optional and +depend on ``libcrypto``. + +It currently uses automatic feature detection through the corresponding +SFDP page. + +Programmer updates +================== + +* ch347_spi: Add spi clock frequency selection (``spispeed`` option) +* dummyflasher: Enable higher frequency emulation, add docs and tests +* ichspi: Change the opcode position for reprogramming on the fly 2->4 +* ichspi: Merge spi_master implementations for Intel ich +* stlinkv3_spi: Mark STLinkV3-Mini not working + +Bugs fixed +========== + +* Modified bytes would sometimes not be verified after writing + + In some situations an off-by-one error would cause the last byte + of memory that was modified by an operation to not be verified. + This could prevent some erase or write errors from being detected, + or in other cases could make verification appear false-negative. + + Fixed by https://review.coreboot.org/c/flashrom/+/84078. + +* Possible crashes while preparing erase operations + + An out-of-bounds memory read was found in the algorithm that selects methods + to erase memory, which could cause flashrom to crash. This issue was first + introduced in release 1.4, and crashes were observed when running on OpenBSD. + + See https://ticket.coreboot.org/issues/555, and fixed by + https://review.coreboot.org/c/flashrom/+/84234. + +* Crash when attempting to erase FEATURE_NO_ERASE chips + + When attempting to erase a chip that doesn't need to be erased before + being written, flashrom could attempt to read through a null pointer + and crash. The only supported chip that is affected is the M95M02 + EEPROM. + + See https://ticket.coreboot.org/issues/553, and fixed by + https://review.coreboot.org/c/flashrom/+/84203. + +* install failures related to libcmocka + + In some configurations, the install target provided by the buildsystem (like + meson install) would fail to execute successfully due to a missing libcmocka + file. This is fixed by not installing libcmocka, because it is a third-party + library used by flashrom only for testing. + + See https://ticket.coreboot.org/issues/561, and fixed by + https://review.coreboot.org/c/flashrom/+/84557. + +* Excess erase of automatically-probed chips on Intel chipsets + + When erasing some chips using the ichspi programmer (for Intel ICH chipsets), + the entire chip would be erased and rewritten even when the hardware supported + erasing smaller blocks, causing operations to take longer to complete and + negatively impacting chip longevity. This issue was first introduced in version + 1.4. + + See https://ticket.coreboot.org/issues/556, and fixed by + https://review.coreboot.org/c/flashrom/+/84253. + +* Unnecessary erases + + When erasing parts of a memory, some blocks could be erased and rewritten + unnecessarily or erased multiple times which could hurt the longevity of + the memory chip. This behavior was introduced in version 1.4. + + Fixed by https://review.coreboot.org/c/flashrom/+/84614 and + https://review.coreboot.org/c/flashrom/+/84686. + +Chipset support +=============== + +Added Raptor Point PCH support. + +Chip model support added +======================== + +* FM25Q04 +* FM25Q64 +* FM25Q128 + +* GD25B128E +* GD25B256E +* GD25B512MF +* GD25F64F +* GD25F128F +* GD25F256F +* GD25R128E +* GD25R256E +* GD25R512MF +* GD25LB256F +* GD25LB512ME +* GD25LB512MF +* GD25LR256F +* GD25LR512MF +* GD25LF256F +* GD25LF512MF + +* MX25U25645G +* MX77U51250F + +* W25Q32JV_M +* W25R512NW +* W74M51NW + +* XM25LU64C +* XM25QH32C +* XM25QH32D +* XM25QH64D +* XM25QH128D +* XM25QH256D +* XM25QH512C +* XM25QH512D +* XM25QU16C +* XM25QU32C +* XM25QU128D +* XM25QU256D +* XM25QU512C +* XM25QU512D + + +* S25FL256L marked as tested + +Misc +========= + +* reduce DELAY_MINIMUM_SLEEP_US to 100 by default +* tests: Add assert for eraseblocks order of invocations for write op +* tests: Add header stdlib.h to allow scan-build to do analysis +* VERSION: Change name pattern to match tag name from now on +* writeprotect: Fix inaccurate return code +* erasure_layout: Fix unreachable error message +* linux_mtd: fix build with clang >= 19 +* Extract usbdev declarations to a separate header +* chipset_enable.c: Add TGL chipset detection based on SPI PCI ID +* flashchips: Skip "WP untested" message for SFDP-capable chip +* sfdp: Update the message shown when SFDP-capable chip is detected +* build script: Add rpmc option to always be enabled on Jenkins +* Rename cli_classic.h to a more adequate cli_getop.h
-
Anastasia Klimchuk (Code Review)