Attention is currently required from: Nico Huber, Caveh Jalali, Tim Wawrzynczak, Rizwan Qureshi, Edward O'Callaghan, Angel Pons, Nick Vaccaro, Alex Levin.
1 comment:
Patchset:
While you are flashing the SPI using flashrom on DUT at S0, there are cases when we are seeing some flashrom failure issue and debug data that we have so far is not very conclusive to say that CSE is doing anything wrong.
Was upstream flashrom used?
Yup.
Why do you assume that the CSE is involved?
Because Chrome OS needs few features that involve CSE to start it's services post booting to OS. Those services might further need to fetch the CSE active partition residing in SPI at regular intervals. We suspect flashrom operation is conflicting with such access as flashrom doesn't sync based on the SCIP bit.
>
> I would expect the hardware to coordinate between the different masters.
Unfortunately, it seems doesn't support multimaster protocol.
At least,
the SCIP bit can never be enough to synchronize masters. Even with the added
waiting loop, there is still much room for race conditions (e.g. second master
reading SCIP = 0 before the first posted its write to start a cycle).
I believe this sync might work like this.
When first master is creating the command and haven't set the FGO bit. There is no operation that is taking place so, 2nd master can read SCIP = 0 and if 2nd master wish to start a new command, it has still room for that. But immediately after FGO is set, the HW logic will flip the SCIP bit so, 2nd master if about to start the new command, it has to in wait loop till 1st master finishes the operation. And I have created the blocking logic. At based on the initial code analysis, CSE FW will ensure not to intrude into host cpu operation but host CPU (using flashrom) might run into issue because CSE is using SPI bus for read operation hence flashrom operation might fail.
To view, visit change 61854. To unsubscribe, or for help writing mail filters, visit settings.