Cosmo host flash could drop ownership notion

[rmustacc]

Currently the Cosmo host rom management looks like Gimlet: it assumes there's a discrete mux on the system that swaps between whether the host can issue commands or the SP. While the initial reasons for making these similar make a lot of sense, this limits our ability to do a lot of different operations, e.g. we can't do writes to the other slot or make changes to the persistent slot while the system is up. However, there's no inherent reason that it has to be this way (though it is a simpler implementation).

Because the host can never write to the SPI flash as this command should be rejected by the eSPI controller, with some help from the FPGA we can change how this actually works and intersperse writes to the non-active region for booting and the slot selection page. Similarly, there is no reason that the SP can't read this while the host is trying to boot. It means there will be more command latency, but there's nothing that says they can't be interspersed.

I realize that this is something that we may opt to never do, but there are some usability and comprehension challenges here for folks. For example, there is no reason to ever hit #2338 on Cosmo's.

[nathanaelhuffman]

As an implementation note, the FPGA currently enforces ownership of the actual SPI nor IP block via this selection mux to an FPGA-implemented mux. We may need to think through what interspersed reads while writing looks like. I don't think there's strictly a problem here but doing the correctly likely requires some additional FPGA adjustment turning this mux into an arbiter or similar pattern.