I noticed that it takes painfully long for flashrom to even simply read a 16MB flash chip using FT2232H (Olimex ARM-USB-TINY-H)
programmer.
The time it takes would be appropriate for kHz-range SPI clocks, not for 30MHz SPI clock that FT2232H provides.
I checked with an oscilloscope and found out that there are long multi-
millisecond delays between short (~150us) SPI clock bursts during simple chip read operation ('-r' or 'reading old flash chip contents'). The delays are 2ms for native Windows 7 64-bit on an Intel Core-i7 2600 @ 3.4GHz, or as long as 7ms for a Ubuntu Linux running in a virtual box on the same Windows machine.
I didn't look any deeper though.
Has anyone done any profiling or have any ideas as to what may be causing
this behavior?
I suspect the main part of this is the latency of the (FTDI) USB protocol. Maybe the performance of the flashrom driver can be improved with bigger buffers/bursts of reads but I am not aware of any obvious bottlenecks.
Stefan, you are correct. It doesn't look like flashrom's fault.
I did some profiling and found out that ft2232_spi_send_command() is called during the chip read operation with a delay of just around 50us after itself. Inside the function there are 2 to send_buf() and 1 call to get_buf() that altogether total to those damn 7ms. Digging further gave me that the majority of the time for send_buf() is spent inside ftdi_write_data() which is basically a wrapper around usb_bulk_write().
According to profiling data, the only function that usb_bulk_write() calls is ioctl(), and those 4 calls per bulk write call take just as much as 7% of the total time taken by usb_bulk_write().
Since usb_bulk_write() is nothing more than a loop calling:
ioctl(dev->fd, IOCTL_USB_BULK, &bulk);
I assume that the poor performance is the fault of FT2232H itself.
Does it sound to you like my analysis is correct or am I terribly wrong anywhere?
Thanks.
With best regards – Alexander Amelkin, T-Platforms [http://www.t-platforms.com]