# HG changeset patch # User Mychaela Falconia # Date 1693765467 0 # Node ID 434806360d91400ab50e18455754704f42e79b07 # Parent 17fdd0ba7a2e3df814a6f72eea999ee7b935c718 eeproms: subset import from freecalypso-hwlab diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/duart28c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/duart28c Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,16 @@ +# This EEPROM configuration is one of two possible configs that can be +# programmed into FreeCalypso DUART28 adapters (custom hw made by +# Falconia Partners LLC) based on the FT2232D chip. The present DUART28C +# configuration sets a custom USB ID and is intended to be used together +# with a custom patch to the Linux kernel ftdi_sio driver that applies +# a special quirk when this USB ID is detected. The driver quirk in +# question applies only to FT2232D Channel B and suppresses automatic +# assertion of DTR & RTS when the corresponding ttyUSBx device is opened; +# this driver quirk is required in order to use the DUART28C adapter's +# boot control outputs. + +vid 0x0403 # FTDI +pid 0x7152 # Allocated by FTDI to Falconia Partners LLC + +manuf FreeCalypso +product DUART28C diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/duart28s --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/duart28s Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,18 @@ +# This EEPROM configuration is one of two possible configs that can be +# programmed into FreeCalypso DUART28 adapters (custom hw made by +# Falconia Partners LLC) based on the FT2232D chip. The present DUART28S +# configuration sets the default USB ID that is used by FT2232x adapters +# and is recognized and treated as a generic dual UART device by the +# standard unpatched Linux kernel ftdi_sio driver. This configuration +# is intended for those users who don't need DUART28C boot control outputs +# and who wish to avoid the major inconvenience of applying a custom patch +# to their Linux kernel ftdi_sio driver. Please note that boot control +# outputs CTL1 and CTL2 cannot be used with this EEPROM configuration - +# they will be triggered whenever Channel B ttyUSBx device is opened, +# making them unusable. + +vid 0x0403 # FTDI +pid 0x6010 # FT2232x default, treated as standard dual UART by Linux + +manuf FreeCalypso +product DUART28S diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/ft2232-example --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/ft2232-example Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,4 @@ +vid 0x0403 # FTDI +pid 0x6010 # FT2232x default +manuf Example manuf +product Example product diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/ft232r-example --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/ft232r-example Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,4 @@ +vid 0x0403 # FTDI +pid 0x6001 # FT232R default +manuf Example manuf +product Example product diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/icestick --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/icestick Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,26 @@ +# Lattice iCEstick FPGA board features an FT2232H chip, with Channel A wired +# for MPSSE mode (access to SPI flash and FPGA configuration controls) and +# Channel B wired as a UART for user logic implemented in the FPGA. This +# FT2232H subsystem includes a 93C56 EEPROM, but boards are shipped with it +# blank, causing the FT2232H chip to take its default VID:PID. +# +# Having this default VID:PID causes undesirable behavior under Linux: a pair +# of ttyUSB devices is created upon plug-in, but the first of these two then +# disappears when the developer runs iceprog to manipulate FPGA programming, +# creating a gap in ttyUSB device numbers. And even if you are working with a +# stable logic design and not running iceprog, the first of the two created +# ttyUSB devices is still bogus, as that hardware channel is wired for MPSSE +# and not UART. +# +# In Falconian queendom, the solution to this problem is to program the EEPROM +# behind the FT2232H chip with our own image and set the USB ID to a code that +# tells the Linux kernel to create a ttyUSB device only for Channel B - the +# so-called "JTAG quirk". Falconia Partners LLC got a block of 8 PIDs +# officially allocated to us by FTDI, and since 2020-09 the mainline Linux +# kernel recognizes two of them as JTAG quirks. Use one of those two PIDs. + +vid 0x0403 # FTDI +pid 0x7150 # Allocated by FTDI to Falconia, JTAG quirk in Linux + +manuf Lattice +product ICE40HX1K-STICK-EVN diff -r 17fdd0ba7a2e -r 434806360d91 eeproms/jtag-unbuf --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/eeproms/jtag-unbuf Sun Sep 03 18:24:27 2023 +0000 @@ -0,0 +1,30 @@ +# This EEPROM configuration is meant to be programmed into COTS FT2232D +# breakout boards used as unbuffered JTAG adapters. The custom USB VID:PID +# belongs to Falconia Partners LLC; we hereby allow the community to program +# this PID into generic FT2232D boards (not made by Falconia) as long as +# it is used for the present purpose with this full EEPROM configuration. +# +# The purpose of having a custom USB ID is to prevent the Linux kernel +# ftdi_sio driver from treating this FT2232D instance as a dual UART and +# creating a ttyUSB device for Channel A. If you wish to use Channel B +# as a UART (which is still available for that purpose), you will need to use +# a Linux kernel version with commit 6cf87e5edd9944e1d3b6efd966ea401effc304ee +# included, or apply that commit locally if your kernel version does not +# include it. + +vid 0x0403 # FTDI +pid 0x7151 # Allocated by FTDI to Falconia Partners LLC +manuf FTDI +product Unbuffered JTAG adapter + +# We program Channel A to come up in the 245 FIFO mode prior to being +# switched into MPSSE mode by OpenOCD, as opposed to the default 232 UART mode. +# If the FT2232D chip's ADBUS pins are connected directly to the JTAG target +# without a buffer (what we mean by an unbuffered JTAG adapter), the default +# 232 UART mode is NOT safe, as it will produce a fight on the ADBUS2 line +# between the UART RTS output and the target's TDO output. 245 FIFO mode is +# expected to be safer, as all 8 ADBUS lines will be inputs for as long as +# the ACBUS2 line is left unconnected and not driven by anything. + +byte00 0x01 # Channel A: FIFO mode, D2XX driver +byte01 0x08 # Channel B: UART mode, VCP driver