[coreboot] SPI flashing

Corey Osgood corey.osgood at gmail.com
Thu Jul 7 14:53:24 CEST 2011


On Thu, Jul 7, 2011 at 6:54 AM, Andreas Galauner <andreas at galauner.de> wrote:
> On 7/7/11 11:35 AM, Andrew Goodbody wrote:
>> Also I would expect that #4 NC is not NC at all, it just
>> does not go to the SPI device. It could very well be some way to allow
>> safe programming of the onboard SPI device such as by putting the board
>> into reset.
> I doubt that. There is no Pin which could lead anywhere ;)
>
> I looked into the NM10 datasheet, which at least indicates, that CS# is
> input and output. And it seems that the chipset detects if some other
> SPI master pulls CS# to low.
>
> NM10 Express datasheet, page 58:
>>> SPI Chip Select: This chip select signal is also used as the SPI bus
>>> request signal.
>
> If that is the case, this pin is open-drain with an external pull-up.
> But I don't know what the board does, when it detects this condition.
> Perhaps it switches MISO, MOSI and SCK into a Z-State.

On my NM10 board, I looked into in-system programming, but Carl-Daniel
convinced me that there was too much that could go wrong. Instead, I
have a small board I built that connects all the pins of 2 different
flash chips to the board, except CS# is switched so that the active
chip is hooked to CS# on the board, the inactive chip's CS# pin is
hooked to VCC via a set of 4 opticouples and a DPDT switch (this was a
suggestion from Carl-Daniel and Stepan). You could probably hook CS#
with a diode to each chip, then just switch VCC, but I didn't want to
fry anything I then have debian set up to boot only to single user
mode, pull a flash image off the network, and flash the chip, and if
the flash succeeds, shut down to test the data. Since I'm using two
different model flash chips (I don't remember the model #s of the top
of my head), the script uses flashrom -c [chipname], so if I don't
flip the switch in time, it will fail and wait instead of overwriting
the stock BIOS. It takes about a minute if I get the chip switched
during powerup to do the complete cycle. I could probably shave more
time off that with a customized kernel and startup scripts, but so far
it's been acceptable enough that it hasn't been worth the trouble.

The next evolution of this will probably be hooking a USB hub,
USB->parallel adapter (to do switching and check power light status),
and USB->serial adapter up to my dd-wrt powered router, and having the
entire process scripted, which would allow me to work entirely
wirelessly or even remotely from my laptop. But, first I need to get
the board back from Zotac's RMA department (unrelated issue, I've had
problems with the memory slots ever since I got it, finally DIMM1 gave
out entirely and DIMM2 is a pain to get to work).

I've also had some luck with SerialICE, you may want to consider it as
an alternative. Once the board gets back, I need to figure out how to
disasseble the stock BIOS to bypass the keyboard wait, then I might be
able to get some info on memory init.

BTW, just curious, have you had any luck getting the datasheets from
Intel that cover memory init? Or did you even bother trying?

HTH
-Corey




More information about the coreboot mailing list