mirror of
https://review.coreboot.org/flashrom.git
synced 2025-04-26 22:52:34 +02:00
fad9f4a547
Change-Id: I80f8423133bf779093d57ea6928f09d9d377d20e Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org> Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Reviewed-on: https://review.coreboot.org/c/flashrom/+/85655 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Peter Marheine <pmarheine@chromium.org>
267 lines
8.5 KiB
ReStructuredText
267 lines
8.5 KiB
ReStructuredText
====================
|
|
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 can be downloaded either via anonymous git at https://review.coreboot.org/flashrom.git,
|
|
or as signed source tarballs.
|
|
|
|
The key fingerprint for source tarballs is
|
|
|
|
6E6E F9A0 BA47 8006 E277 6E4C C037 BB41 3134 D111
|
|
|
|
Version v1.5.1
|
|
---------------
|
|
|
|
Version 1.5.1 fixed an issue flashing some Intel-based platforms with the internal programmer
|
|
that was introduced in 1.5.0.
|
|
Users with older Intel-based platforms (Broadwell/Braswell and earlier) flashing using the internal
|
|
programmer option might encounter an 'Invalid OPCODE' error when erasing/writing which would lead to an
|
|
incomplete flash and potentially a bricked device. External flashing was not affected at all.
|
|
|
|
All users are encouraged to update.
|
|
|
|
Ticket: https://ticket.coreboot.org/issues/573
|
|
|
|
Patch: https://review.coreboot.org/c/flashrom/+/85612
|
|
|
|
Git tag: ``v1.5.1``
|
|
|
|
Tarball: https://download.flashrom.org/releases/flashrom-v1.5.1.tar.xz
|
|
|
|
Signature: https://download.flashrom.org/releases/flashrom-v1.5.1.tar.xz.asc
|
|
|
|
Version v1.5.0
|
|
--------------
|
|
|
|
Git tag: ``v1.5.0``
|
|
|
|
Tarball: https://download.flashrom.org/releases/flashrom-v1.5.0.tar.xz
|
|
|
|
Signature: https://download.flashrom.org/releases/flashrom-v1.5.0.tar.xz.asc
|
|
|
|
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
|