CSD and GPRS on FCDEV3B with Magnetite

[Mychaela Falconia]

Hi DS,

> It is very cool that you got CSD
> working, this could be used I think for encrypted voice calls

Yes, I've been thinking about using mobile-to-mobile CSD for end-to-end
encrypted voice calls since before I even started working on FreeCalypso
in the earnest.

> although I imagine there would be some difficulty since after
> decryption by the ARM, the bits would have to be passed back to
> the DSP for processing by the audio codec.

Getting my hypothetized encrypted voice over CSD arrangement working
on a Calypso-by-itself phone would indeed be very challenging, and may
or may not be doable.  The most proper way would be to add the
necessary support to the DSP with a downloaded patch, which would
require either finding a surviving copy of the source for the DSP ROM
or spending years to RE this ROM code to the necessary degree, and of
course we don't know if the available DSP RAM space for downloadable
patch codes will be sufficient for the implementation of this feature.

The patch-added DSP feature would be a TCH operation mode in which the
channel encoder works as needed for CSD (different from voice TCH, see
GSM 05.03), the DSP then performs end-to-end encryption on 240-bit
frames using the key supplied by the ARM, and then one of the voice
codecs is hooked into the DSP chain.  It is not certain at all whether
or not the DSP will have enough horsepower to do the end-to-end
encryption in addition to its other required duties (CSD-mode channel
encoder and the voice codec), but if the DSP lacks the needed
horsepower, it will be equally questionable whether or not the ARM7
part can do the job, and as you said, passing bits back and forth
between the DSP and the ARM would be an ugly kludge at best, and would
still require development of a custom DSP patch.

OTOH, my hypothetized arrangement of encrypted voice calls over CSD
should be quite easy and natural to implement on a smartphone like the
Neo FreeRunner, with the Calypso just acting as a modem and providing
transparent CSD service to the AP, and with the AP doing the voice
encryption and codec functions.  Note that the voice codec does not
have to be the same as any of the standard GSM ones, as it will be
inside the end-to-end encrypted pipe and thus no one else's business.

In any case, my first proof-of-concept implementation of the
hypothetized functionality in question will be in the form of a
modem+laptop combo, with the modem simply providing transparent CSD
service and with the laptop doing the rest, using nothing more than
ordinary userspace processes that talk to the modem UART on one end
and to ALSA on the other end.  If we can get the functionality working
in this manner with acceptable quality (latency and dropouts due to
lost or errored frames are questions that can only be answered
empirically), *then* we can start thinking about how we can implement
it in a phone that can be carried in a pocket or purse, but until then
it is premature to fret over DSP vs. ARM, dumbphone vs. smartphone and
so forth.

> Also, having working GPRS is excellent! I am right to assume the
> Calypso Lite (found on the C1xx phones) is not capable of running
> a full GPRS stack due to the amount of SRAM that was halved when
> compared to the full Calypso?

Not quite.  As one example I know of, Mot C155/156 phones use the same
Calypso Lite chip (256 KiB of IRAM) as the lower-end C1xx, but these
higher-end models do have GPRS (I don't remember if it's used for WAP
or MMS, but it has to be something along those lines), and they also
present an AT command interface (with working CSD) on their headset
jack UART.  I'm guessing that they use the IrDA UART for RVTMUX,
appearing on the test point pads in the battery compartment, meant for
a bed-of-nails setup, but I never built one of the latter.

Also we have not yet built a version of FC Magnetite with CSD and GPRS
disabled: in the case of the blob version of G23M we cannot change the
feature configuration at all; in the case of the TCS2/TCS3 hybrid we
now have this ability, but I haven't put together such a config yet.
Thus when we run our current Magnetite fw on a C139, the GPRS stack
and the support for CSD are both there, but they cannot be exercised
because the necessary AT command channel is not brought out anywhere:
because I don't have a fancy bed-of-nails setup and because I am not
willing to solder wires to those pads, I had to use the headset jack
UART for RVTMUX and give up the ASCII AT command channel with CSD and
GPRS.  Similar situation on the Pirelli.

None of it should matter any more now that we have our own FCDEV3B:
for development purposes the FCDEV3B is the proper platform to use,
whereas if we ever produce end user firmware with working UI for the
C139 or for the Pirelli, we are going to build it with CSD, GPRS and
the ASCII AT command interface excluded.  If someone would like a
libre dumbphone that can also dual-function as a modem for laptops
with a full AT command interface with CSD and GPRS included, they will
need to buy our own FreeCalypso Libre Dumbphone hardware, pre-existing
hw won't be good enough for such advanced functionality.

> Of course the small 2MB flash that
> is found on the C118/C123 would be another major blocking factor.

It is not only the small flash, but also the small XRAM: AFAIK all
C11x variants, even those with 4 MiB of flash, have only 256 KiB of
XRAM (plus 256 KiB of IRAM), whereas the C139 has 512 KiB of XRAM.
This difference is crucial: our Magnetite fw with CSD and GPRS enabled
can fit into the available RAM and flash on the C139, but C11x is out
because of the small XRAM, or to put it another way, because the total
amount of RAM (IRAM+XRAM) is too little.

Having much less functionality, our Citrine fw does fit into C11x,
even with the small 2 MiB flash.  It remains to be seen how Magnetite
hybrid will fare once we build a config with FAX_AND_DATA and GPRS
disabled (matching Citrine), but even if it fits in a Citrine-like
pseudo-modem (AT over RVTMUX) config, it won't be useful until we add
the UI, and the latter will likely push us over the mark once again.

In any case I do need to emphasize very strongly that I have absolutely
no interest in twisting over backwards to squeeze our firmware into
crippled Mot C1xx phones.  I don't get paid to work on FreeCalypso,
and it is in my natural economic self-interest to make and sell our
own FreeCalypso hardware, rather than expend oodles of time and energy
writing firmware for old phones made in some sweatshop a decade and a
half ago.  I don't plan on removing any of the already developed
support for Mot C1xx targets, as removing working functionality for no
good reason is not the way of FLOSS, but I don't plan on doing any new
development in that direction.

I *might* produce a usable port of FreeCalypso UI to the C139, *after*
the development of FC UI itself on my desired HSMBP but before turning
the HSMBP into a complete phone with plastics and mechanical design,
simply because making a complete phone with plastics and mech design
will take even more time, effort and money than the previous hw steps
and it would be nice to have something in the interim, but C139 is as
far as I will go: I have absolutely no incentive to make that work
even harder and more unpleasant by targeting C11x/12x.  I am also not
targeting C155/156: even though the latter have more XRAM and flash
and one can get the second UART with a bed-of-nails setup or by
soldering wires to test point pads, they have a ringtone generator
chip which we don't know how to program, and I would rather have a
phone that can ring.

M~