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.