ichspi.c: Check SPI Cycle In-Progress prior start HW Seq

As per EDS, SPI controller sets the HSFSTS.bit5 (SCIP) when software
sets the Flash Cycle Go (FGO) bit in the Hardware Sequencing Flash
Control register.

This bit remains set until the cycle completes on the SPI interface.
Hardware automatically sets and clears this bit. Software must initiate
the next SPI transaction when this bit is 0.

Platform Setup: Alder Lake based ChromeOS devices (Brya variants)

Replication Steps: Accepting and running firmware Auto Update (AU) on
the Brya variants (dogfooder system) is seeing `flashrom` getting timed
out.

Problem Statement:
Evidencing AU (Auto Update) failure while performing firmware update on
the Alder Lake based ChromeOS devices.

Observation:
Based on the initial understanding from the failure log/pattern, it
seems like the platform is evidencing multiple `flashrom` access from
different source, for example: `futility` accesses flashrom for erase,
write and read operation, `crossystem` uses flashrom for updating VBNV,
additionally, `set_fw_good` script also uses `crossystem` to update the
fw status.

Solution:
Without this SCIP check being implemented in flashrom, there is no
way to ensure multiple instances of flashrom performing different SPI
operations are not cancelling each other and running into below error:

Erasing and writing flash chip... Timeout error between offset
0x0061c000 and 0x0061c03f (= 0x0061c000 + 63)! FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.

TEST=Able to flash coreboot image on Alder Lake (Brya variants), Tiger
Lake (Volteer variants), Kaby Lake (Eve system), Comet Lake (Hatch
variants) and Ivybridge without any failure.

Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib9265cc20513fd00f32f8fa22e28c312903ca484
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>

0 files changed, 0 insertions, 0 deletions