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~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
