Anastasia Klimchuk submitted this change.
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(-)
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
To view, visit change 85156. To unsubscribe, or for help writing mail filters, visit settings.