When flash regions are protected, erase could incorrectly erase regions
which were meant to be protected by requesting the correct size but
using an erase opcode with coarser granularity than desired (for
instance using a 16-byte erase command while attempting to erase only 8
bytes).
This fixes that by exchanging the nesting of the loops over erase blocks
and flash regions.
Old:
- Select erasefns
- Loop over blocks to erase for each selected erasefn
- Loop over programmer flash regions within erase block
- Erase regions (may fail since selected erasefn will be
too big if flash region is smaller than erase block)
New:
- Loop over programmer flash regions within erase block
- Select erasefns within programer flash region
- Loop over blocks to erase for each selected erasefn
- Erase regions
Eraser selection and erasing has also been factored out into a helper
function to manage nesting depth.
TEST=New test cases pass, whereas some of them fail without the changes
to erasure_layout.c
BUG=https://ticket.coreboot.org/issues/525
Change-Id: Ic5bf9d0f0e4a94c48d6f6e74e3cb9cccdc7adec9
Co-authored-by: Nikolai Artemiev <nartemiev@google.com>
Co-authored-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
get_flash_region() emits a struct flash_region, which uses chipoff_t for
the start and end addresses of a region. chipoff_t is defined as a valid
flash address, so it was wrong to be setting the end address to start +
len; this is clearly wrong in the case where there is a single region
because setting end to the flash size generates an address that is
beyond the end of the chip (due to zero-indexing).
This changes the one actual implementation of .get_region in ichspi.c to
use inclusive upper bounds, and corrects all callers of
get_flash_region() to treat the upper bounds as inclusive. Overall this
reduces complexity slightly by removing more downward adjustments by 1
than it needs to add upward adjustments.
TEST=on yaviks, `flashrom -V -x` prints equivalent messages about
"x region (0xZZZZ..0xZZZZ) is readable" before and after this
patch.
Change-Id: Ia0ca867aef33b598c2697fc264807fa5e29683ec
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
memcpy() function expects 2nd parameter to be non-null. Make sure that
the pointer is non-null before passing it to the function.
Also move allocations under if conditions to avoid allocating memory for
a potentially 0 size.
Found-by: scan-build, clang v17.0.6
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I99aad4119f9c11bea75e3419926cc833bc1f68c5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81548
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the case when layout region is not aligned with eraseblock,
end region boundary is extended to match the eraseblock. There is
a special handling of this extended area (between original end of
region and extended one). Fix the offset of this extended area by +1
so that it covers the extended area and not the original region.
Before the patch, the last byte of the original region was failed to
write since it was treated as if an extended area, while it was the
last byte of the normal layout region.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I7f78a0090065cd2a952cba1a5d28179483ba4c55
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Previously, in the worst-case scenario of erasing region content then
writing new data, three rounds of verification were performed inside of
the `erase_write` function through calls to:
1. `check_erased_range` when erasing with respect to region boundaries
2. `check_erased_range` for the entire erase block after the loop
containing verification 1 completed
3. `verify_range` when all erases/writes were complete
Verification 2 duplicated verification 1 and was orphaned by commit
fa8808595a, which dropped its paired erasefn call but missed this
related step.
Verification 3 duplicated verification which occurs in
`flashrom_image_write` based on `flashctx flags`.
Now, these 2 redundant verifications are removed to improve the
performance of `erase_write`.
This change was tested using the linux_spi programmer to erase and write
to an MT25QL512 chip.
Change-Id: I638835facd9311979c4991cc4ca41a4b9e174bd5
Signed-off-by: Carly Zlabek <carlyzlabek@gmail.com>
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Erasefn was invoked over the same block of memory twice.
This patch removes the second redundant invokation. It was
accidentally introduced during earlier refactoring of the code.
Change-Id: I92351eba0fd29114ce98b4a839358e92d176af28
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77747
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Header files can be found without explicitly specifying include
directory on the file path.
Change-Id: I6ef34273d088d8fb4559fe3d801d1247ad9b3fa2
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aarya <aarya.chaumal@gmail.com>
On failure of erasefn in erase_write it didn't set the error value in
ret which caused send success status as return value.
Change-Id: Ia3bd5fd250dcd0a03f0281c478b9bacb71872f31
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74882
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
DJGPP for compiling DOS has other sizes for the normal int types and
therefore throwing errors when using %i %d or %x with uint32_t.
Fix these warnings by using the macros created for it and provided in
inttypes.h.
Change-Id: Ia75b6df981ce60c891161fe553c7ceab8570178d
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73040
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In erasure_layout.c:create_erase_layout() the layout will be allocated
based on erasefn_count, But calling calloc with 0 is unspecified
behavior. Also it is not freed when erasefn_count is 0.
So test first if erasefn_count is 0, and only when not allocate the
memory for *layout.
Reported by Coverty Scan:
*** CID 1505171: Resource leaks (RESOURCE_LEAK)
/erasure_layout.c: 105 in create_erase_layout()
98 if(!layout) {
99 msg_gerr("Out of memory!\n");
100 return -1;
101 }
102
103 if (!erasefn_count) {
104 msg_gerr("No erase functions supported\n");
>>> CID 1505171: Resource leaks (RESOURCE_LEAK)
>>> Variable "layout" going out of scope leaks the storage it points to.
105 return 0;
106 }
Change-Id: If13b050ac8525fee44d3f3bf74a9c9b6a8d38399
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
1) Add function to flatten out the addresses of the flash chip as per
the different erase functions. This function will return a list of
layouts which is dynamically allocated. So after use all the layouts as
well as the list itself should be freed. The free_erase_layout function
does that.
2) Add function to align start and end address of the region (in struct
walk_info) to some erase sector boundaries and modify the region start
and end addresses to match nearest erase sector boundaries. This
function will be used in the new algorithm for erase function selection.
3) Add function that returns a list of sectors (as seen by the first
erase function) that need erasing.
4) Add a function to call the erase algorithm.
Change-Id: Ic57ca1cca3d1646543f6b5939ba9c35db8d08256
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
