FreeCalypso > hg > fc-magnetite
view doc/Modem-configs @ 364:44795dbadbae
FCHG: bug in CV process caused the control loop to be skipped
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 30 Dec 2017 06:10:48 +0000 |
parents | e60d7a32ae2a |
children | e80e43185ca1 |
line wrap: on
line source
Modem configurations ==================== If you would like to build our Magnetite firmware in the AT-command-controlled modem configuration (not the C-Sample UI demo on the Mot C139), you have 3 specific configurations to choose from, differing in the level of deblobbing: classic This configuration replicates classic TCS211, just like leo2moko from 2013. Almost all of the original binary blob libraries are used; the only components that are recompiled from source are those which we got in source form with our copy of TCS211 from Sotovik. This config can only be built for the fcdev3b and gtamodem targets, not for c139 or pirelli. l1reconst In this configuration the Layer1 component of the firmware (which came as a blob in our copy of TCS211) is recompiled from reconstructed source, and the same is done for the system initialization code in main.lib. The entire chipsetsw division of the firmware (now in src/cs) is thus recompiled from source, either original or reconstructed, and the only components that are used as blobs are the G23M PS, GPF and Nucleus. This config can be built for all targets. hybrid This configuration is a TCS2/TCS3 hybrid. Instead of using the TCS211 version of the G23M protocol stack which we got only as binary blobs, this config uses the G23M PS version from the TCS3.2/LoCosto source, backported to work with L1 and the fw foundation layers from TCS211. ACI also had to be replaced with the TCS3 version, and a special hybrid version of the cdginc headers had to be constructed. L1 and the init code are also deblobbed as in l1reconst. Like l1reconst, this config can be built for all targets, and it is currently the most deblobbed (closest to full source) Magnetite config: the only remaining blobs are GPF and Nucleus. All 3 of the above configurations have CSD, fax and GPRS enabled; this functionality can only be exercised on those hardware targets on which both Calypso UARTs are brought out, with the MODEM UART presenting a standard ASCII AT command interface including data functions, while the IrDA UART carries the RVTMUX interface for debug trace and other development functions. If you are interacting with your Calypso target modem or pseudo-modem solely through RVTMUX, without access to the ASCII AT command interface on the dedicated MODEM UART, then the data functions of the firmware are inaccessible and act as dead weight. Having fully deblobbed all of L1, we are now in a position where we can build a hybrid config with GPRS and/or FAX_AND_DATA excluded, but I (Mychaela) would like to thoroughly exercise the hybrid config in its current everything-enabled state before making further changes to it. The deblobbing of L1 has been done in a very meticulous manner, ensuring that each individual reconstructed C module compiles into a strict functional equivalent of the original binary blob, sometimes even matching bit for bit - thus no regressions are expected with the classic->l1reconst transition, and no extensive testing is deemed necessary beyond the basic tests that have already been done. However, the transition from l1reconst to hybrid involves wholesale replacement of two major firmware components (G23M PS and ACI) and some important associated support pieces with entirely different versions from a different TI program, hence extensive testing and debugging will be needed. So far the most-deblobbed hybrid config looks very promising: after fixing the hideous bug resulting from the addition of A5/3 support in TCS3.2 (hardware feature available on LoCosto but not on Calypso), voice calls work perfectly, both with the legacy codecs and with AMR! (The same A5/3 bugfix has also been applied to our Citrine fw, hence the latter now has working voice calls too.) However, it is almost certain that there are a ton of minor bugs which need to be shaken out, hence this firmware build config should be treated as experimental for the time being, not production.