FreeCalypso > hg > fc-magnetite
view doc/Config-vars @ 600:8f50b202e81f
board preprocessor conditionals: prep for more FC hw in the future
This change eliminates the CONFIG_TARGET_FCDEV3B preprocessor symbol and
all preprocessor conditionals throughout the code base that tested for it,
replacing them with CONFIG_TARGET_FCFAM or CONFIG_TARGET_FCMODEM. These
new symbols are specified as follows:
CONFIG_TARGET_FCFAM is intended to cover all hardware designs created by
Mother Mychaela under the FreeCalypso trademark. This family will include
modem products (repackagings of the FCDEV3B, possibly with RFFE or even
RF transceiver changes), and also my desired FreeCalypso handset product.
CONFIG_TARGET_FCMODEM is intended to cover all FreeCalypso modem products
(which will be firmware-compatible with the FCDEV3B if they use TI Rita
transceiver, or will require a different fw build if we switch to one of
Silabs Aero transceivers), but not the handset product. Right now this
CONFIG_TARGET_FCMODEM preprocessor symbol is used to conditionalize
everything dealing with MCSI.
At the present moment the future of FC hardware evolution is still unknown:
it is not known whether we will ever have any beyond-FCDEV3B hardware at all
(contingent on uncertain funding), and if we do produce further FC hardware
designs, it is not known whether they will retain the same FIC modem core
(triband), if we are going to have a quadband design that still retains the
classic Rita transceiver, or if we are going to switch to Silabs Aero II
or some other transceiver. If we produce a quadband modem that still uses
Rita, it will run exactly the same fw as the FCDEV3B thanks to the way we
define TSPACT signals for the RF_FAM=12 && CONFIG_TARGET_FCFAM combination,
and the current fcdev3b build target will be renamed to fcmodem. OTOH, if
that putative quadband modem will be Aero-based, then it will require a
different fw build target, the fcdev3b target will stay as it is, and the
two targets will both define CONFIG_TARGET_FCFAM and CONFIG_TARGET_FCMODEM,
but will have different RF_FAM numbers. But no matter which way we are
going to evolve, it is not right to have conditionals on CONFIG_TARGET_FCDEV3B
in places like ACI, and the present change clears the way for future
evolution.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 01 Apr 2019 01:05:24 +0000 |
parents | 29c0be5a1962 |
children | b7b809c62586 |
line wrap: on
line source
The following Bourne shell variables can be set on the ./configure.sh command line to tweak the firmware build configuration: ALLOW_CSIM_GSM Per TI's original design, the AT+CSIM command does not allow GSM APDUs of class 0xA0. Openmoko found some need for them, and they patched their modem fw to allow these APDUs with AT+CSIM. With our new hybrid modem fw this policy setting is configurable at build time; the default is ALLOW_CSIM_GSM=1 (GSM APDUs allowed). DISABLE_SLEEP The general default is DISABLE_SLEEP=0, and the firmware automatically enables all of the chipset's available sleep modes on boot. Setting DISABLE_SLEEP=1 causes all sleep modes to be disabled by default on boot (they can still be enabled with the AT%SLEEP command); this setting is needed for FCDEV3B V1 boards that have a hardware bug that causes breakage when sleep modes are enabled. DSAMPLE_FULL_COLOR When the firmware's R2D component (normally present only in UI-enabled builds) is built for any target other than c139, one of TI's D-Sample framebuffer drivers is enabled: either color or B&W. (The actual hardware pokes are omitted when the build target is anything other than dsample, but the framebuffer is still maintained in RAM.) By default the color framebuffer driver is enabled; setting DSAMPLE_FULL_COLOR=0 switches to the B&W framebuffer driver. L1_DYN_DSP_DWNLD This setting enables TI's dynamic DSP patch download mechanism. When the firmware is built for a Calypso target with DSP ROM version 36 in the silicon (all FreeCalypso-made hw and most of the supported legacy targets), L1_DYN_DSP_DWNLD is enabled by default and needs to be kept enabled for correct operation: the patch code we got from TI for this ROM is the dynamic download version, and the ARM-side L1 code expects all of these patches to be present, both the static part and the dynamic parts. However, one can build our fw with L1_DYN_DSP_DWNLD=0 for experimental testing, to see what breaks when the dynamic patches are omitted. L1_VOICE_MEMO_AMR This setting enables or disables support in L1 and in the RiViera Audio Service for AMR voice memo recording and playback. This code has not been properly studied yet and no test AT commands are provided for it, but it is enabled by default like in TI's original TCS211 fw. MELODY_E2 This setting enables or disables support in L1 and in the RiViera Audio Service for playing E2-format melodies. The default is MELODY_E2=1 like in TI's original TCS211 fw. Note that Melody E1 support is always enabled; setting MELODY_E2=0 disables only Melody E2, but not E1. RVTMUX_ON_MODEM This setting configures the usage of Calypso UARTs. RVTMUX_ON_MODEM=0 puts the AT command interface on the MODEM UART and RVTMUX on the IrDA UART (TI's intended config and the default on sensible hw targets); RVTMUX_ON_MODEM=1 (default on the crippled C1xx targets) puts RVTMUX on the MODEM UART, sacrificing the standard AT command interface. SERIAL_DYNAMIC_SWITCH TI's TCS211 fw includes a provision (only for Bluetooth-enabled fw in TI's original) to switch one UART between the AT command interface and RVTMUX while the other UART is fixed for Bluetooth. In FreeCalypso we have changed this code to work without Bluetooth, for the purpose of switching the user-facing MODEM UART between AT commands and RVTMUX, but the mechanism does not work properly yet and is disabled by default. Enable it with SERIAL_DYNAMIC_SWITCH=1 if you would like to play with it. SPEECH_RECO This setting enables or disables support in L1 and in the RiViera Audio Service for TI's speech recognition mechanism. This code and the underlying DSP facility itself have not been properly studied yet and no test AT commands are provided for it, but it is enabled by default like in TI's original TCS211 fw. SUFFIX This setting is solely for configuration management. If you make a build with any of the settings described in this document changed from the default, you should also pass a SUFFIX=-xxx argument so your special build will be appropriately identified in the build directory name and in the firmware version ID string compiled into the image. The naming of suffixes is up to you, but here are some examples: DISABLE_SLEEP=1 SUFFIX=-nosleep DSAMPLE_FULL_COLOR=0 UI_CONFIG=bigbw SUFFIX=-bw L1_DYN_DSP_DWNLD=0 SUFFIX=-nodyn MELODY_E2=0 SUFFIX=-noe2 SERIAL_DYNAMIC_SWITCH=1 SUFFIX=-sds SPEECH_RECO=0 SUFFIX=-nosr TR_BAUD_CONFIG=TR_BAUD_812500 SUFFIX=-812500 USE_STR2IND=1 SUFFIX=-s2i TRACEMASK_IN_FFS TI's Test Interface (TIF) component in the GPF realm includes an optional feature for saving trace masks in FFS, but TI's production firmwares had it disabled. We have now switched to recompiling the component in question from source, but we still keep this TRACEMASK_IN_FFS code disabled by default, at least for now. Set TRACEMASK_IN_FFS=1 to enable this code in GPF. TR_BAUD_CONFIG The value of this symbol is an alphanumeric keyword of the form TR_BAUD_xxxxxx; the default is TR_BAUD_115200. See src/cs/drivers/drv_core/uart/traceswitch.h for the available baud rate choices; the most practical use is setting TR_BAUD_CONFIG=TR_BAUD_812500 when you need to run the RVTMUX serial channel at the maximum possible baud rate. UI_CONFIG The 3 allowed values for this setting are bigcolor, bigbw and 84x48, selecting one of the 3 UI configurations supported by TI's code. The default is 84x48 when the firmware is built for target c11x or c139 or c155, and bigcolor otherwise. USE_STR2IND Unlike TI's original firmwares, we build without str2ind by default. You can enable str2ind with USE_STR2IND=1, but the time to build the fw will be significantly longer as the compiler has to be run twice for each C source file, with str2ind sandwiched in between. The following Bourne shell variables are used inside the build system in the individual component build recipes (components/*) but cannot be set on the ./configure.sh line because they are fixed in the overall fw build recipes (configs/*): GPRS Self-explanatory: enables or disables GPRS. MMI TI's original config variable: MMI=0 for the AT-command-controlled modem configuration or MMI=2 for the UI-enabled configuration with BMI and MFW. SRVC TI's original config variable, selects the presence or absence of data services other than GPRS as follows: SRVC=0: voice and SMS only SRVC=1: CSD and fax enabled SRVC=2: CSD enabled, but not fax Finally, CHIPSET, DSP, RF and AMR variables reflect the physical configuration of the selected target hw that no amount of software hacking can change. (The AMR variable indicates the presence or absence of AMR support in the DSP.)