mirror of
https://review.coreboot.org/flashrom.git
synced 2025-04-26 22:52:34 +02:00
4bb95382b9
Change-Id: Iedaca4a704c57c1db399c7888f743ad2961cbf9d Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Reviewed-on: https://review.coreboot.org/c/flashrom/+/84954 Reviewed-by: Peter Marheine <pmarheine@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
205 lines
6.7 KiB
ReStructuredText
205 lines
6.7 KiB
ReStructuredText
===============================
|
|
Recent development (unreleased)
|
|
===============================
|
|
|
|
This document describes the major changes that are expected to be included in
|
|
the next release of flashrom and which are currently only available by source
|
|
code checkout (see :doc:`../dev_guide/building_from_source`). These changes
|
|
may be further revised before the next release.
|
|
|
|
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 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
|