--- a/doc/Leonardo-target	Sat Jan 04 20:12:07 2020 +0000
+++ b/doc/Leonardo-target	Sat Jan 04 20:48:07 2020 +0000
@@ -20,11 +20,14 @@
    arrangement became trivial once our reconstruction of tpudrv12.c from
    disassembly of tpudrv12.obj reached production quality.
 
-2) We are currently evaluating a certain third-party (non-TI) development board
-   which strongly appears to be a very close derivative of Leonardo, even closer
-   than Openmoko.  We are hoping to get one of these boards into Mother
-   Mychaela's lab some time in 2020-01, at which time we will try running our
-   Magnetite-Leonardo fw on it.
+2) At the end of 2019 we discovered a certain modem module which we call Tango,
+   and this Tango module is essentially a mass-produced version of TI's Leonardo
+   core.  Tango is just the core of Leonardo, without any peripherals, thus a
+   proper fw build target for any given Tango-based platform is going to be a
+   little different from Leonardo in terms of GPIO and other peripheral config
+   (see our tangomdm target), but initially we ran our Magnetite-Leonardo fw
+   (built for target leonardo) on our Caramel board - it runs just fine except
+   for GPIO config being slightly wrong, leaving a few GPIO lines floating.
 
 Supported Leonardo variants
 ===========================
@@ -101,6 +104,11 @@
 UARTFAX_CLASSIC_DTR_DCD to 0 on this target, disabling that code in the
 uartfax.c driver.
 
+This peculiar GPIO 2 situation applies only to real Leonardo boards, not to
+Tango modems: a custom design using a Tango module can use this GPIO line for
+anything, but on Caramel boards it drives RS-232 DCD like on D-Sample and thus
+should be configured as a Calypso output.
+
 Other GPIO and multifunction pins
 =================================
 
@@ -113,3 +121,15 @@
 non-existent hw, and given the unknown of what other Leonardo variants may have
 existed once beyond our known schematics, we would rather leave a few floating
 inputs than risk causing a driver conflict on some unknown board.
+
+In the case of Tango these 3 just-mentioned Calypso signals are contained inside
+the module (not brought out), and it is currently unknown if they are simply
+unconnected or if perhaps they are tied to either GND or V-IO inside the module.
+The Tango manuf's original fw leaves these signals in their power-up default as
+Calypso inputs, hence we do the same currently in order to not risk causing a
+short.  At some later time when our finances allow doing so, we may send a
+sacrificial Tango module for destructive PCB reverse eng and see what is really
+done with these Calypso signals - if they are really unconnected, then we can
+change the code to switch them to outputs, just like we have done for the
+gtamodem target where the original manuf's official fw also left a bunch of
+floating inputs.