On Tue Mar 13 05:21:11 CET 2012, Peter Stuge wrote:
we could easily attach a fast (66+ MHz) SPI flash chip to it.
The OLS as SPI master mux for having an easy way to flash a real chip used by a mainboard when booting is fine. But the chip should be able to reside on the mainboard, and the OLS should drive the mainboard reset while flashing. Having the OLS connect via wires means that the SPI flash can not be driven quite so fast. The shorter wires the better. The OLS is a big board with exposed contacts on the bottom.
I much prefer a separate wire-connected development board. Signals of ~30MHz over ~30cm cable should not pose a real problem I think and it enables a much cleaner hardware setup.
Not sure if asserting the reset signal of an embedded controller will always be sufficient to make its SPI bus tri-state. Possibly, but not strictly neccesary on such a non-shared bus. The underdefined or even nonexistent documentation in combination with dedicated ISP pins on them make me not too confident about it. Anyhow, these reset signals are often not easily accessible.
During most part of the coreboot porting I do not intend to touch the internal SPI flash anyway, not even reading it. I will just deactivate it with its hold_n signal and use one of two external flash chips instead. When I eventually do want to touch the internal flash I will first write some embedded controller bootstrap code that makes it go into a tri-state, interrupt-masked, in-chip loop if it detects a specific (externally applied) SPI signal state at startup. If possible I will prefer using existing functionality here.
More generally, my plan is to focus on 3 separate use cases, lets denote them as: users, hackers and developers. No physical hardware access should be necessary for users, only reliable flashrom access. Hackers may want physical hardware access. Easy access by means of something like a SOP test clip and mini-PCIe card, preferably without even soldering an SPI and LPC pin header. Developers / automatic test setups may want full physical hardware access. Nevertheless, I prefer to avoid invasive hardware access as much as possible. (I would go as far as applying a computer-controlled power socket in combination with a mechanical finger: much more elegant. : )
The OLS is not a good fit for installation into e.g. a laptop. This is one of the use cases for a QiProg; it's intended to be soldered into the target system, on top of, or very near, the flash chip.
Can you please post a reference to this QiProg device? I would like to read more about it and Google does not seem to know it.
I don't know that LPC is usually available, but even so it is a nice start, and VHDL already exists.
Although not part of the official standard, many non-WWAN mini-PCIe slots carry the 7 mandatory LPC signals instead of the official 7 UIM signals. I have added the typical signal mapping below. Unfortunately, the SERIRQ signal is not part of the 7 mandatory LPC signals. It may be available on a separate LPC pin header.
Regards, Paul
mini-PCIe pin | offical signal | LPC signal 08 | UIM_PWR | LFRAME# 10 | UIM_DATA | LAD3 12 | UIM_CLK | LAD2 14 | UIM_RESET | LAD1 16 | UIM_VPP | LAD0 17 | UIM_C8 | LRESET# 19 | UIM_C4 | LCLK