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

View Change

2 comments:

• Commit Message:

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

    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.

    Yes, SCIP is more over to prevent two instance of SPI operation initiate the operation by setting the FGO bit. Additionally, a check against SCIP would help us to know why flashrom is aborted (may be because operation initiated from same master in current WIP).

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

    Thanks for the pointer David.

  • 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.

    Yes David, you are spot on, I know what you mean here, SPI status register 2/3 is not supported using hw seq, hence a hybrid model is the only way. But starting from ADL, chipset doesn't support the sw seq, so sw seq is the only way out here. (I remember reading this is some ADL spec but can double confirm)

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

    Yes.

    Obviously because futility moved from calling cros flashrom to using lib-
    flashrom lately. Why do I know that?

    Don't want to argue but there is no evidence about other chipsets adopted libflashrom lately shows the same failure during AU except ADL. So, we are covering all possible to angle to fix this issue and adopt Intel's recommendation.

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