On Thu, Nov 26, 2009 at 7:16 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
There are two ways to do this:
- Link flashrom with libpayload and have it stored in the ROM. Needs
working RAM to be useful.
So that option is out.
- 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