Inexplicable paranormal mystery in OM's history

Mychaela Falconia mychaela.falconia at gmail.com
Thu Mar 12 05:33:32 UTC 2020


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


More information about the Community mailing list