FreeCalypso > hg > freecalypso-docs

comparison FC-modem-family @ 33:7aed57fc1928

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
FC-modem-family article fully rewritten for the new reality of FC Tango modules
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 28 Sep 2020 00:48:17 +0000
parents 1e76655a44bd
children
comparison
equal deleted inserted replaced
32:78c2cc6ebbb8 33:7aed57fc1928
1 I, Mother Mychaela, have a vision for a family of FreeCalypso modem products in 1 The very first FreeCalypso hardware product named FCDEV3B was conceived in 2015
2 different physical form factors, possibly with variations in offered 2 and physically produced in the first version in 2017, with the final all-bugs-
3 functionality, all sharing the same fcmodem firmware build target - meaning that 3 fixed version produced in early 2019. FCDEV3B was conceived to fulfill an
4 the same FreeCalypso fw built for the fcmodem target (a proposed successor to 4 internal project need: to replace no longer available and quite inconvenient
5 the current fcdev3b build target) will run on all FC modem hw products, 5 Openmoko hardware, and to provide a platform for empirically learning those
6 requiring some commonalities across the entire product family but also 6 parts of TI's chipset+fw solution which were previously elusive. The '3B' at
7 supporting some variations. The following design constraints are hereby being 7 the end of FCDEV3B board name stands for triband, which was a deviation from
8 laid down in order to make this common fcmodem firmware possible: 8 the Mother's original desires: ever since I first found TI's Leonardo schematics
9 back in 2011, I had always wanted to make all of my FreeCalypso hw designs fully
10 quadband, following TI's original Leonardo+ quadband reference design. But in
11 2015 we lacked the necessary know-how to recreate TI's quadband Leonardo from
12 schematics alone, whereas for Openmoko's triband version we had not only
13 schematics, but also the complete PCB layout - thus we took the only course of
14 action that was viable at that time, and produced our FCDEV3B based on
15 Openmoko's version of the Calypso modem.
9 16
10 * All FC modem products will be either triband or quadband: triband if the 17 At the same time when our first FCDEV3B boards were being produced and debugged,
11 current Openmoko-based RFFE is kept as is (the safer route with less effort 18 there was talk about producing a derivative version that would be packaged as a
12 and design labor cost) or quadband if the customer commissioning a modem 19 component to be integrated into other people's systems and projects, as opposed
13 product is more adventurous and willing to pay more and take greater risks in 20 to a standalone development board for use on a lab bench. I also did not feel
14 order to get full quadband capability. Please refer to the Quadband-ideas 21 like staying triband forever, and the thought of a future quadband successor was
15 article for further details. 22 on my mind even as FCDEV3B was being designed. Thus there was an intent to have
23 a family of FreeCalypso modem products, eventually evolving from triband to
24 quadband, and being made in different form factors for different use cases.
25 But none of these ideas ever came to fruition because no one ever funded any of
26 them.
16 27
17 * Flash chip type autodetection in both fc-loadtool and firmware FFS driver code 28 The situation changed drastically with the discovery of already existing Tango
18 allows different flash chip types to be used depending on business needs, 29 modem modules, discovery that was made in December of 2019 and fully accepted
19 parts availability and the available physical space on the PCB. Flash 30 as the new reality over the course of 2020. The newly discovered Tango modem
20 capacity can range from 4 MiB (minimum fw requirement) to 16 MiB (maximum 31 module is essentially a mass-produced version of TI's Leonardo+ quadband
21 Calypso addressing capability); if a 16 MiB flash chip with two 8 MiB chip 32 reference design, and it is a very good module, even more capable than what we
22 select banks is used, then the second bank must be on nCS2 (like on FCDEV3B), 33 would have produced if someone had funded our ideas in the 2017 to 2019 period.
23 not on any other Calypso chip select.
24 34
25 * External RAM (XRAM) capacity can range from 512 KiB (minimum fw requirement) 35 In this new Tango reality it makes absolutely no business sense to produce any
26 to 8 MiB (maximum Calypso addressing capability), but it will always be on 36 new FreeCalypso modem modules, so instead we decided on a different and quite
27 nCS1, not on any other Calypso chip select. 37 novel course of action: we are officially adopting this already existing Tango
38 module into our FreeCalypso family by way of rebranding - we are going to resell
39 these modules as FreeCalypso Tango, flashed with our FreeCalypso firmware and
40 differentiated from non-FC-sourced modules with a sticker bearing our trademark.
41 Our rebranded and reflashed FC Tango modules are expected to become available
42 in December of 2020.
28 43
29 * The extra logic voltage level translating buffer IC that was introduced on 44 On the FreeCalypso firmware side, our earlier idea of a single fcmodem target
30 FCDEV3B V2 in order to make flash reset timing compatible with S71PL129N flash 45 that would cover multiple physical hw products in the FC modem family has been
31 may or may not be included. The Mother's preference is to include it when 46 withdrawn: our existing FCDEV3B hw is covered by firmware build target fcdev3b,
32 possible in order to increase the repertoire of usable flash chips, but if a 47 whereas Tango modems are covered by fw build target tangomdm. Openmoko modems
33 given design allows no PCB space for this extra little IC, then it will be 48 are covered by fw build target gtamodem. None of these 3 fw build targets are
34 acceptable to go back to driving the flash reset line with FDP and require 49 interchangeable: each build will only work on its one respective hw target.
35 the use of some flash chip other than S71PL129N - if the same footprint needs
36 to be kept and/or maximum flash and RAM capacity is desired, S71PL129J can be
37 used instead.
38 50
39 MCSI 51 In the unlikely event that our recently discovered Tango modules prove
40 ==== 52 insufficient and someone commissions us to design and build a new Calypso modem
53 starting from just chips, it will probably make the most sense to design that
54 new modem in such a way that it would share the same fw build with Tango, rather
55 than with FCDEV3B: Tango is much more versatile in terms of how the multitude
56 of Calypso GPIO and multifunction pins may be configured.
41 57
42 It is envisioned that most FC modem products will provide a digital voice 58 FreeCalypso handset idea
43 interface via MCSI as a major feature, but some may not. If a given product 59 ========================
44 does feature MCSI, pull-down resistors for MCSI_CLK and MCSI_FSYNCH will need
45 to be included on the modem module itself, so that the user always sees them as
46 non-floating outputs from the modem. MCSI_RXD will be a pure input without
47 on-board pull-up or pull-down resistors, i.e., the user will be responsible for
48 tying it off or pulling it to a stable logic level if it is unused.
49 60
50 However, if a given product does not feature MCSI, then it will be an unwelcome 61 I (Mother Mychaela) still desire my own FreeCalypso phone handset that would
51 burden to require extra pull-down resistors on the PCB, hence a different 62 replace my current Pirelli DP-L10 - but it is currently unknown whether or not
52 provision is planned. If and when we ever produce a FreeCalypso modem without 63 my personal life circumstances will remain such that this project desire will
53 MCSI, we will program a /etc/fc-pinmux file in FFS telling our fcmodem firmware 64 remain active, or if changes in my personal life circumstances (such as loss of
54 to switch the MCSI pins into GPIO mode and to drive all 4 of them as dummy 65 GSM service in the area where I live combined with no ability to relocate to a
55 outputs, eliminating floating I/O pins without any effort from the hardware 66 more GSM-friendly country) will invalidate this project desire.
56 side.
57 67
58 Why would a FreeCalypso modem product not feature MCSI? Two use cases are 68 In the now-seemingly-unlikely event that I live long enough with active GSM
59 envisioned here: 69 service to where I would get around to doing this FC handset project, it is my
70 desire to build that handset board starting from just chips, rather than based
71 on Tango. A handset is not a modem, thus handsets and modems generally do not
72 share the same firmware build targets - thus if my dream FC handset board ever
73 becomes a reality, it will have its own dedicated fw build target, not shared
74 with any other hw. I definitely wish to use the same quadband RFFE as Leonardo
75 and Tango, and my currently envisioned choice of flash chip is S71PL064J.
60 76
61 * The new GTA02-like smartphone motherboard thought experiment - see the 77 CONFIG_TARGET_FCFAM C preprocessor symbol
62 corresponding section at the end of this article;
63
64 * If we ever produce a FreeCalypso modem in the form factor of a USB dongle for
65 laptops, it would be very easy to incorporate an FT2232x adapter presenting
66 both Calypso UARTs to the USB host, but adding a USB-to-MCSI bridge would
67 entail much greater complexity, hence it may make sense to omit MCSI for this
68 product and instead provide an analog headset jack for voice calls.
69
70 GPIO
71 ====
72
73 Our firmware configures Calypso GPIO 3 as an input; GPIOs 0-2 and those
74 multifunction pins which are unused and configured as GPIOs (TSPDI/IO4,
75 BCLKX/IO6, MCUEN1/IO8 and MCUEN2/IO13) are configured as outputs. Board wiring
76 must be compatible with these directions: those pins which our fw drives as
77 outputs can be simply left unconnected, while GPIO 3 needs to be sensibly driven
78 or tied off as explained below.
79
80 Openmoko's modem puts out an application processor wakeup signal (asserted by
81 the fw when the modem needs to send something to the host but is blocked by CTS
82 being held high) on GPIO 1. In order to have full feature parity, our FC modems
83 will provide an equivalent signal as well, but we are moving it to GPIO 0
84 because in FreeCalypso GPIO 1 is already taken for the loudspeaker control
85 signal like on TI's D-Sample and Leonardo boards. Our firmware's complete GPIO
86 usage thus becomes:
87
88 GPIO0: application processor wakeup signal
89 GPIO1: loudspeaker amplifier on/off control
90 GPIO2: DCD modem control output
91 GPIO3: DTR modem control input
92 all others: dummy outputs
93
94 Because GPIO3/DTR is an input, it needs to be either sensibly driven or tied
95 off. On our current FCDEV3B this line has a 100 kOhm pull-down resistor to GND,
96 but it is not accessible to the user in any way - this design aspect was copied
97 from TI's Leonardo board before I thought better. Most of our future FC modem
98 products are planned to have DTR as a user input signal (which the user can tie
99 off if it is not used or needed in a given application), but if there is no DTR
100 user input signal on a given modem product, then GPIO3 will be grounded inside
101 the modem to keep the firmware happy.
102
103 Calypso's unused DSR_MODEM/LPG pin was left unconnected in Openmoko's version
104 but on our FCDEV3B it is tied to GND on the board. Future FC modem family
105 boards will also need to have this pin tied to GND: our firmware leaves this
106 pin in its default power-up config of DSR_MODEM input and does not change it to
107 LPG output, thus leaving it unconnected would cause it to float.
108
109 Extreme case: a new GTA02-like smartphone motherboard
110 =====================================================
111
112 A rather extreme thought-experiment test case for the FC modem family idea
113 presented in this article is this thought: suppose we wanted to produce a new
114 GTA02-like smartphone motherboard, bringing Openmoko's dream back from the dead.
115 We could try to make a verbatim clone of GTA02-MB-A6 from OM, but for both
116 technical and political reasons it would be desirable to make a few changes:
117
118 * Making a strictly verbatim clone of GTA02-MB-A6 would mean populating a
119 Samsung K5A3281CTM memory chip onto OM's PCB footprint which does not really
120 fit this chip properly. Changing the PCB footprint to fit K5A32xx more
121 properly would not be easy because there are signal traces in the PCB spots
122 where the extra mounting balls for K5A32xx would need to go. The approach
123 that seems most naturally sensible would be to populate a better-fitting
124 memory chip, such as Spansion S71PL129JB0BAW9Z for which that footprint was
125 properly made - but then the result would no longer be a verbatim clone of
126 OM's version, and our gtamodem target configuration would no longer fit. And
127 at that point it would make the most sense to stop following the gtamodem
128 config and to make it an fcmodem family product instead.
129
130 * It would be politically preferable if the new GTA02-like motherboard would run
131 fcmodem firmware rather than gtamodem, making a clean break from those parts
132 of OM's troubled history which caused them to be Closedmoko during certain
133 years.
134
135 Hence the technical challenge: would it be possible to make a GTA02 derivative
136 with absolutely minimal changes that would run fcmodem firmware instead of
137 legacy mokoN or FC fw builds for the gtamodem target? The answer is yes, and
138 here is the recipe - note that *no* new components need to be added to the
139 extremely tight PCB layout:
140
141 * Move the 2nd flash chip select connection from nCS4 to nCS2 on the Calypso;
142
143 * Move the AP wakeup interrupt line from GPIO1 to GPIO0 to match fcmodem
144 firmware GPIO assignments;
145
146 * Take the useless INT0 AP-to-BP connection line present in the GTA02 original
147 and move it to Calypso GPIO3, providing fcmodem firmware with the DTR input
148 it expects;
149
150 * Ground Calypso's unused DSR_MODEM/LPG signal, causing it to not float when
151 our fcmodem firmware keeps the power-up default of DSR_MODEM function;
152
153 * Program /etc/fc-pinmux in FreeCalypso FFS to tell the firmware that there is
154 no MCSI on this board, so that all 4 MCSI signals will become GPIO dummy
155 outputs and won't float.
156
157 Some additional changes which don't affect the firmware one way or the other:
158
159 * Remove R1003 and R1004 0Rs which seem to be the root cause of bug #1024 and
160 replace them with solid PCB traces;
161
162 * Up C1009 from 10 uF to 22 uF as additional guard from bug #1024;
163
164 * Ground Calypso's unused input RXIR_IRDA to keep it from floating - this input
165 cannot be changed to an output under firmware control without breaking other
166 functionality.
167
168 At the same time it would also make a lot of sense to remove the Glamo graphics
169 decelerator from the AP subsystem, connecting the LCD directly to the Samsung AP
170 like it was on GTA01 - thus from the AP software perspective the new motherboard
171 would also become its own new platform just like the modem, very similar to the
172 GTA02 original, but not strictly identical, featuring some improvements instead.
173
174 IP rights and FreeCalypso brand integrity
175 ========================================= 78 =========================================
176 79
177 The present vision of having the same fcmodem firmware support all FreeCalypso 80 As of 2020-09 this C preprocessor symbol (currently defined only for build
178 modem products applies ONLY to those hardware products which are designed and 81 target fcdev3b) has only two effects:
179 physically produced by Mother Mychaela or one of her business entities. We will
180 NOT provide any support whatsoever for any pirate hardware products that may be
181 produced by any persons or entities who are making, have made or are planning to
182 make inappropriate use of any of our published or unpublished board design
183 files.
184 82
185 In the event that some third party buys a legitimate license to produce their 83 1) It changes the src/cs/drivers/drv_app/ffs/board/dev.c table of supported
186 own derived works based on FreeCalypso hardware designs, we may provide 84 flash chips and FFS configurations, as well as a few other FFS config bits
187 technical support to that specific customer as per our agreement with them, but 85 to support the large 16 MiB flash config used on FCDEV3B. Targets like Tango
188 any such support will be customer-specific: our generic, non-customer-specific 86 with S71PL064J or S71PL032J flash will continue to work equally well whether
189 public FreeCalypso firmwares will only ever support our own official 87 or not CONFIG_TARGET_FCFAM is defined because these two flash chips are
190 Falconia/FreeCalypso modem products, and should not be expected to support any 88 listed in both versions of the table with the same FFS config, but 16 MiB
191 customized products made by or at the request of particular third parties. 89 flash chips S71PL129J and S71PL129N are supported only with
90 CONFIG_TARGET_FCFAM and cannot be otherwise, as their 2nd flash chip select
91 wiring is FC-specific. Yet on the contrary, Samsung K5A32xxCTM with
92 Openmoko's FFS config (also used by Huawei) is NOT compatible with
93 CONFIG_TARGET_FCFAM.
94
95 2) It changes the default compiled-in AFC Psi parameters in L1 from TI's
96 Leonardo values to a different set of numbers that match Openmoko/FCDEV3B
97 VCXO. But these compiled-in values are only fallbacks, and are generally
98 expected to be overridden by factory calibration written into FFS.
99
100 -h fcfam target for fc-loadtool
101 ===============================
102
103 The -h fcfam target must be used with FCDEV3B, no other loadtool configs will
104 work: FCDEV3B has a 16 MiB flash chip that is only supported with -h fcfam.
105 Either -h fcfam or -h gen8 will work equally well on FC Tango modems (S71PL064J
106 flash chip), thus you can use whichever config you feel is more philosophically
107 correct.