On Fri, Sep 06, 2019 at 08:41:28AM -0500, Steve Maher wrote:
Thanks for the information. The slow speed is a little disconcerting...
I haven't completely puzzled the architecture of flashrom. I assume that there is a higher "layer" at which flashrom handles spi transactions, which get passed off to a lower layer to be implemented via bigbang, dedicated spi hardware, etc. Perhaps I'd be better off operating at that level, as batching what would be individual bitbang transactions to a single multi-byte transfer to the 2232 could speed things up considerably.
Yes. If your hardware configuration allows you to do batched transactions then you should interface at a level above simple bitbanging.
For example, a complete spi word transfer could be handled as a multi-byte write to the 2232. Any pointers as to where in the source tree things are at this level of abstraction?
Take a look at ft2232_spi_send_command(). It's job is to launch a complete half-duplex SPI command at the flash device.
If you cannot run the MPSSE in SPI mode then this is the code that will need to be modified to send a different command stream to the MPSSE (obviously you will have to fix up the initialization as well).
On Fri, Sep 6, 2019 at 5:23 AM Daniel Thompson firstname.lastname@example.org wrote:
On Thu, Sep 05, 2019 at 01:50:49PM -0500, Steve Maher wrote:
I've been googling and perusing the source tree, but am still unsure if general bitbang support is present in flashrom.
Specifically, I have a board which has an onboard FT2232H with some of
GPIO pins wired to a SPI flash device. The pins used are NOT the MPSSE
pins from the 2232, but rather some other unused GPIO pins (the MPSSE dedicated pins are being used for JTAG, and the other 2232 channel is
used for data transfer), and I can't change the wiring from the 2232 to
You're talking about the CBUS pins?
Does flashrom support this type of configuration? If there is general bitbang support, I can write the necessary routines to control the pins
the 2232 in a bitbang fashion.
This sounds exactly how the developerbox_spi.c driver works. In that case the GPIO pins are hooked up to a CP2102N rather than an RT2232H but all the principles should be the same.
Assuming the USB wire protocol is of the set pins/read pins variety (each a seperate USB transation) then things can work but it is extremely slow. Even after a bit of optimisation to make it easier to coalesce USB packets then my notes mention read performance roughly on par with a 2400 baud modem (between 60 and 70 minutes per megabyte if you prefer) and write performance was 50% slower still!
Any pointers here would be much appreciated.
How do you hope to toggle the pins? Using libgpiod (e.g. use kernel-side FTDI driver and use the GPIO user/kernel interface) or via libftdi (e.g. userspace FTDI driver that uses the raw USB user/kernel interface).
libgpiod is more generic but I think libftdi would be faster because it would be easier to coalesce USB packets.
If you want to go via libftdi then perhaps try starting from the developerbox_spi.c driver, rip out the CP210XN code and replace it with libftdi calls to manipulate the CBUS pins. See https://github.com/legege/libftdi/blob/master/examples/bitbang_cbus.c for inspiration on that.