diff doc/Compiling @ 109:a68c6c7942d7

doc: basic build documentation written
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 24 Jul 2018 23:55:24 +0000
parents
children 4238e3220682
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/Compiling	Tue Jul 24 23:55:24 2018 +0000
@@ -0,0 +1,223 @@
+Selecting and preparing the compiler environment
+================================================
+
+FreeCalypso Selenite firmware can be built with two different compiler
+toolchains: either with TI's original TMS470 compiler or with gcc.  Transition
+to compiling with gcc is a very bold move with very heavy fallout, and many
+parts of the fw are still broken or destabilized when built with gcc instead of
+the original compiler they were developed with, thus for the foreseeable future,
+anyone who aspires to be a FreeCalypso developer will need to compile our fw in
+both ways, compare the behaviour of the two versions, and work toward making
+the gcc-built version perform as well as the TMS470-built one.  Thus you need
+to have both compiler toolchains installed and working - see the
+Toolchain-setup-470 and Toolchain-setup-gcc articles for the instructions.
+
+Compiling the local helper utilities
+====================================
+
+(cd helpers; make)
+
+Do the above.  Most of the build helper scripts used in the FC Selenite build
+system are written in Bourne shell, but a few were easier to implement in C.
+You need to compile these C helper utilities before you can run an actual FC
+Selenite firmware build, but these utilities are totally ad hoc and specific
+to the needs of our fw build system, hence they are not meant to be installed
+globally on your system - instead they stay within the fc-selenite tree.  You
+just need to run make in the helpers directory once before any actual firmware
+builds.
+
+Actually building the firmware
+==============================
+
+To build our FC Selenite firmware for your hw target of interest in the default
+configuration, run a command like this from the top level of the fc-selenite
+tree:
+
+./configure-gcc.sh fcdev3b
+
+or
+
+./configure-tms470.sh fcdev3b
+
+As of this writing, the following hardware targets are supported:
+
+c11x		Motorola C11x/12x
+c139		Motorola C139/140
+fcdev3b		FreeCalypso FCDEV3B
+gtamodem	The Calypso GSM/GPRS modem in Openmoko GTA01/02 smartphones
+pirelli		Pirelli DP-L10
+
+Notice the difference from FC Magnetite: there is no "configuration name"
+argument after the target name.  Because FC Selenite does not include any UI
+code (modem functionality only) and does not offer different versions of
+various fw components the way Magnetite does, it does not have named
+configurations in the same sense as Magnetite.  Instead any configuration
+tweaks are done via var=value optional arguments on the configure command line
+after the required target name argument; the following variables are currently
+available for tweaking:
+
+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.
+
+FCHG_STATE
+
+	This setting enables or disables the FCHG battery charging driver.  By
+	default it is enabled on targets that have battery charging hardware
+	(c11x, c139, pirelli) and disabled on those that don't have such hw
+	(fcdev3b, gtamodem).
+
+GPRS
+
+	Self-explanatory: enables or disables GPRS.  By default GPRS is enabled
+	on proper modem hw targets (fcdev3b and gtamodem) and disabled on c11x,
+	c139 and pirelli.
+
+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.
+
+MEMSUPER
+
+	This setting enables the memory supervision feature in TI's GPF and in
+	the G23M protocol stack built on top of it.  This code has not been
+	properly studied yet; play with it at your own risk.
+
+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.
+
+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
+
+	The default is SRVC=1 (fax and data enabled) for proper modem hw targets
+	(fcdev3b and gtamodem) and SRVC=0 (voice and SMS only) on c11x, c139
+	and pirelli.
+
+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:
+
+	L1_DYN_DSP_DWNLD=0 SUFFIX=-nodyn
+	MELODY_E2=0 SUFFIX=-noe2
+	MEMSUPER=2 SUFFIX=-ps
+	SERIAL_DYNAMIC_SWITCH=1 SUFFIX=-sds
+	SPEECH_RECO=0 SUFFIX=-nosr
+	TR_BAUD_CONFIG=TR_BAUD_812500 SUFFIX=-812500
+
+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.
+
+Each configuration is built in its own directory; the name of this build
+directory always begins with build- and is constructed to reflect the
+configuration.  The auto-generated build directory name includes the name of
+the target, the selection of services to be included based on the GPRS, SRVC
+and FCHG_STATE variables, and a -470 or -gcc suffix indicating the compiler
+toolchain, but if you manually override any of the other config variables
+described above, you should also include a SUFFIX=-xxx argument giving an
+identifying suffix for your own configuration changes.
+
+To actually compile the firmware, cd into the created build directory and run
+make there.  With gcc the build proceeds very fast because the compiler runs
+natively, but building with the original TMS470 compiler requires going through
+Wine, which is much slower.  There is, however, a trick to speed up these
+TMS470 builds: if you run some other Wine program that stays open and does not
+exit on its own (e.g., wine cmd) in another window and leave it open while you
+run your Selenite TMS470 build, the build will proceed much faster - the
+presence of another Wine process using the wineserver environment will keep
+Wine from shutting this environment down and restarting it for every individual
+cl470 run, i.e., for each individual C source file.
+
+When the build is done, the flashable firmware image will be in fwimage.bin.
+This image is to be flashed with fc-loadtool at address 0x10000 on Mot C11x and
+C139 targets, and at address 0 on the more sensible targets that have the
+Calypso boot ROM enabled.  The build system also produces a short text file
+named flash-script which is a flashing command script for fc-loadtool that
+erases the correct range of flash sectors and then programs fwimage.bin at the
+right address.
+
+When building firmware for the FCDEV3B or for the Pirelli, one can build either
+a flashable image or a RAM-loadable one - or both.  Because this part of the
+build system is common with other targets for which only flash images can be
+produced, the Makefile always builds the flashable image by default -
+fwimage.bin is always meant for flash and never for RAM.  To build a RAM-
+loadable image when the target allows it, run 'make ram' - the image will be in
+ramimage.srec, which you can then load and run on the target with FreeCalypso
+host tool fc-xram.
+
+Running on the hardware
+=======================
+
+In order to run the firmware you have built on your FCDEV3B or other Calypso
+device (flash or run in RAM as appropriate), you will need to use FreeCalypso
+host tools.  As of this writing, the latest packaged release is this one:
+
+ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/fc-host-tools-r8.tar.bz2