[coreboot] GSoC project ideas

[Paul Geraedts]

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