[flashrom] [PATCH][RFC] uisp_spi programmer support
Andrew
andrew at ncrmnt.org
Mon Jun 2 09:35:31 CEST 2014
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
More information about the flashrom
mailing list