view doc/Leonardo-target @ 660:293c7db5f10f

bmi3: fixed the mysterious "mute on first call" bug When UI-enabled fw boots on a previously blank (no /mmi/* files) FFS for the first time, the output_volume member of the persistent UI settings structure was left uninitialized, corresponding to the earpiece volume being set to mute, which is an invalid setting. Because of other quirks in the far-from-finished UI code, this volume setting takes effect only when the first call is answered, producing the odd behaviour seen at the user level. The current fix is to set the blank-FFS default for output_volume to volume level 4, which is the same -6 dB Iota volume as the ACI default.
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 14 May 2020 02:50:41 +0000
parents 6edd9be81b94
children edaceb78719a
line wrap: on
line source

TI's primary development platform for TCS211 firmware was D-Sample - see our
D-Sample article for explanation of our current limited support for that target
in FC Magnetite - but they also had another platform called Leonardo.  The
primary difference is the RF section: D-Sample had Clara RF (the one for which
we lack support), whereas Leonardo was TI's reference platform for Rita RF and
for the complete Calypso+Iota+Rita chipset.  Another major difference is that
D-Sample was a single stable platform, whereas Leonardo was made in a
bewildering assortment of different variants.

We (FreeCalypso core team) never succeeded in getting our hands on a real
TI-made Leonardo board of any variant, but we do have a Leonardo build target
in FC Magnetite for two reasons:

1) Adding this build target was trivial: our starting hw target for which we
   got our original starting-point fw was Openmoko's embedded GSM/GPRS modem,
   and that modem is a very close derivative of Leonardo.  The only firmware-
   affecting diff between Leonardo and OM's modem is FIC/OM's reshuffling of
   TSPACT control lines for their triband RFFE; producing a build configuration
   with these TSPACT control signals put back into their original Leonardo
   arrangement became trivial once our reconstruction of tpudrv12.c from
   disassembly of tpudrv12.obj reached production quality.

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
===========================

RF bands: there were several Leonardo variants with full quadband RF using Epcos
M034F FEM, and there were several more variants with artifically restricted RF,
using a dual-band/single-region FEM and supporting only the two EU bands.  The
two versions should be firmware-compatible according to our available schematics
(the same TSPACT signals are used for Tx control), thus our Magnetite-Leonardo
fw should run on any Leonardo variant that matches any of our known schematic
versions at least in the principal aspects.

Flash memory: our Magnetite-Leonardo fw supports the following flash chips for
FFS:

4 MiB: Fujitsu MBM29DL320FB or MBM29DL320FT
8 MiB: Am29DL640G or its Fujitsu equivalent, or any MCP containing this flash
16 MiB: Spansion PL129J or its AMD predecessor, second bank on nCS2

If anyone finds a Leonardo variant with some other flash, it may not be
supported out of the box - but our included FFS configs for the Leonardo target
come directly from TI's original TCS211 version (it is highly unlikely that OM
changed anything other than adding their Samsung flash), thus we support
everything that TI's own TCS211 supported out of the box.

Memory size limits
==================

The linker script template we use for target leonardo has memory region size
limits set as follows: 8 MiB of flash, 2 MiB of XRAM and 512 KiB of IRAM.  If
you are working with a Leonardo or Leonardo-compatible board that has smaller
flash or XRAM, or has a Calypso Lite chip with only 256 KiB of IRAM, then you
have to manually ensure that you stay within your actual memory limits, as you
won't get a failing link unless you exceed the larger linker script limits.

If you are building a modem-only fw configuration (l1reconst or hybrid), it
will fit into under 3 MiB of flash (fitting into a 4 MiB flash chip together
with FFS), 512 KiB of XRAM and 256 KiB of IRAM, so you are safe unless you are
going to add a lot of your own code or data space.  But if you are going to
build a UI-enabled fw config (2092 or hybrid-ui), then you will need at least
an 8 MiB flash chip (won't fit into a 4 MiB chip together with FFS) and at least
1 MiB of XRAM.  So far all of our configs fit into 256 KiB of IRAM.

Different Calypso chip versions
===============================

If you specify the build target as just leonardo, your fw will be configured
and built for the leonardo-dsp36 target.  If you actually need leonardo-c05b or
leonardo-dsp34 because your board has an older Calypso chip version on it, then
you will need to specify the build target as just stated - see the
Calypso-version-override article.

Calypso GPIO 2 configuration
============================

On TI's C-Sample and D-Sample boards Calypso GPIO 2 is wired to serve as the DCD
output for the MODEM UART (Calypso device as DCE), and our FC Magnetite firmware
drives it as such on D-Sample, FCDEV3B and GTM900 targets.  But this same config
does NOT apply to Leonardo: on the latter boards GPIO 2 is wired in a way that
requires it to be configured as an input to Calypso, not an output.

TI's TCS211 firmware had this Leonardo GPIO 2 situation handled in a very
bizarre manner: the main GPIO init code in AI_InitIOConfig() in armio.c made no
differentiation between D-Sample and Leonardo and configured GPIO 2 as an
output, then the init code in uartfax.c did the same setup again, but at the
end of the Init_Serial_Flows() function in the init module (which we only got
as init.obj, with init.c censored out) they inserted a bit of code that switches
GPIO 2 to be an input.  What a mess.

Our handling of this GPIO 2 situation in FC Magnetite is much cleaner: we have
put an #ifndef CONFIG_TARGET_LEONARDO around the AI_ConfigBitAsOutput(2) call
in AI_InitIOConfig() so this GPIO line never becomes an output in the first
place, and our targets/leonardo.h configuration header defines
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
=================================

Our Magnetite-Leonardo fw is unchanged from TI's TCS211 original in that GPIO0,
TSPDI/GPIO4 and DSR_MODEM/LPG pins are left configured as inputs, even though
the schematics we've got show GPIO0 as an output and the other two pins as
unconnected, in which case they should also be configured as outputs in order
to not float.  We are leaving this aspect unchanged currently because this
Magnetite-Leonardo fw build target is really just a reference for practically
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.