Attention is currently required from: Nico Huber, Caveh Jalali, Tim Wawrzynczak, Rizwan Qureshi, Edward O'Callaghan, Angel Pons, Nick Vaccaro, Alex Levin, YH Lin, Boris Mittelberg. Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/61854 )
Change subject: ichspi.c: Check SPI Cycle In-Progress prior start HW Seq ......................................................................
Patch Set 2:
(1 comment)
Patchset:
PS2:
I guess a simple experiment could give a hint if it does: The hardware is also able to start cycles on its own for memory-mapped flash access. You could test if this toggles the SCIP bit in the host master interface. For instance, poll SCIP and then read from the memory-mapped BIOS area. If polling too fast is an issue, I'd measure the time of a short cycle, then take half of that as the > polling
delay.
I believe this scenario is valid while we are booting from SPI memory mapped memory (till we have resources are memory mapped) and not in the case of while we are running the flashrom from OS. There should not be any code which is getting fetched from XIP/SPI mapped memory while BIOS is done.
Doesn't matter what is valid. If it toggles the host master SCIP bit, than there is definitely something to do in flashrom. If it doesn't, that says nothing, but we could continue to investigate and see if CSE activity toggles the host SCIP bit.
CSE access the SPI for read hence, it will for sure flip the SCIP. No doubt about that.
Have you tested that (and with that I mean that the *host* SCIP bit flips when the CSE uses its own interface)?
yes, I have verified by making CSE send a storage access command and read the SCIP from host side and host send a command and read the SCIP from CSE side. And there is no specific interface. It's same SPI controller MMIO offset bit 5 read in both cases.
(sorry to ask dump questions, but so far you haven't told us much beside the background story)