view doc/Tango-pinmux @ 685:3fb7384e820d

tpudrv12.h: FCDEV3B goes back to being itself A while back we had the idea of a FreeCalypso modem family whereby our current fcdev3b target would some day morph into fcmodem, with multiple FC modem family products, potentially either triband or quadband, being firmware-compatible with each other and with our original FCDEV3B. But in light of the discovery of Tango modules that earlier idea is now being withdrawn: instead the already existing Tango hw is being adopted into our FreeCalypso family. Tango cannot be firmware-compatible with triband OM/FCDEV3B targets because the original quadband RFFE on Tango modules is wired in TI's original Leonardo arrangement. Because this Leonardo/Tango way is now becoming the official FreeCalypso way of driving quadband RFFEs thanks to the adoption of Tango into our FC family, our earlier idea of extending FIC's triband RFFE control signals with TSPACT5 no longer makes much sense - we will probably never produce any new hardware with that once-proposed arrangement. Therefore, that triband-or-quadband FCFAM provision is being removed from the code base, and FCDEV3B goes back to being treated the same way as CONFIG_TARGET_GTAMODEM for RFFE control purposes.
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 24 Sep 2020 21:03:08 +0000
parents 52ee171ff5e4
children
line wrap: on
line source

FreeCalypso Tango is a Calypso core module with the special quality of having
many Calypso signals brought out on the user interface connector.  Out of the
great many Calypso signals that are brought out, the following 8 pins are
subject to functional multiplexing concerns:

GPIO1
GPIO2
GPIO3
RESET_OUT/GPIO7
MCSI_TXD/GPIO9
MCSI_RXD/GPIO10
MCSI_CLK/GPIO11
MCSI_FSYNCH/GPIO12

All 8 are capable of functioning as GPIOs, meaning that a Tango-based custom
application board designer can use them for whatever purpose they like, but
some of them can also be configured as dedicated Calypso peripheral pins,
particularly MCSI.  Others (GPIO1-3) have software-defined conventional
functions based on long-standing tradition.

The special complication that arises for our firmware with regard to these GPIO
and multifunction pins is that it is not our place as the firmware vendor to
dictate to our potential customers how they should wire these pins on their
boards.  Instead an FC Tango customer should be able to wire up their board as
their application calls for, subject to constraints imposed by hardware (not by
firmware!), and our standard fw needs to work with every reasonable possibility
for user wiring of our GPIO and multifunction pins.  The following practical
cases need to be addressed:

* If a customer chooses to use any of our GPIOs as an input, feeding some
external output to it, there needs to be a way to tell our fw to leave that GPIO
as an input and not switch it to an output.

* Conversely, if a given GPIO or multifunction pin is unused or not needed in a
given application, the app board designer should have the freedom to either tie
it off or leave it unconnected.  If some of our GPIO or multifunction pins are
left unconnected, this fact needs to be communicated to our fw so it can
configure them as dummy outputs, preventing floating inputs.

* Some applications will use MCSI, while others won't.  If a given application
does not use MCSI, the 4 pins (or any subset of them) can be used as GPIOs,
either inputs or outputs, or the unused pins may be left unconnected.

* GPIO3 is traditionally defined (by conventions going back to TI) as DTR input
- but not every application will have a sensible DTR signal to feed to this pin.
If there is no DTR signal in a given application, the app board designer should
be able to either use GPIO3 for some unrelated purpose, or leave it unconnected.

* GPIO2 is similarly defined as DCD output by the same traditional conventions.
Because it is an output from Calypso, it can be simply ignored and left
unconnected if it is not needed - but a user should also be able to use the GPIO
for unrelated purposes.

* There exist several historical conventional functions for GPIO1 output:
loudspeaker control (D-Sample, Leonardo, FCDEV3B), Openmoko's application
processor wake-up signal, or RI modem control output.  We allow any of these
options, plus other arbitrary uses.

FreeCalypso solution
====================

Our solution for firmware build target tangomdm (standard shipping fw for Tango
modems) is that our fw will look on boot for a file in FFS named
/etc/tango-pinmux; it will be a binary file of 4 bytes, defining pin
multiplexing configuration as follows:

Byte 0: GPIO1 config

The following values are defined:

0x00: GPIO1 is left as an input from power-up
0x80: GPIO1 is switched to an output, initial value 0
0x81: GPIO1 is switched to an output, initial value 1
0x82: GPIO1 is wake-up output per Openmoko GTA01/02 convention
0x83: GPIO1 is RI output

Byte 1: GPIO2 and GPIO3 config

Bit 7: if 1, GPIO3 is DTR input, other bits in this nibble ignored
       if 0, GPIO3 is a "generic" GPIO (undefined function) per bits 5 and 4
Bit 5: if 1, GPIO3 is an output, otherwise it's an input
Bit 4: initial output value if GPIO3 is an output

Bit 3: if 1, GPIO2 is DCD output, other bits in this nibble ignored
       if 0, GPIO2 is a "generic" GPIO (undefined function) per bits 1 and 0
Bit 1: if 1, GPIO2 is an output, otherwise it's an input
Bit 0: initial output value if GPIO2 is a generic (not DCD) output

Byte 2: Peripheral pin mux config

Bit 7: if 0, MCSI pins retain their default power-up functions
       if 1, MCSI pins are switched to being GPIOs

Bit 3: if 0, RESET_OUT pin retains its default power-up function
       if 1, RESET_OUT pin is switched to being GPIO7
Bit 1: if 1, GPIO7 is an output, otherwise it's an input
bit 0: initial output value of GPIO7

Byte 3: I/O config of MCSI pins turned into GPIOs

This byte will be considered only if Byte 2 Bit 7 is set to 1, and will be
ignored otherwise.

Bit 7: GPIO12 direction: 1 means output, 0 means input
Bit 6: GPIO11 direction: 1 means output, 0 means input
Bit 5: GPIO10 direction: 1 means output, 0 means input
Bit 4: GPIO9 direction: 1 means output, 0 means input

Bit 3: GPIO12 initial output value
Bit 2: GPIO11 initial output value
Bit 1: GPIO10 initial output value
Bit 0: GPIO9 initial output value

If the /etc/tango-pinmux file is missing, the effect will be the same as if all
four bytes are equal to zero: GPIO1-3 will be functionally-undefined inputs,
RESET_OUT/GPIO7 will be left as RESET_OUT from power-up, and all 4 MCSI pins
will be likewise left in their power-up default MCSI function.

Any GPIO that is configured as an input can be read with AT+IOR, and any GPIO
that is configured as a generic (not built-in function) output can be set with
AT+IOW.

Other GPIO pins
===============

Calypso pins GPIO0, TSPDI/GPIO4, BCLKX/GPIO6, MCUEN1/GPIO8 and MCUEN2/GPIO13
are not brought out externally on Tango modules, thus they don't need to be
considered.  Our fw configures them as dummy outputs to prevent floating inputs.