[SerialICE] an idea

[ron minnich]

On Thu, Nov 26, 2009 at 7:16 AM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> There are two ways to do this:
> 1. Link flashrom with libpayload and have it stored in the ROM. Needs
> working RAM to be useful.

So that option is out.

> 2. Add serialice support to flashrom via an external programmer driver.
> Will not work reliably for parallel and LPC flash due to timing
> constraints: we have a few timeouts in the order of 50 盜 (microseconds)
> during programming and I doubt we can reach a sustained data rate of 5
> bytes (1 command, 3 addr, 1 data) per 50 盜 (100 kByte/s, 800 kbit/s)
> over serial.

OK IIRC many of the parts we use can do bytewise programming, or is
that memory wrong? If they can do bytewise programming, then there are
no timing constraints between data bytes sent over serial, and we can
have large inter-data-byte delays, and need only deal with the short
delays between the sequence of FLASH writes for the commands and one
byte of data to program each byte [did that make sense?].

I think this says we may need some minor changes to operators for the
external interface that could match serialice? In SerialICE we have no
memory but we have a few register variables -- certainly enough to
hold base address, length, and byte of data.

Can we have something like:
1. erase block command
2. set programming base address command
3. set programming length command
4. "streaming program"
    given (2) and (3), accept "length" bytes and do bytewise
programming for each one. You'll have to tell me
    if this can even work.

This is obviously not a production interface but it would make my life
a lot easier. I would no longer need to sacrifice a 1580 for each test
run. I just got told I'm going to have 2048 1580s handed to me and
dedicated to the botnet stuff, so the BIOS issue just became important
to me again. At the same time something along these lines *could*
become incredibly useful in many real-life situations: a very simple
API, *primarily designed to be computer controlled*, which can be used
to recover from almost any bad thing that happens. The key is
*primarily designed to be computer controlled*: not some kludgy
keyboard/mouse/display interface like current BIOSes do, but rather a
system designed for automated error detection and recovery, up to and
including reflashing the BIOS. I think this could be a really Big
Deal. In fact it could be a huge value-add for coreboot (There! I Just
used Market-droid language!)

Another very useful thing to do with SerialICE would be a "test
harness" mode where we run the memory enable sequence and return
control to SerialICE, and then test memory.

I think the uses of SerialICE are really just becoming apparent. It
certainly wins the Cool Hack of The Year Award for this project, if
not all projects :-)

ron