--- a/fluid-mnf/README	Sun Mar 15 03:02:13 2020 +0000
+++ b/fluid-mnf/README	Sun Mar 15 03:52:23 2020 +0000
@@ -279,3 +279,94 @@
   component (which we haven't modified except for the 39 MHz fix) displays
   pretty dancing patterns on these LEDs as it does its work.
 
+FLUID operating on Openmoko devices
+===================================
+
+While nowhere near as sexy as on TI's own D-Sample, our fluid-mnf port works
+well on Openmoko modems:
+
+* Only fluid-mnf -oo mode works on Openmoko devices, NOT fluid-mnf -oO, same as
+  with Leonardo or Caramel boards or any other Calypso 26 MHz platform.  We have
+  incriminating evidence that Openmoko once made fluid -oO mode work on their
+  platform by witchcraft (bending the known laws of physics), but we were never
+  able to reproduce that paranormal feat - see this FreeCalypso community
+  mailing list thread:
+
+  https://www.freecalypso.org/pipermail/community/2020-March/000743.html
+
+* Don't try D-Sample XXO baud rates of 230400, 460800 or 921600 bps - they
+  won't work.  However, Calypso high baud rates of 203125, 406250 and 812500 bps
+  do work if you are going through the external headset jack and have one of
+  the better USB-serial cables, either FTDI or appropriately programmed CP2102.
+
+Target boot control
+===================
+
+The code we got from TI in fluid-2.27.zip includes a rather bizarre provision
+for some ancient way of doing target boot control: right after opening the
+target serial port but before sending periodic beacons seeking to interrupt and
+divert the boot path either in the Calypso boot ROM or in a flash-resident
+FLUID bootloader, FLUID does some manipulation of the host UART's DTR and RTS
+outputs, as well as sending a break on the main data line.  These manipulations
+do absolutely nothing on any ordinary Calypso hardware: the DTR line goes only
+to a GPIO if anywhere at all; the host's RTS output line will normally be
+connected to Calypso CTS_MODEM input if it's the MODEM UART, but these flow
+control lines are completely ignored by both the Calypso boot ROM and various
+flash-resident bootloaders.  But apparently there once existed some special
+cable, interfaced to some unknown (probably very early and TI-internal) Calypso
+or before-Calypso targets in some unknown way, and that arrangement produced a
+target reset (probably a predecessor of Iota nTESTRESET on whatever before-Iota
+ABB) when FLUID did this wiggle.
+
+In any case, that hardware no longer exists and cannot be recreated because we
+have no idea what it was like and how it is supposed to work.  But the logic in
+question is still there in this fluid-mnf port; running OM's fluid.exe under
+strace reveals that they had retained this logic as well, although they broke
+the code that generates a break on the serial data line - how ironic.
+
+Aside from this non-understood UART control line wiggling, there is no effective
+target boot control in FLUID: not in TI's original version, not in OM's port
+and not in the present fluid-mnf.  You just run FLUID against a serial port, it
+sends beacons and waits forever for the selected bootloader (boot ROM or FLUID
+bl) to respond, and you have to cause the Calypso target to go through its boot
+path by your own external means.  Most importantly, there is no provision for
+automation, i.e., no provision for the process to exit with an error code
+instead of hanging forever if you got some target boot control implemented, but
+the bootloader fails to respond as expected - put another way, there is no
+equivalent to loadtools -t option which we've added as of fc-host-tools-r13.
+
+Performance
+===========
+
+Even though it cannot be a replacement for fc-loadtool in most use cases, FLUID
+is very aggressively optimized for speed in ways that would be hard to match in
+our fc-loadtool architecture:
+
+* FLUID's serial protocol between the host tool and the target-side component
+  includes compression (some form of LZ77) for blocks of data destined for
+  flash;
+
+* The process of programming flash is parallelized: the bits to be programmed
+  are serially transferred into a large RAM buffer on the target in parallel
+  with the execution of flash erase and program operations on the target;
+  specifically, flash erase and program operation functions call the UART Rx
+  handler function (which handles the incoming serial stream) as they poll the
+  flash chip to complete its operation!
+
+For these reasons, on those targets which are supported by both FLUID and
+fc-loadtool, flash programming with FLUID is faster.  Here are the performance
+numbers obtained on the Mother's Slackware 14.2 host system, flashing an
+Openmoko GTA02 modem with firmware version moko-new-fw-20190128, going through
+the external headset jack, UberWaves CP2102 Professional cable:
+
+fluid-mnf   at 115200 baud: 2m28s
+fc-loadtool at 115200 baud: 4m02s
+fluid-mnf   at 812500 baud: 0m40s
+fc-loadtool at 812500 baud: 1m12s
+
+With both tools the m0 version of the firmware image (fwimage.m0) was being
+flashed; in the case of fc-loadtool the new flash e-program-m0 command was used.
+The version of fc-loadtool used for this test is the one that is about to be
+released with fc-host-tools-r13; previous versions would be even slower.  In
+the case of fluid-mnf the -C option was used to disable delta downloads, making
+the test operation independent of previous flash state.