Re: Forcing a USB device to "ugen"

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

> I have a device based on the FTDI FT2232C:
>
> [ 11113285.311079] uftdi1 at uhub1 port 2 configuration 1 interface 0
> [ 11113285.311079] uftdi1: SecuringHardware.com (0x0403) Tigard V1.1 (0x6010), rev 2.00/7.00, addr 3
> [ 11113285.311079] ucom1 at uftdi1 portno 1
> [ 11113285.311079] uftdi2 at uhub1 port 2 configuration 1 interface 1
> [ 11113285.311079] uftdi2: SecuringHardware.com (0x0403) Tigard V1.1 (0x6010), rev 2.00/7.00, addr 3
> [ 11113285.311079] ucom2 at uftdi2 portno 2
>
> It's a combo device that, in addition to a standard TTL-level UART, has a bunch of break-out headers for doing things like SPI, SWD, and JTAG (in my case, I need to use JTAG for programming some Atmel CPLDs).  I should be able to do this with OpenOCD (pkgsrc/devel/openocd), but libfdti1 fails to find the device because libusb1 only deals in "ugen".
>
> "ugenif" might have been a possible solution here, except for the fact that 0x0403,0x6010 is the standard VID,PID for the FTDI FT2232C, and I don't want "interface 1" of ALL FT2232C devices to get the "ugen" treatment.  The desire to use "ugen" on "interface 1" is not a property of 0x0403,0x6010, it's really a property of "SecuringHardware.com","Tigard V1.1".  Unfortunately, there's isn't a way to express that in the kernel config syntax.
>
> I think my only short-term option here is to, in uftdi_match(), specifically reject based on this criteria:
>
> 	- VID == 0x0403
> 	- PID == 0x6010
> 	- interface number == 1
> 	- vendor string == "SecuringHardware.com"
> 	- product string == "Tigard V1.1"
>
> (It's never useful, on this particular board, to use the second port as a UART.)
>
> -- thorpej


[going a little off topic, but maybe this fills in some blanks about
that chip]

The FT2232 and its buddies the FT4232 and FT232H are nice chips.  They
are also polymorphic in that there is at least one or more engines in
the chip called the MPSSE that can program the pins to support any
number of different sorts of things such as I2C, SPI, and simple GPIO
(and others) in addition to a mode that is the usual FTDI UART (at the
very least, some of the chips support other UART modes).  The chip
always identifies itself as a FTwhatever, however, and you can't use
that as the basis for what you want the pins to do and in some cases you
can have a usual FTDI UART plus a I2C bus (for example) at the same time
because there is more than one MPSSE engine present.  I have samples of
all of the chips, and some interest in supporting the polymorphic
behavior, but no particular time to do the work.  My personal main goal
would be to allow any system with a USB port the ability to have I2C,
probably SPI and simple GPIO.






-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org