Attention is currently required from: Patrick Georgi, Rizwan Qureshi, Stefan Reinauer, Sridhar Siricilla, Angel Pons, Alex Levin, YH Lin, Nico Huber, Martin Roth, Subrata Banik, Caveh Jalali, Tim Wawrzynczak, Nick Vaccaro, Boris Mittelberg.

View Change

2 comments:

• Commit Message:

  • Patch Set #7, Line 24: BUG=b:215255210

    I want to make sure the reference to that bug won't do any damage. I can't […]

    For historical context, the "big lock" approach was intended to prevent multiples instances of flashrom from changing the target flash chip. Back then BBS (boot BIOS strap) was more of a concern, since one instance of flashrom could target a SPI ROM (e.g. BIOS) while could target the EC on LPC.

    Checking SCIP is a good idea, however it doesn't address the original concern that the big lock was intended for which was to prevent sudden changes to SPI controller settings during a read or write operation.

    See also: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/HUXSHBC73MOMK43BP4XXUSUMNVPZ4O6G/

  • Patch Set #7, Line 25: TEST=Concurrent flashrom access is not throwing timeout.

    how since then so many years AU worked without being bothered about checking this SCIP bit in HW SEQ on older platform, I don't have that answer either with me. But for sure SW SEQ platform do use this SCIP bit checking.

    cros-flashrom used software sequencing for a long time because some implementations of hardware sequencing did not provide a way to write all of the status registers on recent flash chips. This meant that write protection could not be set up using hwseq.

    As you pointed out, software sequencing has checked the SCIP bit since commit 01d05914 when Carl-Daniel added it over a decade ago.

To view, visit change 61854. To unsubscribe, or for help writing mail filters, visit settings.