Hello FC community, I have come across an extremely strange oddity in the land of ancient Openmoko history, it is so strange and so odd that I thought I would share it with y'all.
First some background: TI had other baseband chips before Calypso, and those previous DBB chips did not have a boot ROM like Calypso has. In the days before Calypso boot ROM, the standard way to bootstrap a board with blank or bricked flash was to load initial boot code via JTAG, then run FLUID (or older Delta tools) to program the flash with a firmware image. TI's firmwares included a flash-resident bootloader stage so that subsequent reloads could be done without needing JTAG again, as long as you didn't brick your board. TI's FLUID (official flash programming tool) supports two ways of making bootloader entry: fluid -oO works the old way, talking to the old bootloader that is either flash-resident or loaded via JTAG, and fluid -oo works the new way, talking to the Calypso boot ROM just like fc-loadtool or osmocon -m romload. On TI's D-Sample board (Calypso chip, 13 MHz CLKTCXO input) both ways work, but on Leonardo and its derivatives only the boot ROM way works. When the combination of Calypso DBB and Rita RF is used (the combination that occurs on Openmoko devices and every other Calypso hw we generally work with, and currently the only combination supported by both us and OBB), the CLKTCXO input to the Calypso is fed with 26 MHz rather than 13 MHz. Calypso boot ROM autodetects this input clock frequency and sets the correct register bits when a serial download is fed to it, but TI never updated their old flash-resident bootloader (FRBL) code to support 26 MHz Calypso platforms. The bootloader.lib blob library which TI gave to OM and which also appears verbatim-identical in other vendor firmwares that have passed through my hands contains code that would operate the UARTs at 115200 baud if one were to run this code on a board like D-Sample, but when running on any common 26 MHz Calypso platform, this code ends up running the UARTs at 230400 baud, waiting for an interrupt-boot sequence at that baud rate, and when no such 230400 baud interrupt-boot sequence arrives in the allotted time, the main fw boots normally. The problem of course is that this old fluid -oO protocol was meant to run at 115200 baud, not 230400: the fact that TI's FRBL code runs the UARTs at 230400 baud on 26 MHz Calypso platforms is a bug, not a feature, it is simply a bug which TI never bothered to fix because this old fluid -oO operation mode is completely unnecessary when the much better boot ROM way (fluid -oo) is available. While we have no source for Openmoko's version of FLUID with unknown modifications, we do have the source for TI's original Windows version, and sure enough, it only tries 115200 baud in -oO mode, not 230400. (FLUID does support high baud rates for the later bulk data transfer phase, but the baud rates for bootloader entry are fixed at 19200 and 115200 baud for -oo and -oO, respectively.) But here is the real mystery: when OM people were playing with their version of FLUID, running it on the application processor of GTA01 and GTA02 devices and talking to their Calypso modem, they somehow got that old deprecated -oO mode to work! In their final moko11 uSD image release they do use the better fluid -oo mode (Calypso boot ROM), and their current instructions for manual fluid usage on the GSM firmware flashing wiki page likewise instruct to use -oo, but in the earlier versions they used -oO and somehow got it to work! See the very earliest version of their wiki page: http://wiki.openmoko.org/index.php?title=Flashing_the_GSM_Firmware&oldid=58504 In there you can see a fluid command line with that -oO option, and furthermore, they give an example of fluid run-time output, and the "(fluid, version 3) ok" line in that output indicates that it really did gain target access via the old FLUID bootloader protocol! (The current version of this wiki page instructs people to use -oo instead, but the example output shown is still the "(fluid, version 3) ok" one.) But how did they get it to work that way?? I did a few experiments: * I have built test fw versions with this bootloader.lib blob reinstated (our current FC firmwares have it disabled) for both FCDEV3B and GTA02 (l1reconst-bl config in FC Magnetite), and confirmed with my frbl2test program (see freecalypso-reveng repository) that this old broken bootloader really does speak its serial protocol at 230400 baud on 26 MHz hardware, not at 115200 baud. * I tried running OM's fluid.exe with -oO on my GTA02 AP against this FRBL-enabled fw version, but it never made entry. * We have no corresponding source for OM's fluid.exe ARM/Linux binary, but I ran it under strace, and nope, no signs of OM having changed this part: the termios baud rate being set in -oO mode is B115200 as indicated by strace, just like the Windows original, not B230400. So how in the world did OM's people get fluid -oO to work all those years ago, a mode of operation which TI never supported on any Calypso 26 MHz platforms? And it isn't just that one wiki page: I have read through mailing list archives from those days, the threads about Calypso fw flashing, and there were people in the community too who apparently used fluid.exe successfully in both -oo and -oO modes. People talk about ghosts and UFOs and whatnot as paranormal mysteries, but what I am seeing here in OM's history is just as much of a paranormal mystery to me: how could this fluid -oO mode have possibly worked for those people when everything we know about the laws of physics (electrical signals, timing, baud rates) says that it could not have ever worked given the baud rate mismatch? Are there any old-time ex-OM people who can shed some light on this mystery? Or any paranormal investigators perhaps? (j/k) Utterly bewildered, Mother Mychaela _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community