[flashrom] [PATCH][RFC] uisp_spi programmer support

[Stefan Tauner]

On Sun, 25 May 2014 17:49:04 +0400
Andrew <andrew at ncrmnt.org> wrote:

> Hello, all.
> 
> I've been playing around with buspirate and my uISP ( 
> https://github.com/uISP/ ) dongle.
> Even with newer firmware buspirate is really slow, and on average, takes 
> 3m 49s to read out
> a 2MiB SPI flash.
> 
> So I decided to play around and see if I can make a faster programmer 
> with my uISP
> dongle. Basically it's an atmega8 with 12M crystal running vusb stack 
> (no hardware usb). Any
> other similar hardware would do. This hardware is really cheap (BOM is 
> less than 5$ including
> the pcb).
> 
> My first attempt was creating a serprog-compatible firmware for uISP. It 
> can be found here:
> 
> https://github.com/uISP/uisp-app-serprog
> 
> The results weren't very exciting. It took 4m 30s to read out a 2MiB SPI 
> flash (EN25QH16) on
> 12M crystal. Same for 20M crystal. It seems like it was a limitation of 
> bulk out transfers via
> vusb.
> 
> The second attempt required patching flashrom itself, but resulted in a 
> MUCH simpler firmware
> that fits roughly 115 lines of code (not counting vusb). It just uses 
> control transfers for both
> reads and writes. With vusb long transfers enabled, 20Mhz crystal, 10Mhz 
> SPI speed and
> max_data_read/max_data_write set to 4096 bytes reading a 2MiB SPI flash 
> took only 2m 13s which I
> consider a WIN.
> 
> 4096 is not a vusb limit. USB spec limits maximum transfers to control 
> endpoint to 4096 bytes anyway.
> 
> Using 254 byte max_data_read/max_data_write and long transfers disabled 
> would be slower, but it is
> possible to fit everything into 2K flash and use some attiny2313, which 
> will make it even cheaper.
> The protocol's simple as hell, so anyone with a better hardware around 
> (STM32, atmega8u2, pic32, whatever)
> can implement it with very little effort and get lighting-fast speeds.
> My WIP patch to flashrom's attached, although I have a few silly 
> questions left:
> 
> * Do I need to implement SPI frequency changing via a dedicated command 
> or is it okay to hardcode it
>    to 10Mhz in firmware?
> * Right now I'm using the same spi_read as serprog does. Is okay, or 
> should I add an option to disable
>    it?
> * firmware version checking, etc. (Is it a good idea to implement?)
> * Is there a better way to benchmark read/write speed in flashrom, since 
> delay loop calibration interferes
>    with speed measurements (currently I just used "time flashrom ...")

Hi,

as you are probably aware of, we have quite some backlog of open patches
and yours is about the exact opposite of easy to deal with. :) Please
don't expect a detailed review any time soon. That said, thank you very
much for sending your patch (and your open hardware :). We would
certainly like to include a module for your programmer eventually.

I'll try to quickly answer your questions:

- SPI frequency is rather unimportant and adding an interface to change
  it can always be amended later IMHO.
- I don't understand your question fully. You have copied the function
  from serprog AFAICS. That's OK for now.
- serprog supports version checks but we had no need to use it yet(?)
  because we only added features (and opcodes) but did not refine
  existing functions in non-compatible ways. I have not looked at your
  protocol so I can't say if it is more likely to need it later. In
  general I think it would be a good idea to add this rather early.
- No benchmark functionality yet. If the calibration loop or anything
  else really makes any difference than your performance is good enough
  already IMHO ;) You could easily add some timekeeping to doit() and
  print the difference between two time stamps at the end, if you want
  more precession.

HTH for now, please keep us updated about your progress and thanks
again.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner