[SerialICE] an idea

[Carl-Daniel Hailfinger]

On 26.11.2009 19:46, ron minnich wrote:
> 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.
>   

Well, with some careful changes, I think flashrom can get by with maybe
2 kB of RAM or CAR. I know what to change, but I can't make 100% correct
RAM requirement estimates. And we'll need boatloads of const keywords.
Patches welcome, especially for the const stuff. The biggest writable
object is the flashchip array. We can make it const, but then we have to
copy each chip to a temporary variable during probe. Not really ideal. Hm.


>> 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 µs (microseconds)
>> during programming and I doubt we can reach a sustained data rate of 5
>> bytes (1 command, 3 addr, 1 data) per 50 µs (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?].
>   

It does make sense until you think about what needs to go over the wire.
Take the simplest example:
JEDEC 1-byte write (3 byte write for starting the program mode, 1 byte
write actual data):
chip_writeb(0xAA, bios + 0x5555);
chip_writeb(0x55, bios + 0x2AAA);
chip_writeb(0xA0, bios + 0x5555);
chip_writeb(*src, dst);

Per write, you have to transfer 4 one-byte writes. For each write, you
have to submit the address (4 bytes, reduced with some tricks to 3
bytes) and the data (1 byte). Even if you have a zero-overhead protocol
(no byte needed to tell SerialICE whether to read or write), you have to
shove 4 bytes (single-byte write) over the wire in 50 microseconds. That
assumes you are allowed a 50 microsecond delay for each chip_writeb.

I'd love to be proven wrong because that would make the task at hand a
lot easier.

Now about SPI flash: All of the SPI interfaces I saw so far have no
timeouts. You could punch in the values by hand (literally) and it would
still work fine. That's one of the reasons why I suggested this model
for SPI.


> 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.
>   

Each command (if we completely ignore the data we want to program) is at
least 3x (3 bytes address, 1 byte data), totaling 12 bytes. After that,
you need 3 bytes start address for streaming write, and can
theoretically stream 1 byte per byte over the serial line. The streaming
is impossible if your chip only supports 1-byte write because you have
to enter the "start program mode" command before each single byte write
to the chip. To make this feasible, you need at least 12 bytes buffer
space for the command and 3 bytes for the first data address. Total is
15 bytes. No idea if you can spare 15 bytes in registers besides the
register holding the current data byte. You tell me.


> 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!)
>   

Give me 16 bytes of CAR/RAM and some registers (32bit reg for address,
8bit reg for data) to work with, and I can give you an interface that
can do byte writes. Twice the RAM if you want to be able to erase
anything. It will be anything but fast, however it will work with
existing flashrom. For SPI, the CAR/RAM requirements are lower, but you
need working PCI (or at least config space access to the LPC bridge) and
you need to activate one memory BAR of the LPC bridge.


> 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 :-)
>   

Are there any contests for that? Nobody knows about SerialICE if we
don't promote it.

Regards,
Carl-Daniel

-- 
Developer quote of the month: 
"We are juggling too many chainsaws and flaming arrows and tigers."