view doc/Bootloader @ 607:030ce1ddd4f7
targets/gtm900.{conf,h}: temporary test build as Leonardo
author
Mychaela Falconia <falcon@freecalypso.org>
date
Mon, 17 Jun 2019 20:22:53 +0000 (2019-06-17)
parents
fbf0fabc5505
children
line source
+ − As we understand it, TI's earlier DBB (digital baseband processor) chips prior
+ − to our Calypso did not have an on-chip ARM boot ROM: instead they would execute
+ − code directly out of flash immediately out of reset, like our Calypso does when
+ − its boot ROM is disabled with nIBOOT high. To get the firmware code into the
+ − flash initially, one had to either use JTAG or populate preprogrammed chips
+ − onto the board, and if you bricked your flash, you were screwed without JTAG.
+ −
+ − To assist with loading new firmware images during casual development, TI
+ − incorporated a bootloader stage into their firmware architecture. This
+ − bootloader stage is placed at the beginning of the flash at the reset vector,
+ − and the rest of the firmware begins at an erase unit boundary. The bootloader
+ − stage executes first, and before it jumps to the main firmware entry point
+ − (_INT_Initialize) for normal boot, it offers an opportunity for the boot process
+ − to be interrupted and diverted if an external host sends certain magic command
+ − packets into either of the two UARTs during the allotted time window. If the
+ − external host does interrupt and divert the boot process in this manner, it can
+ − feed a code image to the bootloader to be written somewhere in target RAM, and
+ − then command the bootloader to jump to it. It is exactly the same functionality
+ − (though with different serial protocol specifics) as implemented in the Calypso
+ − boot ROM. The ROM version is obviously superior because it is unbrickable, but
+ − the flash-resident, built-with-firmware version is what TI used before they
+ − came up with the idea of the boot ROM for the Calypso.
+ −
+ − When the boot-ROM-equipped Calypso came along, TI kept the flash-resident
+ − bootloader in the firmware: it does no harm aside from adding a little bit of
+ − delay to the boot process, it does not conflict with the ROM bootloader as the
+ − two speak different serial protocols and respond to different interrupt-boot
+ − sequences, and it allowed TI to keep the same firmware architecture for
+ − platforms with and without a boot ROM. (Using flash boot mode 1, TI's firmwares
+ − boot and run exactly the same way whether the Calypso boot ROM is present and
+ − enabled or not.) However, in our FreeCalypso firmwares starting with Magnetite
+ − we have removed this extra bootloader stage for the following reasons:
+ −
+ − * It is not useful to us on any of our hardware targets: on those devices that
+ − have the Calypso boot ROM enabled, we use that boot ROM and get full
+ − unbrickability, whereas on Mot C1xx phones we have to work with Mot/Compal's
+ − own different bootloader and serial protocol at least initially, hence it
+ − makes the most sense to stick with the same after the conversion to
+ − FreeCalypso as well.
+ −
+ − * As delivered by TI with their full production TCS211 fw releases, their
+ − firmware-resident bootloader works as intended only on hw platforms with
+ − 13 MHz VCXOs like the original D-Sample (Clara RF), and is broken on platforms
+ − like Rita RF (the only RF chip for which we have driver code!) with 26 MHz
+ − VCXOs: there is no conditionally-compiled code anywhere in the bootloader
+ − code path to set the VCLKOUT_DIV2 bit in the CNTL_CLK register on 26 MHz
+ − platforms, thus the UARTs are fed with 26 MHz instead of the standard 13 MHz
+ − clock expected in normal operation, and the intended baud rate of 115200 bps
+ − turns into 230400. Because 230400 bps is a baud rate which Calypso UARTs
+ − *cannot* produce in normal GSM operation (when the peripheral clock network
+ − runs at the expected 13 MHz), tools that are designed to talk to Calypso GSM
+ − devices are typically not designed to support this baud rate. In particular
+ − for CP2102 USB-serial adapters, the precedent established by the factory
+ − CP2102 EEPROM programming in the Pirelli DP-L10 phone is that the baud rate
+ − entry for 230400 bps is replaced with 203125 bps, which is a valid baud rate
+ − for Calypso UARTs running at 13 MHz.
+ −
+ − * We have no source for TI's firmware-resident bootloader, only linkable binary
+ − objects that came with our world's last surviving copy of TCS211, which are
+ − incompatible with our goal of blob-free firmware.
+ −
+ − Because this extra bootloader stage is ultimately unnecessary in our
+ − environment, the deblobbing goal was easier accomplished by removing it
+ − altogether instead of expending effort on a blob-free replacement. Because I
+ − wasn't comfortable with modifying TMS470 assembly code and linker script magic,
+ − the removal of the bootloader was accomplished by stubbing out its C body with
+ − an empty function. A 'build_lib bootloader' instruction in a firmware
+ − configuration recipe causes a dummy do-nothing bootloader to be built from this
+ − stubbed-out source.
+ −
+ − We have been removing (stubbing out) the bootloader from our TCS211-based
+ − firmwares since 2015, but in 2018-09 I (Mother Mychaela) finally took the time
+ − to study TI's bootloader code via disassembly and finally figured out what it
+ − does and how it works. Now that it is no longer an unknown, it may be
+ − interesting to build some fw images with this bootloader blob re-enabled for
+ − experimentation purposes, and a new experimental (not for production!)
+ − l1reconst-bl configuration has been created for this purpose. The bootloader
+ − blob has also been re-enabled in the classic configuration, whose only purpose
+ − is to serve as a reference point that preserves almost everything from our
+ − TCS211/Leonardo starting point.
+ −
+ − Finally, it needs to be noted for the sake of completeness that Compal's
+ − bootloader used on Mot C1xx phones is a modified version based on TI's original
+ − bootloader. However, this factoid matters only for historians and genealogists;
+ − for all practical purposes it is an unrelated animal, as Mot/Compal's serial
+ − protocol for interrupting and diverting the boot process is their own and bears
+ − no resemblance to TI's version. And yes, Mot/Compal's version does set the
+ − VCLKOUT_DIV2 bit in the CNTL_CLK register to adjust for the 26 MHz clock input
+ − as its first order of business; it was probably the very first issue they had
+ − to fix.