FreeCalypso > hg > fc-magnetite

comparison doc/Bootloader @ 526:fbf0fabc5505

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Bootloader written
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 22 Sep 2018 05:59:38 +0000
parents
children
comparison
equal deleted inserted replaced
525:ecdb7aed6d3a 526:fbf0fabc5505
1 As we understand it, TI's earlier DBB (digital baseband processor) chips prior
2 to our Calypso did not have an on-chip ARM boot ROM: instead they would execute
3 code directly out of flash immediately out of reset, like our Calypso does when
4 its boot ROM is disabled with nIBOOT high. To get the firmware code into the
5 flash initially, one had to either use JTAG or populate preprogrammed chips
6 onto the board, and if you bricked your flash, you were screwed without JTAG.
7
8 To assist with loading new firmware images during casual development, TI
9 incorporated a bootloader stage into their firmware architecture. This
10 bootloader stage is placed at the beginning of the flash at the reset vector,
11 and the rest of the firmware begins at an erase unit boundary. The bootloader
12 stage executes first, and before it jumps to the main firmware entry point
13 (_INT_Initialize) for normal boot, it offers an opportunity for the boot process
14 to be interrupted and diverted if an external host sends certain magic command
15 packets into either of the two UARTs during the allotted time window. If the
16 external host does interrupt and divert the boot process in this manner, it can
17 feed a code image to the bootloader to be written somewhere in target RAM, and
18 then command the bootloader to jump to it. It is exactly the same functionality
19 (though with different serial protocol specifics) as implemented in the Calypso
20 boot ROM. The ROM version is obviously superior because it is unbrickable, but
21 the flash-resident, built-with-firmware version is what TI used before they
22 came up with the idea of the boot ROM for the Calypso.
23
24 When the boot-ROM-equipped Calypso came along, TI kept the flash-resident
25 bootloader in the firmware: it does no harm aside from adding a little bit of
26 delay to the boot process, it does not conflict with the ROM bootloader as the
27 two speak different serial protocols and respond to different interrupt-boot
28 sequences, and it allowed TI to keep the same firmware architecture for
29 platforms with and without a boot ROM. (Using flash boot mode 1, TI's firmwares
30 boot and run exactly the same way whether the Calypso boot ROM is present and
31 enabled or not.) However, in our FreeCalypso firmwares starting with Magnetite
32 we have removed this extra bootloader stage for the following reasons:
33
34 * It is not useful to us on any of our hardware targets: on those devices that
35 have the Calypso boot ROM enabled, we use that boot ROM and get full
36 unbrickability, whereas on Mot C1xx phones we have to work with Mot/Compal's
37 own different bootloader and serial protocol at least initially, hence it
38 makes the most sense to stick with the same after the conversion to
39 FreeCalypso as well.
40
41 * As delivered by TI with their full production TCS211 fw releases, their
42 firmware-resident bootloader works as intended only on hw platforms with
43 13 MHz VCXOs like the original D-Sample (Clara RF), and is broken on platforms
44 like Rita RF (the only RF chip for which we have driver code!) with 26 MHz
45 VCXOs: there is no conditionally-compiled code anywhere in the bootloader
46 code path to set the VCLKOUT_DIV2 bit in the CNTL_CLK register on 26 MHz
47 platforms, thus the UARTs are fed with 26 MHz instead of the standard 13 MHz
48 clock expected in normal operation, and the intended baud rate of 115200 bps
49 turns into 230400. Because 230400 bps is a baud rate which Calypso UARTs
50 *cannot* produce in normal GSM operation (when the peripheral clock network
51 runs at the expected 13 MHz), tools that are designed to talk to Calypso GSM
52 devices are typically not designed to support this baud rate. In particular
53 for CP2102 USB-serial adapters, the precedent established by the factory
54 CP2102 EEPROM programming in the Pirelli DP-L10 phone is that the baud rate
55 entry for 230400 bps is replaced with 203125 bps, which is a valid baud rate
56 for Calypso UARTs running at 13 MHz.
57
58 * We have no source for TI's firmware-resident bootloader, only linkable binary
59 objects that came with our world's last surviving copy of TCS211, which are
60 incompatible with our goal of blob-free firmware.
61
62 Because this extra bootloader stage is ultimately unnecessary in our
63 environment, the deblobbing goal was easier accomplished by removing it
64 altogether instead of expending effort on a blob-free replacement. Because I
65 wasn't comfortable with modifying TMS470 assembly code and linker script magic,
66 the removal of the bootloader was accomplished by stubbing out its C body with
67 an empty function. A 'build_lib bootloader' instruction in a firmware
68 configuration recipe causes a dummy do-nothing bootloader to be built from this
69 stubbed-out source.
70
71 We have been removing (stubbing out) the bootloader from our TCS211-based
72 firmwares since 2015, but in 2018-09 I (Mother Mychaela) finally took the time
73 to study TI's bootloader code via disassembly and finally figured out what it
74 does and how it works. Now that it is no longer an unknown, it may be
75 interesting to build some fw images with this bootloader blob re-enabled for
76 experimentation purposes, and a new experimental (not for production!)
77 l1reconst-bl configuration has been created for this purpose. The bootloader
78 blob has also been re-enabled in the classic configuration, whose only purpose
79 is to serve as a reference point that preserves almost everything from our
80 TCS211/Leonardo starting point.
81
82 Finally, it needs to be noted for the sake of completeness that Compal's
83 bootloader used on Mot C1xx phones is a modified version based on TI's original
84 bootloader. However, this factoid matters only for historians and genealogists;
85 for all practical purposes it is an unrelated animal, as Mot/Compal's serial
86 protocol for interrupting and diverting the boot process is their own and bears
87 no resemblance to TI's version. And yes, Mot/Compal's version does set the
88 VCLKOUT_DIV2 bit in the CNTL_CLK register to adjust for the 26 MHz clock input
89 as its first order of business; it was probably the very first issue they had
90 to fix.