FreeCalypso > hg > freecalypso-sw
comparison doc/Pirelli-Howto @ 896:7c5b129573f6
doc/Pirelli-Howto written
author | Space Falcon <falcon@ivan.Harhan.ORG> |
---|---|
date | Wed, 01 Jul 2015 06:03:24 +0000 |
parents | |
children | 7d3f0910aeb2 |
comparison
equal
deleted
inserted
replaced
895:1fa8ada742ff | 896:7c5b129573f6 |
---|---|
1 How to play with FreeCalypso GSM firmware on a Pirelli DP-L10 | |
2 ============================================================= | |
3 | |
4 Our experimental FC GSM fw can now run on the Pirelli DP-L10 target. Our fw | |
5 cannot yet operate this phone in a useful manner, i.e., it is not currently | |
6 possible to replace Pirelli's proprietary fw with ours and use the phone as an | |
7 end user. Our gsm-fw is close to having working voice call functionality when | |
8 controlled by an external host via AT commands, but we haven't even started | |
9 working on the on-board user interface part yet. | |
10 | |
11 One very useful special feature of the Pirelli DP-L10 is its very large RAM: | |
12 8 MiB. Having such large RAM allows us to run our experimental fw on this | |
13 target entirely from RAM, without touching the flash. When you compile a | |
14 FreeCalypso gsm-fw image for the Pirelli target, by default a ramImage will be | |
15 built instead of a flashImage. It is possible to build a flashable image of | |
16 the fw in the same configuration and program it into flash with fc-loadtool, | |
17 but doing so is not recommended: our current fw has no battery management code, | |
18 so the charging hardware circuit will never be enabled and the battery will | |
19 discharge even with a USB power source connected; keeping Pirelli's original | |
20 fw in flash will allow the phone to charge its battery and otherwise function | |
21 normally when you are not in the middle of a FreeCalypso firmware experiment. | |
22 | |
23 If you are ready to play with our experimental GSM pseudo-modem fw on your | |
24 Pirelli, the steps are as follows: | |
25 | |
26 1. Build the firmware in the pirelli-gsm configuration - see the Compiling | |
27 document for more details. | |
28 | |
29 2. Connect a USB cable from your GNU/Linux PC/laptop to the phone. If the | |
30 phone was off but the battery is present, it will go through a charger-plug | |
31 power-on event; if the flash contains Pirelli's original fw, it will boot in | |
32 the charging mode. If the battery is not present, the Calypso won't power | |
33 on (it needs VBAT and can't run on VCHG power instead), but the /dev/ttyUSBx | |
34 device will still show up, as the CP2102 USB-serial chip inside the phone is | |
35 powered strictly from the USB side. | |
36 | |
37 3. Run a command like the following: | |
38 | |
39 fc-xram -h pirelli /dev/ttyUSB0 finlink/ramImage.srec rvinterf | |
40 | |
41 Adjust the paths to your /dev/ttyUSBx device and your ramImage.srec as | |
42 appropriate, and add rvinterf logging or other options as desired. | |
43 Specifying rvinterf on the fc-xram command line directs fc-xram to exec | |
44 rvinterf and pass the serial channel to it immediately as soon as the code | |
45 image has been loaded into target RAM and jumped to; this direct passing of | |
46 the serial channel from fc-xram to rvinterf is appropriate because the | |
47 loaded fw will immediately start emitting binary trace packets in TI's RVTMUX | |
48 format. | |
49 | |
50 4. Induce the phone to execute its Calypso boot path: if the battery was | |
51 removed, insert it now; if Pirelli's regular fw is running, execute its | |
52 power-off sequence. | |
53 | |
54 Once the Calypso chip in the Pirelli phone executes its boot path with fc-xram | |
55 running, the boot path will be diverted and our experimental firmware will be | |
56 loaded into target device RAM and jumped to. Our fw will now run, and the | |
57 rvinterf process on the host will maintain communication with it. | |
58 | |
59 To exercise our firmware further, you will need to open another terminal window | |
60 on your driving PC/laptop and run fc-shell. This program will connect to the | |
61 already running rvinterf process via a local socket, and it will enable you to | |
62 send various commands to the running fw on the target, the most important ones | |
63 being standard AT commands. Send the following sequence of AT commands to | |
64 bring up GSM functionality: | |
65 | |
66 AT%SLEEP=2 -- disable deep sleep (doesn't work yet) | |
67 AT+CMEE=2 -- enable verbose error responses | |
68 AT+CFUN=1 -- enable radio and SIM interfaces | |
69 AT+COPS=0 -- register to the default GSM network | |
70 | |
71 Our fw is currently able to exercise all SIM interface functions (at least the | |
72 obvious ones which I've tested), register with a live commercial GSM network | |
73 using a legitimate SIM, and send and receive SMS using standard GSM 07.05 AT | |
74 commands. Voice calls don't work yet; dialing a MO call with the ATD command | |
75 or placing a MT call to the device under test from the network side results in | |
76 the firmware going haywire. The latter misbehaviour is next to be investigated | |
77 and (hopefully) fixed. | |
78 | |
79 When you are done playing with our experimental fw, you can either yank the | |
80 battery and kill the host side rvinterf and fc-shell processes, or you can | |
81 issue a 'tgtreset' command at the fc-shell prompt. The latter will cause the | |
82 target to reset and boot back into its regular firmware. |