mirror of
https://review.coreboot.org/flashrom.git
synced 2025-04-26 22:52:34 +02:00
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>
This commit is contained in:
parent
5ecd48978b
commit
343d54b789
@ -16,189 +16,3 @@ 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 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
|
||||
|
@ -5,5 +5,6 @@ Release notes
|
||||
:maxdepth: 1
|
||||
|
||||
devel
|
||||
v_1_5
|
||||
v_1_4
|
||||
v_1_3
|
||||
|
239
doc/release_notes/v_1_5.rst
Normal file
239
doc/release_notes/v_1_5.rst
Normal file
@ -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
|
Loading…
x
Reference in New Issue
Block a user