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

[Andrew]

Stefan Tauner wrote on 01.06.2014 04:33:
> 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.

Thanks for the reply. I will be refining and documenting the protocol 
and
hardware shortly and will resend the patch this week along with a more 
detailed
writeup, pictures and benchmarks.

So far the changes implemented are:
   * Protocol versioning support
   * Programmer now reports CPU frequency and maximum SPI frequency
   * SPI Frequency setting (for now with a programmer param)
   * Multi-CS support (if the programmer has several flashes attached to 
different chip-selects)
   * Any ideas what else to implement?
   * Programmer lock/unlock (Another accidentally started instance of 
flashrom won't screw us up anymore)

I will be also making some new hardware based on STM32, that should 
provide a real speed boost,
but since the actual chips are stuck somewhere between China and Russia 
this may take a while.
My goal is to make a blazing fast programmer with BOM cost of under 5$ 
(and possibly parallel
flash programming support as well).

-- 
Regards,
Andrew