FreeCalypso > hg > fc-magnetite

comparison doc/Pirelli-Howto @ 97:ffa25a27fa27

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Pirelli-Howto written
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 03 Oct 2016 19:23:59 +0000
parents 596d86109e44
children 619a33e8425e
comparison
equal deleted inserted replaced
96:9fb9f896bd77 97:ffa25a27fa27
1 Running FreeCalypso Magnetite firmware on the Pirelli DP-L10 1 Running FreeCalypso Magnetite firmware on the Pirelli DP-L10
2 ============================================================ 2 ============================================================
3 3
4 <To be written> 4 The Pirelli DP-L10 is a neat target for playing with FreeCalypso for two
5 reasons:
6
7 1. It has a USB port connected to one of Calypso's UARTs through a built-in
8 CP2102 USB-serial adapter, eliminating the need for headset jack serial
9 cables.
10
11 2. The huge RAM on this phone (8 MiB) makes it possible to run experimental GSM
12 firmware images entirely in RAM without flashing - and we have successfully
13 implemented this capability in FC Magnetite similarly to Citrine.
14
15 There is, however, one difference between our Citrine and Magnetite firmwares
16 when it comes to running on the Pirelli without flashing: Citrine uses a
17 RAM-based fake FFS, whereas Magnetite always requires a real FFS in flash, even
18 when the firmware code image itself is entirely RAM-based. However, just like
19 on the C139, we do NOT use the same FFS which is used by Pirelli's official
20 firmwares - the latter contains nothing of use to our fw, hence it is best for
21 us to use our own separate FreeCalypso Magnetite FFS.
22
23 The flash location that's been chosen for Magnetite FFS on the Pirelli is
24 0x02480000 through 0x025FFFFF, i.e., offsets 0x480000 through 0x5FFFFF in the
25 second flash bank. Pirelli's official firmwares use this flash area as
26 temporary storage during OTA (over-the-air, probably WLAN in this case) fw
27 reloads and leave it untouched at all other times, therefore as long as you are
28 not doing firmware reloads over WLAN while in the "official mode", you can use
29 your Pirelli phone for FreeCalypso experiments via fc-xram and go back to the
30 regular fw in between, and the Magnetite FFS in the flash will be preserved
31 from one fc-xram session to the next, not disturbed by Pirelli's fw.
32
33 Compiling
34 =========
35
36 When compiling our Magnetite firmware for the Pirelli target, you will need to
37 select the l1reconst configuration - it is the only currently available
38 configuration that works on this target. Therefore, you configure.sh command
39 should be:
40
41 ./configure.sh pirelli l1reconst
42
43 To build a RAM-loadable image for the Pirelli, run 'make ram' in the build
44 directory created by the configure script - see the Compiling write-up for
45 more details.
46
47 Because we have not deblobbed the G23M firmware component yet (the l1reconst
48 configuration uses G23M binary blobs from TCS211/Sotovik), your Magnetite fw
49 build will include FAX_AND_DATA and GPRS functionality. In the FreeCalypso
50 environment where we are not doing WAP or MMS this functionality can only be
51 exercised on targets that bring out a classic modem UART with the classic AT
52 command interface to the external host, but the Pirelli is not one of those
53 targets - hence on this target all FAX_AND_DATA and GPRS code is nothing but
54 dead weight. We will only be able to remove this dead weight when and if we
55 fully deblob all of L1 and G23M, so it will be a while before we get there,
56 and we'll have to carry the dead weight until then.
57
58 Running on the target
59 =====================
60
61 1. Connect a USB cable from your GNU/Linux PC/laptop to the phone. If the
62 phone was off but the battery is present, it will go through a charger-plug
63 power-on event; if the flash contains Pirelli's original fw, it will boot in
64 the charging mode. If the battery is not present, the Calypso won't power
65 on (it needs VBAT and can't run on VCHG power instead), but the /dev/ttyUSBx
66 device will still show up, as the CP2102 USB-serial chip inside the phone is
67 powered strictly from the USB side.
68
69 2. Run a command like the following:
70
71 fc-xram -h pirelli /dev/ttyUSB0 ramimage.srec rvinterf
72
73 Adjust the paths to your /dev/ttyUSBx device and your ramimage.srec as
74 appropriate, and add rvinterf logging or other options as desired.
75 Specifying rvinterf on the fc-xram command line directs fc-xram to exec
76 rvinterf and pass the serial channel to it immediately as soon as the code
77 image has been loaded into target RAM and jumped to; this direct passing of
78 the serial channel from fc-xram to rvinterf is appropriate because the
79 loaded fw will immediately start emitting binary trace packets in TI's RVTMUX
80 format.
81
82 3. Induce the phone to execute its Calypso boot path: if the battery was
83 removed, insert it now; if Pirelli's regular fw is running, execute its
84 power-off sequence.
85
86 Once the Calypso chip in the Pirelli phone executes its boot path with fc-xram
87 running, the boot path will be diverted and our experimental firmware will be
88 loaded into target device RAM and jumped to. Our fw will now run, and the
89 rvinterf process on the host will maintain communication with it.
90
91 FFS initialization
92 ==================
93
94 When our Magnetite firmware boots, it will examine the state of the flash
95 sectors in the area we have allocated for our aftermarket FFS. If this flash
96 area is completely blank the first time Magnetite boots, as it should be if you
97 have a "virgin" Pirelli phone, the FFS code in our fw will automatically perform
98 what TI called the "preformat" operation: write undifferentiated FFS block
99 headers (0xBF in the flags byte) into each flash sector. However, it won't
100 automatically perform the "format" operation - instead you'll need to run
101 fc-fsio to do the format and to populate this FFS with some necessary content.
102 If you are not sure of the state of the Magnetite FFS flash area on your
103 Pirelli, you can also run fc-fsio to examine it - so run fc-fsio either way.
104 Run fc-fsio WITHOUT -p: let it connect to the rvinterf process you should
105 already have running from fc-xram.
106
107 NOTE: the following instructions are based on the new version of fc-fsio that
108 has not yet made its way into a packaged fc-host-tools release as of this
109 writing. Therefore, please get the latest development version here:
110
111 https://bitbucket.org/falconian/freecalypso-tools
112
113 Once you are in fc-fsio, check the status of your FFS like this:
114
115 fsio> ls -l /
116
117 If the FFS is already formatted, you will get a listing of the root directory;
118 if it is not formatted, you'll get an error like this:
119
120 opendir: FFS error 4 (EFFS_NOFORMAT: ffs not formatted)
121
122 To format and initialize your Pirelli Magnetite FFS, issue the following
123 commands:
124
125 fsio> format /
126 fsio> pirelli-magnetite-init
127
128 If you already have a formatted FFS from before, it is safe to rerun the
129 pirelli-magnetite-init command, but not format. The format command will *not*
130 work on an already formatted FFS; if you have a messed-up FFS and you would
131 like to restart from a clean slate, erase the Magnetite FFS sectors with
132 fc-loadtool:
133
134 loadtool> flash2 erase 480000 180000
135
136 Exercising the GSM functionality
137 ================================
138
139 Once your FFS is good, open another terminal window on your driving PC/laptop
140 and run fc-shell. This program will connect to the already running rvinterf
141 process via a local socket, and it will enable you to send various commands to
142 the running fw on the target, the most important ones being standard AT
143 commands. Send the following sequence of AT commands to bring up GSM
144 functionality:
145
146 AT+CMEE=2 -- enable verbose error responses
147 AT+CFUN=1 -- enable radio and SIM interfaces
148 AT+COPS=0 -- register to the default GSM network
149
150 When you are done playing with our experimental fw, you can either yank the
151 battery and kill the host side rvinterf and fc-shell processes, or you can
152 issue a 'tgtreset' command at the fc-shell prompt. The latter will cause the
153 target to reset and boot back into its regular firmware.