Attention is currently required from: Nico Huber, Caveh Jalali, Rizwan Qureshi, Tim Wawrzynczak, Sridhar Siricilla, Angel Pons, Nick Vaccaro, Alex Levin, YH Lin, Boris Mittelberg.
1 comment:
Patchset:
This leaves some questions. Is something broken wrt. arbitration? How does
arbitration work if two masters set FGO at the same time? is that accounted
for in the hardware?Yes this is taken care in the HW. The SPI Ctrlr will queue the transaction of one of the masters until the other is served.
Thank you Rizwan. That's how I always understood it. However, Subrata's test
result suggest otherwise:My Bad Nico, I'm also saying the same. This SCIP bit is for each master like when u start a flashrom operation that sets the SCIP bit and attempt to run flashrom using other application (where currently flashrom doesn't bother to look at SCIP even on the same master), we are seeing `timeout` issue in transaction.
Note: there are other tool that uses the flashrom even on running from host (if we leave CSE for now) and if there is no sync mechanism in operations at host side, we will run into the issue.
As I said there is no way to synchronize this with the SCIP bit alone.
Can you please share your thoughts about how the sync should have been taken care without a HW sync bit at each master operation? Additionally, what is your thought behind running more than one application that might potentially use flashrom concurrently being same context master? In such case, how those processes can avoid entering into SPI access move using same flashrom utility?
Don't we need simple semaphore logic to prohibit more than instance to trigger the SPI access using flashrom.
Here is a scenario and please suggest how would you implement such sync: an application example: set_gbb.sh (which might internally use flashrom) would know if some flash operations are in progress using flashrom (example: futility) at the same time? Eventually multiple flashrom utilities would start executing in parallel and without any lock mechanism, we are meant to run into such a timeout error.
The recommendation is to check H_SCIP bit before starting a transaction. This indicates a transaction by the same master is in progress.
Trying to
do so makes the code look rather ill-considered. Running two programs using these
registers at once has many more implications, e.g. one process could clear status
bits that another is waiting for.
This is what is happening now. You could argue saying, we could use the file locking mechanism to avoid multiple program to use the same flashrom while one operation is in progress. Isn't having HW register (SCIP) is better than SW file locking logic.
It seems mind-boggling to continue the program
when it detects that another one is accessing the registers.
This is the point, how do you even *detect* this today that *another* one is accessing register without knowing the busy bit register. And SCIP polling is the way to prevent such access and wait till SPI bus is freely available before initiate newer command with FGO. (This is my bad that I overlooked SCIP polling at first place in SKL days during HW sequencing implemented in coreboot and later flashrom just ported coreboot fast spi driver hence, missed this too).
Please describe your use-case including this other tool in detail and bring it
to the mailing list <flashrom@flashrom.org>.
I have added Edward to help on this regard.
We can try to help finding a solution
to your problems but not if the problem description stays vague, changes at your
convenience and earlier test results that suggest that your hardware does something
wrong are ignored.
Sorry I didn't get your point.
To view, visit change 61854. To unsubscribe, or for help writing mail filters, visit settings.