Attention is currently required from: Patrick Georgi, Rizwan Qureshi, Stefan Reinauer, Angel Pons, Sridhar Siricilla, Alex Levin, YH Lin, Martin Roth - Personal, Subrata Banik, Caveh Jalali, David Hendricks, Tim Wawrzynczak, Nick Vaccaro, Boris Mittelberg. Hello build bot (Jenkins), Patrick Georgi, Stefan Reinauer, Rizwan Qureshi, Angel Pons, Sridhar Siricilla, Alex Levin, YH Lin, Nico Huber, Martin Roth - Personal, Caveh Jalali, Tim Wawrzynczak, Edward O'Callaghan, Nick Vaccaro, Boris Mittelberg,
I'd like you to reexamine a change. Please visit
to look at the new patch set (#13).
Change subject: ichspi.c: Check SPI Cycle In-Progress prior start HW Seq ......................................................................
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 and Comet Lake, Hatch variants without any failure.
Signed-off-by: Subrata Banik email@example.com Change-Id: Ib9265cc20513fd00f32f8fa22e28c312903ca484 --- M ichspi.c 1 file changed, 17 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/54/61854/13