FreeCalypso > hg > freecalypso-sw

comparison doc/Roadmap @ 462:6500e1817d9b

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Roadmap: written
author Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
date Mon, 23 Jun 2014 20:39:36 +0000
parents
children
comparison
equal deleted inserted replaced
461:7017da4978bb 462:6500e1817d9b
1 The ultimate goal of the FreeCalypso project is to produce a GSM firmware
2 version that:
3
4 a) runs on the Calypso targets of interest to us: not only the FIC/Openmoko
5 GTA0x GSM modem, but also some complete dumbphones like Mot C139 and/or
6 Pirelli DP-L10;
7
8 b) operates each target device it runs on in a way that is practically usable:
9 to me (lead developer Space Falcon) practical usability means providing a
10 standard AT command interface on modems like GTA0x and operating as a self-
11 contained standard cellphone with a UI on complete "dumbphone" targets;
12
13 c) is rebuildable from source in a way that would allow us to exercise the
14 traditional Four Freedoms of free software as defined by the FSF.
15
16 Our starting point is TI's Leonardo reference firmware version from Sotovik, a
17 mixture of source and linkable binary object modules. It can be built into a
18 complete and functional firmware image with TI's TMS470 compiler+linker+etc
19 toolchain, and can run on two hardware targets:
20
21 a) TI's Leonardo development board for the Calypso/Iota/Rita chipset -
22 legendary unobtainium hardware;
23
24 b) FIC/Openmoko GTA0x GSM modem - while this device is *not* what I wish to use
25 with the "end user" hat on, it is an available and working hw platform for
26 development.
27
28 This Leonardo starting point does kinda-sorta satisfy the "rebuildable from
29 source" requirement, as I was able to port it from the Leonardo board to the
30 GTA0x modem, but it is still quite far from what the FreeCalypso project
31 ultimately seeks to achieve.
32
33 What I, the lead developer, ultimately seek is not an AT-controlled modem
34 embedded in a "Linux" smartphone, but a complete and standalone "dumbphone",
35 with the UI driven by the Calypso. Transforming our starting and working
36 reference version from something that runs on the GTA0x modem and presents an
37 AT command interface into something that can run on a complete "dumbphone" and
38 present a self-contained UI can be done in several possible ways:
39
40 1. One could proceed further with the same approach that was used to produce
41 leo2moko: keep making small incremental changes to the Leonardo semi-src,
42 while keeping most of the binary object blobs intact at least initially, and
43 sticking with the original proprietary TMS470 compiler toolchain (running
44 under wine, as it's a bunch of M$ Windows binaries) throughout the journey.
45
46 Advantage: no massive "forklift" step required at the very beginning of the
47 journey, one can do small incremental steps instead. One possible roadmap
48 with this approach might be (just thinking out loud here) to start with
49 finding a way to redirect the AT command channel to something wrapped inside
50 RVTMUX, then port the fw to run on a target like Pirelli DP-L10, still
51 controlled via AT commands but passed via RVTMUX, and then try to add the
52 "dumbphone" UI layers. Some of the binary object blobs would certainly need
53 to be "cracked" and modified in this process, most sensibly by replacing
54 each blob in need of modification with a reconstructed source piece, but
55 this work would be done incrementally, rather than in a massive "forklift"
56 step upfront.
57
58 Disadvantage: this approach requires sticking with the original proprietary
59 compiler toolchain throughout at least most of the journey, which means
60 keeping the Weendoze poison that toolchain comes with. This aspect was
61 enough to turn me personally away from this approach.
62
63 2. One could move away from the proprietary compiler toolchain and replace it
64 with gcc, while still retaining those parts of the Leonardo firmware for
65 which we only have linkable binary objects but no C source, by teaching the
66 GNU toolchain (gcc+binutils) to emulate the TMS470 compiler's ABI: COFF
67 objects, a very different way of doing ARM/Thumb interworking, and a host of
68 other differences from how the GNU toolchain for ARM normally does things.
69 (I've done similar work on GCC and GNU Binutils in the past; let us not
70 forget that GNU started out by emulating various inter-component interfaces,
71 including ABIs, of various proprietary Unix versions.)
72
73 The advantage of this approach should be obvious. While in the long run we
74 would certainly like to get rid of all binary object blobs and replace them
75 with reconstructed source pieces, life would be much easier if we could do
76 this work incrementally, one blob at a time in a regression-tested working
77 fw version, rather than all upfront.
78
79 Disadvantage: teaching gcc and binutils to emulate TI's TMS470 ABI well
80 enough to where one could compile some sources with gcc, link the resulting
81 .o's with TI's blobs and get a working fw image at the end would be no easy
82 matter. In fact, it would be a massive amount of work, and considering that
83 this work would serve absolutely no purpose but to allow linking with some
84 proprietary binary blobs, finding the justification for the effort would be
85 difficult.
86
87 3. The approach I am currently following is the most ambitious one: start by
88 deblobbing the firmware, i.e., replacing all binary object blobs with
89 reconstructed source pieces, and then simply compile the all-C source with
90 the GNU toolchain for ARM7 in its default ABI.
91
92 Advantage: having the firmware in the form of full C source that builds with
93 a free compiler (a compiler that is itself bona fide Free Software) is
94 obviously the ultimate best. No blobs means no need to waste creative energy
95 on emulating proprietary compiler ABIs.
96
97 Disadvantage: all the hardest work is upfront, and needs to be done in a
98 "forklift" manner.
99
100 It should be obvious that incrementality, or division into manageable, bite-
101 sized pieces, is an essential requirement for successful execution of any large
102 scale project, and FreeCalypso is no different. Because our chosen approach
103 unfortunately does not allow us to make small incremental modifications to a
104 fully functional fw version, I currently achieve the needed incrementality in a
105 different way: by starting out with a firmware "skeleton" that compiles into an
106 image and runs on the hardware, but does nothing useful yet, and then slowly
107 adding chunks of "meat" to this skeleton in incremental steps aiming in the
108 direction of the complete & working fw version that is our reference. As I add
109 each "chunk of meat" to our gcc-built gsm-fw, I test it on the hardware and
110 compare its operation against the leo2moko reference version - that is our form
111 of pseudo-regression testing.
112
113 Where the missing source bits come from
114 =======================================
115
116 How can we replace a binary object blob with a corresponding source piece if we
117 lack the original source? In two ways:
118
119 1. In many cases we can lift the corresponding source piece from another TI
120 source leak, e.g., the LoCosto one. Calypso and LoCosto chipsets are
121 different, so code specific to LoCosto hardware won't run on Calypso targets,
122 but much of the code is chipset-independent. The LoCosto source leak is
123 important because it contains real C source for many of the chipset-
124 independent components for which our Leonardo reference version has only
125 binary blobs.
126
127 2. When no original or suitable substitute source can be found anywhere, we
128 have to bite the bullet, pass the blob through a suitable disassembler (I
129 wrote one that is specifically taylored for reversing code built with the
130 TMS470 compiler), and then write a piece of new C code that replicates the
131 logic found in the disassembled blob.