Stefan Tauner wrote on 01.06.2014 04:33:
On Sun, 25 May 2014 17:49:04 +0400 Andrew andrew@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).