1
0
mirror of https://review.coreboot.org/flashrom.git synced 2025-04-27 07:02:34 +02:00

7 Commits

Author SHA1 Message Date
Anastasia Klimchuk
dc88d5d618 tests: Add assert for eraseblocks order of invocations for write op
Change-Id: I558fded2b9f876e33ca92dea324d90ef73f6a2be
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
2024-10-24 01:46:35 +00:00
Anastasia Klimchuk
84bfe0e04e tests: Add header stdlib.h to allow scan-build to do analysis
Without the header being explicitly included, scan-build run on CI
was returning errors for these files, such as:

include the header <stdlib.h> or explicitly provide a declaration
for 'calloc'

The functions in question were calloc, free, etc.

Change-Id: I4b79c5f86c074c456533296c309293e4064abe3f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84455
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-09-25 01:46:27 +00:00
Anastasia Klimchuk
14f121e39e Ensure verify operation completed in full if chip memory modified
The patch adds new functionality to the test: tracking the areas of
chip memory that were modified (i.e. by erase or write operation),
and then checking those areas were completely covered by verify
operation.

The test operates over the mock chip memory of 16 bytes, so it is
possible to track each byte which was modified, and assert that is
has been verified afterwards.

Adding the test found a bug which is fixed in this commit:

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 (see test cases #16-19).

Change-Id: I3c5d55a0deb20f23f4072caac8c0dce04cc98fd4
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
2024-09-08 07:48:12 +00:00
Peter Marheine
077c641c33 erasure_layout: Fix get_flash_region bug
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>
2024-06-11 06:30:02 +00:00
Peter Marheine
510ef74653 tests/erase: record the opcode for each erase
This allows tests to verify that the correct opcode is used when
erasing, which is required to unit-test the fix to issue #525 where in
some situations an incorrect erase opcode will be used.

BUG=https://ticket.coreboot.org/issues/525

Change-Id: I3983fe42c2e7f06668a1bd20d2db7fafa93b8043
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
2024-05-31 00:25:27 +00:00
Anastasia Klimchuk
2bf299f1bf tests: Add test cases for erasing/writing unaligned layout regions
The test cases from #16 onwards cover the case when layout region is
not aligned with eraseblock region, and therefore either layout start
boundary or end boundary needs to be extended to align with
eraseblock.

Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I726a30b0e47a966e8093ddc19abf4a65fb1d70ce
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78985
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-01-15 02:01:54 +00:00
Anastasia Klimchuk
ffa2159923 tests: Unit tests for erase function selection algo
The test checks that algorithm for erase functions selection
works and there are no regressions.

Specifically, test contains an array of test cases. Each case
initialises a given initial state of the memory for the mock chip,
and layout regions on the chip, and then performs erase and write
operations.
At the end of operation, test asserts the following:
- the state of mock chip memory is as expected, i.e. properly erased
  or written
- erase blocks are invoked in expected order and expected number
  of them
- chip operation (erase or write) returned 0.

Change-Id: I8f3fdefb76e71f6f8dc295d9dead5f38642aace7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
2023-11-12 22:18:46 +00:00