--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/fc-uja/design-spec	Mon Oct 21 00:53:38 2019 +0000
@@ -0,0 +1,536 @@
+FreeCalypso UART+JTAG Adapter
+Board design specification
+
+1. Purpose and scope
+
+The circuit board described in this specification will be an adapter for
+connecting a host PC or laptop (via USB) to the following 3 development
+interfaces on FreeCalypso GSM devices:
+
+* A 3-wire UART interface intended for RVTMUX on Calypso's IrDA UART
+* Calypso JTAG
+* Iota nTESTRESET
+
+The core function of interfacing from USB to a UART, JTAG and GPIO will be
+performed by an FT2232D chip, but the board described herein has two key
+differences from a generic FT2232x board, key differences which necessitate the
+development of a custom board:
+
+* Our board will have 3-state buffers on the JTAG lines and an open drain
+  driver on the nTESTRESET line, wired in such a way that they cannot be
+  accidentally turned on while the FT2232D is in its power-up default UART
+  mode, prior to the software switch into the MPSSE+GPIO mode.
+
+* The target connection interface will be presented not only on general-purpose
+  headers, but also on a special FFC connector, to be used with our future
+  FreeCalypso handset boards that will use the FFC-based development interface
+  copied from Foxconn's Pirelli DP-L10 phone.
+
+The gadget to be built is intended to serve the following two purposes, in this
+order of importance:
+
+Application 1: the present adapter will be required to do initial bring-up,
+deep development and production-time programming and testing on our upcoming
+FreeCalypso handset boards.  Calypso's MODEM UART will be wired to the handset's
+built-in USB-serial port also acting as the charging power source, but that
+interface is intended for end users - deep development, initial bring-up and
+production processes will need to be done through the IrDA UART wired to the
+FFC interface through the present adapter.  JTAG is not expected to be needed,
+but is "thrown in for free" - however, the Iota nTESTRESET line will be very
+useful for commanding system switch-on that can be distinguished from both the
+end user power-on button and the charger plug event, as well as for easy
+recovery from any hung state.
+
+Application 2: it costs us nothing extra to bring the target connection
+interface out on generic headers in addition to the FFC connector.  If anyone
+needs to play with JTAG on our FCDEV3B or on a Motorola C1xx phone hacked up
+with little wires, the present adapter will be more robust compared to
+unbuffered COTS FT2232x breakout boards thanks to our 3-state buffers
+protecting the JTAG lines from FT2232's initial UART mode garbage.
+
+However, the present FreeCalypso UART+JTAG adapter board is NOT intended to be
+used as a generic JTAG adapter for non-Calypso targets.  The set of additional
+signals needed besides JTAG is quite different between the two: most traditional
+(non-GSM) ARM processors and DSPs have TRST and/or SRST signals, and sometimes
+also DBGRQ/DBGACK - whereas the Calypso+Iota chipset has no TRST, and the way
+Iota's nTESTRESET signal works is quite different.  Companies like Tin Can Tools
+(Flyswatter2) already provide superb-quality and very cheap FT2232x-based JTAG
+adapters for "generic" applications, and there is no point in trying to compete
+with them - instead we need a Calypso-specific adapter that provides a UART,
+nTESTRESET control and JTAG in this order of priority.
+
+2. Detailed design
+
+2.1. FT2232D core block
+
+The FTDI chip chosen for this adapter board is FT2232D.  One of the FT2232x
+devices is needed because we need MPSSE for JTAG plus a second channel for the
+RVTMUX UART, leaving FT2232C/D/L and FT2232H as the two viable candidates.  The
+FT2232H high speed device does not offer anything useful for our application,
+hence the more basic FT2232D has been chosen on the principle of "bez nadobnosti
+nosimyj nabryushnik vreden" (a Russian proverb) - introducing USB high speed
+capability (480 Mbps USB signaling) with FT2232H would increase the chances of
+USB signal integrity problems due to suboptimal PCB layout or suboptimal USB
+cable quality while providing absolutely no useful gain in our application,
+whereas FT2232D is inherently safer in this regard by not having that USB high
+speed capability in the first place.  FT2232D is a direct drop-in for the
+earlier FT2232C and FT2232L chips; FT2232D is a currently active part available
+from Digi-Key whereas its predecessors are surplus-only parts.
+
+FT2232C/D devices only support MPSSE on Channel A, hence our FreeCalypso
+UART+JTAG adapter will follow the general canon for such adapters in that JTAG
+and test reset will be on Channel A, whereas Channel B will be used for the
+RVTMUX UART.
+
+There will be a 93C46 EEPROM connected to the FT2232D chip.  This EEPROM is
+needed so that we can give our adapter a custom USB ID (out of the range of USB
+IDs allocated by FTDI to Falconia Partners LLC); this custom USB ID is needed
+for several reasons:
+
+* We don't want the ftdi_sio driver in the Linux kernel to create two ttyUSBx
+  devices for both FT2232D channels only to have the first of the pair disappear
+  when a custom libftdi-based program is run to make use of JTAG and/or reset
+  functions on Channel A - instead we would like to have this driver create
+  only one ttyUSBx device for the UART on Channel B.  There already exist
+  several other UART+JTAG adapters whose creators and users had the same need,
+  and the ftdi_sio driver in Linux supports them.  The existing adapters of
+  this kind are identified by custom USB IDs, and once our own adapter advances
+  past the vaporware phase, we'll be submitting a one-line patch to the Linux
+  kernel driver to add our custom USB ID to the list.
+
+* We will have a custom libftdi-based program for sending nTESTRESET to the
+  FreeCalypso GSM device target through our adapter; this program will have an
+  easier time locating our USB device among other potential FTDI-based devices
+  if we use a custom USB ID.
+
+* When the time comes to configure OpenOCD to do JTAG through our adapter,
+  having a custom USB ID will similarly help prevent erroneous binding to other
+  FTDI-based devices that may be present.
+
+2.2. Buffering logic for JTAG
+
+One significant design blemish of the otherwise quite versatile FT2232D is that
+"bit" modes like MPSSE cannot be configured in the EEPROM, instead they can only
+be entered dynamically on software command from the host.  As the result, an
+FT2232D channel that is meant to be used for, say, JTAG on a given board will
+still operate in its default UART mode when USB power is first applied, and will
+remain in this state indefinitely long, until the user runs a program on the
+host that issues a software command to enter the "bit" mode - which may never
+happen.  If an FT2232D channel is wired for JTAG but the chip operates in its
+default UART mode, the following problems will occur if the signals are wired
+directly without additional buffering logic:
+
+* The ADBUS0 line which becomes TCK in JTAG mode is TxD in UART mode, and will
+  thus drive a high level on power-up - even though the quiescent state on TCK
+  should be low.
+
+* JTAG TDO line (output from the target) needs to be connected to ADBUS2 - this
+  signal becomes an input in MPSSE mode - but in the power-up default UART mode
+  ADBUS2 is an output.  Thus this default output can end up fighting with the
+  target's TDO output, potentially damaging the target, the adapter or both.
+
+(The other two JTAG signals - TDI and TMS driven from ADBUS1 and ADBUS3 - are
+ less of a problem because in the power-up default UART mode these FT2232D pins
+ are inputs with weak internal pull-ups on them.)
+
+Our solution to this problem is to insert 3-state buffers (unidirectional in
+the JTAG signal direction) into all 4 JTAG lines.  We shall use 3-state buffers
+with active-low enables, and the two enable lines (one for the TCK, TDI and TMS
+outputs from the adapter, the other for the TDO input) will come from FT2232D
+pins ADBUS5 and ADBUS6.  In the MPSSE mode used for JTAG these pins become GPIOs
+and will need to be configured as outputs driving low in order to enable JTAG,
+but in the power-up default UART mode they are inputs with internal pull-ups,
+and we will have additional external pull-ups for safety.  The effects will be
+as follows:
+
+* As long as the FT2232D channel is in UART mode, the 3-state buffers can never
+  be enabled.  All JTAG outputs from the adapter will be tristated (i.e., the
+  same as if the adapter weren't there, presenting the target with its normal
+  sans-JTAG state), there will be no fighting on ADBUS2, and the UART will sense
+  all of its inputs as inactive high.
+
+* As the MPSSE mode is entered on software command, the initial pin direction
+  mask byte should be 0x01, keeping ADBUS0 as an output, but then an MPSSE GPIO
+  command should be given, enabling the other outputs along with sensible
+  initial values.
+
+* ADBUS6 should be driven low to enable the TDO receiving buffer (it will have
+  a weak pull-up on the buffer's input in order to not float when there is no
+  target connected) right after ADBUS2 is switched to being an input, but
+  ADBUS5 can be driven low or high at any time afterward to enable or disable
+  the JTAG outputs.
+
+2.3. Sideband signals alongside JTAG
+
+2.3.1. Iota nTESTRESET driver
+
+The test reset line in the Calypso+Iota solution (nTESTRESET) is handled by the
+VRPC block in the Iota ABB which is essentially a PMIC.  It is always pulled up
+inside the GSM device to a non-logic power rail, and this circuit works even
+when the mobile is in the switched-off state with all of the main voltage
+regulators for regular logic turned off.  The raw nTESTRESET line is not meant
+to ever be driven by any kind of active push-pull logic driver; instead it is
+meant to be shorted to GND to trigger the reset, through either a pushbutton
+switch or an OC/OD driver.
+
+Back when TI made their x-Sample and Leonardo development boards, they
+apparently preferred to drive their JTAG+reset test interface (14-pin header in
+TI's JTAG pinout) with whatever generic (non-Calypso-specific) JTAG adapter
+they already had at the time, and as their 14-pin JTAG interface was defined,
+pin 2 (reset) was defined to be TRST with an active push-pull driver in the
+JTAG host adapter (or "emulator" as they call it).  These x-Sample and Leonardo
+boards have a little on-board circuit between this connector pin 2 and the
+actual nTESTRESET; this circuit consists of two transistors and has the effect
+of protecting the internal nTESTRESET line from whatever the external driver
+may be doing: if the external adapter drives a logic low, the transistor circuit
+pulls nTESTRESET low via what is effectively an OC driver, otherwise the JTAG
+block presents a Hi-Z state to the nTESTRESET line.  This circuit has been
+copied from Leonardo schematics on our own FCDEV3B, but the current plan is to
+not include it on the handset board, instead bringing out nTESTRESET in its
+native form on the FFC interface like the Pirelli DP-L10 board appears to do.
+
+Our FreeCalypso UART+JTAG adapter will drive this nTESTRESET pin with an open
+drain driver.  This driving arrangement is compatible with both approaches:
+either direct nTESTRESET connection or the transistor circuit on FCDEV3B and on
+TI's boards.  It does, however, make our adapter specific to Calypso+Iota GSM
+devices: more generic ARM processors and DSPs will often have more standard
+TRST and/or SRST signals instead, possibly needing active push-pull drivers.
+
+To protect the reset line from FTDI's UART-default bogosity, the input to the
+non-inverting open drain driver will come from ADBUS7, which is an input in the
+FT2232D's power-up default UART mode.  Like ADBUS5 and ADBUS6 controls for the
+3-state buffers for JTAG, this ADBUS7 line will have an additional external
+pull-up for safety, thus the reset can never be triggered accidentally while
+the FT2232D channel is in UART mode - the only way to trigger the test reset
+will be to first put the channel into the MPSSE+GPIO mode, then make ADBUS7 an
+output driving low.
+
+2.3.2. Calypso nEMU0 and nEMU1 pins
+
+The Calypso chip has two JTAG-sideband pins called nEMU0 and nEMU1.  They form
+some kind of debug/development interface which is not needed in normal product
+operation, and all Calypso-based GSM phone and modem product boards known to us
+leave them unconnected - even those product boards on which the regular JTAG
+pins are brought out (Pirelli DP-L10 and some Mot C1xx variants).  TI's
+Leonardo schematics leave them unconnected as well, but their more complete
+x-Sample boards have them brought out to the 14-pin JTAG connector.  Our
+FCDEV3B has them brought out as well.
+
+The problem with these nEMU0 and nEMU1 pins is that they are undocumented: the
+docs we have only say that they are bidirectional signals with pull-ups, and
+nothing else.  We have on-board pull-ups on these two lines on our FCDEV3B
+(copied from TI's E-Sample board) strengthening the Calypso chip's supposed
+internal pull-ups, but we don't know what will happen if either or both pins
+are driven low externally (at boot or any other time), nor do we know if the
+Calypso chip itself ever drives or pulses them low as outputs.  Common sense
+suggests that one of their likely functions is probably to hold the ARM7 core
+in the debug halt state directly out of reset, and possibly disable the
+watchdog timer which is otherwise enabled and ticking at this time - but we
+don't know any of the details.
+
+Because we don't know exactly how these nEMU0 and nEMU1 pins work, the only
+sense in which we can support them is to provide a way to use our FreeCalypso
+UART+JTAG adapter as a reverse engineering tool, experimentally playing with
+these nEMU[1:0] pins on an FCDEV3B.  We are going to make the following simple
+provision to facilitate such experimentation: we are going to connect FT2232D
+pins ACBUS2 and ACBUS3 to pins 13 and 14 on the 14-pin JTAG header, which are
+the pins for nEMU0 and nEMU1.  Unlike all other signals, this one will be a
+direct connection without any buffering.  ACBUS2 and ACBUS3 function as open
+drain LED drivers in the power-up default UART mode, and these pins have been
+chosen on the reasoning that they are expected to stay non-driving as long as
+no one actually opens Channel A as a UART and tries to send something through
+it.  The following important additional considerations apply:
+
+* These nEMU0 and nEMU1 signals are NOT included in the FFC interface defined
+  by Foxconn/Pirelli which we are copying for our FreeCalypso handset boards.
+  The positive implication is that the development interface for these FC
+  handset boards will not be adversely affected by the potentially dangerous
+  unbuffered connection to FT2232D pins; the negative implication is that if we
+  ever do learn how to use these nEMU[1:0] pins to do whatever they can do,
+  that ability won't be available on the handset boards.  However, the latter
+  loss is deemed to be acceptable: the most plausible function of these
+  nEMU[1:0] pins is to enter JTAG debug state directly out of reset, and we
+  don't need this ability when we have the internal boot ROM enabled via nIBOOT:
+  we can interrupt and divert the boot process serially, and then enter the
+  debug state through the regular JTAG scan chain.
+
+* Anyone using the 14-pin JTAG header interface to connect to a target such as
+  FCDEV3B that does have nEMU0 and nEMU1 signals on pins 13 and 14 still has
+  the freedom to connect or not connect these signals as desired.  With our
+  current FCDEV3B certain mechanical constraints practically impose the
+  requirement of making a custom cable in any case: the spacing between headers
+  on the FCDEV3B is too tight for standard ribbon cables terminated with IDC
+  connectors (there is no room for the bulky sides of those IDC connectors),
+  hence one needs to crimp female terminals onto individual wires and insert
+  them into a crimp housing instead.  In light of these considerations, you
+  should only connect pins 13 and 14 between our adapter and your target if you
+  are specifically interested in experimenting with driving or sensing Calypso's
+  nEMU0 and nEMU1 signals, otherwise leave them unconnected.
+
+* Our entire "support" for these nEMU[1:0] pins will consist of two PCB traces
+  connecting FT2232D's ACBUS2 and ACBUS3 pins to two pins on the 14-pin JTAG
+  header.  This arrangement, which could be considered quite risky under
+  different circumstances, does absolutely nothing and cannot cause any harm if
+  those two header pins are NOT subsequently connected to an actual Calypso
+  target.
+
+2.4. FT2232D I/O pin summary
+
+Channel A pins will be assigned and connected as follows:
+
+ADBUS0: JTAG TCK (fixed by FTDI)
+ADBUS1: JTAG TDI (fixed by FTDI)
+ADBUS2: JTAG TDO (fixed by FTDI)
+ADBUS3: JTAG TMS (fixed by FTDI)
+ADBUS4: unused and unconnected
+ADBUS5: active-low output enable control for JTAG outputs
+ADBUS6: active-low output enable control for TDO receiving buffer
+ADBUS7: active-low nTESTRESET control
+
+ACBUS0: unused and unconnected
+ACBUS1: unused and unconnected
+ACBUS2: wired to JTAG header pin 13 (nEMU0)
+ACBUS3: wired to JTAG header pin 14 (nEMU1)
+
+The 3 pins that are unused and unconnected (ADBUS4, ACBUS0 and ACBUS1) can be
+configured as either inputs with internal pull-ups or outputs.  For the
+remaining pins which do have assigned functions, the following software init
+sequence should be adhered to:
+
+* As the MPSSE mode is entered on software command, the initial pin direction
+  mask byte should be 0x01.  The critical points are to set ADBUS0 as an output
+  at this point so it never glitches through a non-driving state (it is TxD in
+  the power-up default UART mode), make ADBUS2 an input as it will need to be
+  once TDO is enabled, and set ADBUS5-7 as inputs.  ADBUS5-7 need to be inputs
+  at this stage (the connected logic will sense the inactive high level from
+  pull-up resistors) because the initial output value for initialized-as-output
+  pins is not defined.
+
+* MPSSE Set Data Bits High Byte (0x82) command should be given to set ACBUS2
+  and ACBUS3 as inputs, leaving nEMU[0:1] pins undisturbed until and unless you
+  are playing with them.
+
+* MPSSE Set Data Bits Low Byte (0x80) command should be given to make ADBUS0
+  (TCK) an output driving 0, make ADBUS1 (TDI) an output driving 1, keep ADBUS2
+  as an input from the MPSSE mode entry step, make ADBUS3 (TMS) an output
+  driving 1, and make ADBUS6 (TDO receiving buffer control) an output driving 0.
+  ADBUS5 (JTAG output buffer control) and ADBUS7 (nTESTRESET driver) should be
+  configured as outputs at this point, but their driving values will depend on
+  the application.
+
+Channel B will be used as a data-leads-only UART with standard wiring requiring
+no software intervention:
+
+BDBUS0: TxD (UART output)
+BDBUS1: RxD (UART input)
+the rest: unused and unconnected
+
+2.5. Logic voltage levels and buffering
+
+Many FT2232x-based JTAG adapters have level-translating buffers between FT2232x
+pins and the target interface in order to support targets with different logic
+voltage levels, usually from 3.3 V down to 1.8 V, or sometimes an even wider
+allowed range: for example, the Flyswatter2 adapter from Tin Can Tools supports
+target logic voltage levels from 1.6 to 5.0 V.
+
+In our case such voltage level shifting is not really needed: Calypso is 2.8 V
+native, but perfectly tolerant of 3.3 V inputs as well.  The following
+approaches have been considered for our FreeCalypso UART+JTAG adapter:
+
+Approach 1: put a 3.3 V regulator on our board, run FT2232D I/O pins at 3.3 V,
+run the 3-state buffers for JTAG at 3.3 V as well, and connect the UART lines
+to FT2232D Channel B pins directly, without buffering.  This approach relies on
+Calypso's inputs being tolerant of 3.3 V and Calypso's 2.8 V outputs producing
+voltage levels suitable for 3.3 V inputs.  In practice this approach has already
+been used quite extensively in other contexts: we connect Calypso I/O to 3.3 V
+logic when we connect FCDEV3B UARTs to generic off-the-shelf FT2232x adapter
+boards, users of headset jack serial adapters for Motorola and Openmoko phones
+do likewise, Openmoko connected Calypso's 2.8 V UART to their 3.3 V application
+processor, and Foxconn/Pirelli appear to have done likewise with their built-in
+USB-serial interface based on a CP2102 chip with 3.3 V I/O.
+
+Approach 2: put both 3.3 V and 2.8 V regulators on our board, run FT2232D I/O
+pins at 3.3 V (the lowest I/O voltage officially supported by FT2232x chips),
+have the inputs from the Calypso target go directly to 3.3 V logic like with
+Approach 1, but run the 3-state buffers for JTAG outputs plus an always-enabled
+buffer for the UART output at 2.8 V.  This approach makes the adapter's outputs
+2.8 V proper, but at the cost of an extra on-board regulator.
+
+Approach 3: similar to Approach 2, but omit the on-board 2.8 V regulator and
+instead power the 2.8 V output buffers from the target voltage reference pin
+provided both on TI's 14-pin JTAG interface (used on development boards, both
+TI's and our own FCDEV3B) and on the FFC interface we are copying from
+Foxconn/Pirelli.  Compared to Approach 2, this approach eliminates the extra
+on-board regulator, but would cause some power to be drawn from the target to
+power the output buffers.  This approach would also create difficulties if a
+user wishes to use the generic header interface (as opposed to the highly
+specialized FFC interface), and there is no source from which the target
+reference voltage pin can be supplied.  A compromise approach could be
+implemented by putting a 3-pin jumper header on our board, selecting the power
+to the output buffers between internal 3.3 V and the external target voltage
+reference pin, but having that jumper set to the internal 3.3 V supply would
+effectively bring us back to Approach 1.
+
+Approach 4: do what the "big guys" do in terms of voltage level translation:
+use special dual-supply translating buffers in both directions, supporting any
+target voltage level at least between 1.8 and 3.3 V or possibly wider.  This
+approach would be appropriate for a more general-purpose JTAG adapter that needs
+to work with, say, 1.8 V targets, but given that our adapter is specific to the
+Calypso which has 2.8V-native, 3.3V-tolerant I/O, the extra complexity of
+full-blown voltage level translation is not really justifiable.
+
+Approaches 3 and 4 are excessively complex and cumbersome, and cannot be
+justified in our Calypso-specific application.  The practical choice is thus
+between approaches 1 and 2.  My (Mother Mychaela's) initial leaning was toward
+Approach 1, but upon further reflection I swayed over to Approach 2.  The cost
+of the additional on-board 2.8 V regulator in terms of PCB real estate and
+layout complexity is not too great, and given that our adapter is very
+specifically for the Calypso and no other targets, it makes more sense to put
+out Calypso's native voltage levels, rather than merely compatible ones.
+
+Approach 2 will be used on our FreeCalypso UART+JTAG adapter, with the following
+additional nuances:
+
+* A 74LVC125A output buffer (4 individual buffers in one package) powered from
+  the 2.8 V regulator will be used for the 4 logic outputs from our adapter:
+  JTAG outputs TCK, TDI and TMS, and the single UART output.  The output enables
+  for the JTAG outputs will come from ADBUS5, whereas the UART output will be
+  always enabled.
+
+* Another similar buffer, but powered from the 3.3 V regulator will be used for
+  the two logic signals going the other way: JTAG TDO and the UART input.  The
+  buffer for TDO will be enabled by ADBUS6, the UART input will be always
+  enabled.  There will be a pull-up resistor to local 2.8 V on the input
+  (target interface) side of each buffer.  The buffer for TDO is needed for
+  3-state control, but an identical buffer will also be used for the UART input
+  for the sake of symmetry, and to present the target with a pull-up to 2.8 V
+  rather than FT2232D's internal pull-up to 3.3 V.
+
+* All pull-ups on the interface between FT2232D pins and the just-described
+  buffers will be to 3.3 V.
+
+* A dedicated 3.3 V regulator will be used, instead of trying to use the feeble
+  one built into the FT2232D, as the datasheet-stated limit of 5 mA seems like
+  too little margin.
+
+* The only interface on which the target would ever see 3.3 V rather than 2.8 V
+  will be the purely experimental provision for Calypso nEMU[1:0] described in
+  section 2.3.2, to be used only by those who are specifically interested in
+  that line of experimentation, and not in any other use cases.  It makes no
+  sense to attempt voltage level-translating buffering for these signals when
+  we don't even know if they are really inputs or outputs, and under what
+  conditions.
+
+The target voltage reference pins on the TI-style 14-pin JTAG header connector
+and on the Foxconn/Pirelli-style FFC connector will remain unused and
+unconnected.  One could make an argument that not using the target-provided I/O
+voltage reference is wrong, but the issue needs to be seen in context.  TI's
+14-pin JTAG interface was designed for use in a wide range of applications,
+covering I/O voltages at least between 1.8 and 3.3 V, and TI's XDS JTAG adapters
+support this wide range of I/O voltages just like the ones made by community
+vendors like Amontec and Tin Can Tools.  In the case of Foxconn and their
+Pirelli DP-L10 design, we can never know for certain, but it is highly plausible
+that they weren't making a custom FT2232x-based JTAG adapter of their own like
+we are doing, and instead had a passive adapter that connected their FFC
+interface to some existing TI XDS JTAG adapter, likely via that very same 14-pin
+interface.  In that case the existing TI XDS JTAG adapter they were using needed
+a target voltage reference pin, and so they included one in their custom FFC
+interface.  But our circumstances are different: we are making a custom
+UART+JTAG adapter for reasons of our own, and because our custom adapter is
+very specific to the Calypso, having our own on-board 2.8 V regulator is more
+robust than depending on an I/O buffer supply from the target.
+
+2.6. Target connection interfaces
+
+2.6.1. Generic header interface
+
+Our FreeCalypso UART+JTAG adapter will feature two header connectors: a 14-pin
+header in TI's pinout for JTAG, nEMU[1:0] and nTESTRESET, and a separate 3-pin
+header for the UART.  This header interface option will make it possible to use
+our adapter with the FCDEV3B, with TI's D-Sample board (JTAG+company 14-pin
+interface only) and even with hacked-up C1xx phones with little wires soldered
+to JTAG test pads.  As explained in section 2.3.2, always give explicit thought
+as to whether pins 13 and 14 (nEMU0 and nEMU1) should be connected or not in
+your application.
+
+The UART on FT2232D Channel B will be completely independent of JTAG and other
+Channel A functions, and can be used as a completely generic data-leads-only
+asynchronous serial interface at 2.8 V.
+
+2.6.2. FFC interface
+
+Our upcoming FreeCalypso handset boards will need to use an FFC interface for
+development functions.  At the very minimum this interface needs to connect the
+Calypso's IrDA UART carrying RVTMUX, and do it in such a way that this serial
+interface can be connected without applying a "charger present" condition to
+the VRPC block in the Iota ABB - hence the need for an interface outside of the
+handset's built-in USB-serial port.  Furthermore, if we copy the FFC interface
+from Foxconn's Pirelli DP-L10 design instead of inventing our own, we get not
+only a UART channel, but also JTAG and nTESTRESET on the same interface.  There
+is very little need for JTAG in FreeCalypso, but it is certainly a nice-to-have.
+Having the ability to drive nTESTRESET from the development host will also come
+very useful: once we implement proper handset on/off logic in the firmware,
+meaning that different switch-on causes will be treated like they should be in
+a real handset, switch-on from nTESTRESET will become the development and
+production boot mode.
+
+Our FFC interface is effectively defined by the unpopulated FFC connector
+footprint and its wiring found in Pirelli DP-L10 phones.  It is a 12-pin FFC
+interface with 0.5 mm pitch, the unpopulated connector footprint on Pirelli's
+PCB has pin numbers marked on the silk screen, and the pins are assigned as
+follows:
+
+Pin	Function
+----------------
+1	V-IO rail
+2	UART Rx (input to the target)
+3	Iota nTESTRESET
+4	JTAG TDI
+5	JTAG TMS
+6	JTAG TCK
+7	UART Tx (output from the target)
+8	JTAG TDO
+9	unused
+10	GND
+11	unused
+12	unused
+
+At one time we had a plan to add Calypso nEMU[1:0] signals to this interface by
+putting them on the last two unused pins, but this addition has been rejected
+for the time being: because we have no documentation for what these nEMU[1:0]
+pins do and all we can do with them are reverse engineering experiments, these
+signals should be kept out of handset products and limited to development boards
+like FCDEV3B for the time being.
+
+There is, however, one critical aspect of this FFC interface which cannot be
+recovered from the Pirelli DP-L10 artifacts and instead has to be defined anew:
+the question of top vs. bottom orientation.  Our decision process in this regard
+begins with the availability of FFC jumpers, i.e., the flat flexible piece that
+goes between the two boards.  The FFC jumper version with same-side contacts is
+readily available from Digi-Key as very inexpensive single pieces, but the
+version with opposite-side contacts is only available with a prohibitely
+expensive MOQ.  Having settled on the FFC jumper with same-side contacts, we
+are left with two options: have the contacts on both sides face upward, or have
+them face downward.  The decision between the two is completely arbitrary and
+we have no way of knowing which way Foxconn had it back in their day, but we
+have to decide one way or the other starting with the design of this adapter
+board.  The Mother's arbitrary decision is to have the contacts on both sides
+of the FFC jumper face upward, meaning that:
+
+* The FFC connector on the FreeCalypso UART+JTAG Adapter board will need to be
+  the top-side contacts version.
+
+* If we are going to populate an FFC connector on a decased Pirelli motherboard
+  in order to exercise our adapter against that pre-existing target, the top-
+  side contacts version will need to be used.  We'll need to do the same if we
+  make our own handset board on which the FFC connector is on the side with the
+  display and the main keypad buttons.
+
+* If we make our own handset board on which the FFC connector is on the bottom
+  side of the motherboard (the side opposite the display), which is the current
+  plan, the connector will need to be the bottom-side contacts version.
+
+Because pin 1 is on the left on the existing target board with the connector on
+the top side (Pirelli DP-L10) and we are using the same-side jumper version that
+flips the left/right orientation, pin 1 will need to be on the right in the
+connector footprint definition on the adapter board.