mirror of
https://review.coreboot.org/flashrom.git
synced 2025-06-30 21:52:36 +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:
Anastasia Klimchuk
@ -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
|
||||
|
||||
Reference in New Issue
Block a user