FreeCalypso > hg > fc-magnetite
view doc/Calypso-version-override @ 636:57e67ca2e1cb
pcmdata.c: default +CGMI to "FreeCalypso" and +CGMM to model
The present change has no effect whatsoever on Falconia-made and Openmoko-made
devices on which /pcm/CGMI and /pcm/CGMM files have been programmed in FFS
with sensible ID strings by the respective factories, but what should AT+CGMI
and AT+CGMM queries return when the device is a Huawei GTM900 or Tango modem
that has been converted to FreeCalypso with a firmware change? Before the
present change they would return compiled-in defaults of "<manufacturer>" and
"<model>", respectively; with the present change the firmware will self-identify
as "FreeCalypso GTM900-FC" or "FreeCalypso Tango" on the two respective targets.
This firmware identification will become important if someone incorporates an
FC-converted GTM900 or Tango modem into a ZeroPhone-style smartphone where some
high-level software like ofono will be talking to the modem and will need to
properly identify this modem as FreeCalypso, as opposed to some other AT command
modem flavor with different quirks.
In technical terms, the compiled-in default for the AT+CGMI query (which will
always be overridden by the /pcm/CGMI file in FFS if one is present) is now
"FreeCalypso" in all configs on all targets; the compiled-in default for the
AT+CGMM query (likewise always overridden by /pcm/CGMM if present) is
"GTM900-FC" if CONFIG_TARGET_GTM900 or "Tango" if CONFIG_TARGET_TANGO or the
original default of "<model>" otherwise.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Sun, 19 Jan 2020 20:14:58 +0000 |
| parents | 9f19cc5e46e8 |
| children |
line wrap: on
line source
TI's TCS211 program supported 3 different Calypso silicon versions on their D-Sample and Leonardo boards: C05B (CHIPSET 8, DSP 33), early C035 (CHIPSET 10, DSP 34) and final C035 (CHIPSET 10, DSP 36). In FreeCalypso we generally work only with the last chipset (final C035), but we also support the two earlier ones to a good extent. C05B has been partially exercised on the Mother's D-Sample board (non-functional Clara RF, no genuine tpudrv10.c source and too many unknowns, but at least some of the DSP-based audio services work), whereas Calypso C035 with DSP 34 has been tested and found to work on a specially modified FCDEV3B board - see the FCDEV3B-751774 article. All 3 Calypso chip versions in question are footprint-compatible, i.e., they can all be populated onto the same PCB. Changing between C05 and C035 requires changing the VLRTC strapping on the Iota companion chip, thus not all boards can support Calypso C05 (the newer ones are C035 only), but one can always populate either early C035 (DSP 34) or final C035 (DSP 36) on the same PCB. TI's own D-Sample and Leonardo development boards have most certainly been made with all 3 Calypso silicon versions: D-Sample appears to support both C05 and C035 on the same PCB; the schematics we have for Leonardo show fixed VLRTC strapping for C035, but there also existed an earlier Leonardo version with Calypso C05B. Our own FCDEV3B also has fixed C035-only VLRTC strapping, our regular boards have final C035 chips on them, but we have put a D751774AGHH chip on one experimental board for DSP 34 testing. In the case of target boards that can have different Calypso chip versions populated on them, we want to be able to target all of them without creating a configuration explosion. The implemented solution is that you can pass a target argument to the ./configure.sh script of the following form: dsample-c05b dsample-dsp34 dsample-dsp36 leonardo-c05b leonardo-dsp34 leonardo-dsp36 fcdev3b-dsp34 Our configure.sh script recognizes the hyphen as indicating this construct; the word before the hyphen must be the conventional target name, and the word after the hyphen needs to be one of c05b, dsp34 or dsp36, corresponding to the three supported Calypso silicon versions.