Attention is currently required from: Anastasia Klimchuk.
Peter Marheine has posted comments on this change by Anastasia Klimchuk. ( https://review.coreboot.org/c/flashrom/+/84954?usp=email )
Change subject: doc: Add few sections to recent development doc ......................................................................
Patch Set 1:
(9 comments)
File doc/release_notes/devel.rst:
https://review.coreboot.org/c/flashrom/+/84954/comment/af96bb2b_72e4ff57?usp... : PS1, Line 70: Programmers ```suggestion Programmer updates ```
https://review.coreboot.org/c/flashrom/+/84954/comment/0d7aebfb_a09f5c3a?usp... : PS1, Line 73: * ch347_spi: Add spi clock frequency selection ```suggestion * ch347_spi: Add spi clock frequency selection ("spispeed" option) ```
https://review.coreboot.org/c/flashrom/+/84954/comment/cd0a62c7_0cdea139?usp... : PS1, Line 78: Bugs fixes ```suggestion Bugs fixed ```
I think it'll be more useful for these to describe what can go wrong, and link to the change. Users want to know how they might have been affected by the bugs that have been fixed (which isn't entirely clear with how these are written now), and distributors might want to know which patches they should backport. Suggestions inline.
https://review.coreboot.org/c/flashrom/+/84954/comment/f08e31f3_5a52b9db?usp... : PS1, Line 81: * Ensure verify operation completed in full if chip memory modified : : Post-cleanup after processing unaligned region for the case when end : region needs to be extended to align with erase block. Writing was : done correctly, but post-processing of newcontents could cause : one-off offset at the end of the region, which would make : verification appear false-negative ```suggestion * 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, which could prevent some erase or write errors from being detected.
Fixed by https://review.coreboot.org/c/flashrom/+/84078. ```
https://review.coreboot.org/c/flashrom/+/84954/comment/bef7a071_86818501?usp... : PS1, Line 89: * erasure_layout: Fix init_eraseblock segmentation fault : : Fix a segmentation fault that is caused by accessing an invalid : "subedata" pointer on the last iteration of the init_eraseblock loop. : Instead, short circuit the loop condition to check the sub block index : first, and do not access the invalid pointer if it is the last sub : block. : : Issue was encountered in OpenBSD. ```suggestion * 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. ```
https://review.coreboot.org/c/flashrom/+/84954/comment/ad7de33d_dc526450?usp... : PS1, Line 99: * Fix FEATURE_NO_ERASE chips and add test for them : : https://ticket.coreboot.org/issues/553 ```suggestion * 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. ```
https://review.coreboot.org/c/flashrom/+/84954/comment/12fcf664_f4f55eb0?usp... : PS1, Line 103: * build: never install cmocka : : https://ticket.coreboot.org/issues/561 ```suggestion * 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. ```
https://review.coreboot.org/c/flashrom/+/84954/comment/2d2a7ed4_3cd7c9a8?usp... : PS1, Line 107: * ichspi: Probe opcode in POSSIBLE_OPCODES[] as well : : https://ticket.coreboot.org/issues/556 ```suggestion * 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. ```
https://review.coreboot.org/c/flashrom/+/84954/comment/bfbc5ac4_6d937ca3?usp... : PS1, Line 111: * erasure_layout: Erase larger block only when all sub-block need erase : : * erase/write: Deselect all smaller blocks when large block is selected These are two changes relating to the same issue, so I think they make sense to combine.
```suggestion * 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. ```