--- a/fluid-mnf/README	Sun Mar 15 03:52:23 2020 +0000
+++ b/fluid-mnf/README	Sun Mar 15 08:59:12 2020 +0000
@@ -265,7 +265,7 @@
 * The D-Sample board has an extra 14.745600 MHz crystal oscillator and a special
   circuit (controlled by bits in a register mapped into Calypso nCS3 address
   space) that can switch the Calypso clock input from the regular 13 MHz coming
-  from the RF section to this special 14.745600 clock.  Of course no GSM
+  from the RF section to this special 14.745600 MHz clock.  Of course no GSM
   functions can work in this state, but feeding this special clock to Calypso
   allows its UARTs to produce "standard" baud rates of 230400, 460800 and 921600
   bps!  This feature is apparently called XXO for eXternal Xtal Oscillator, and
@@ -370,3 +370,68 @@
 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.
+
+Where to go from here
+=====================
+
+So now we have two competing tools for operating on the flash memory of Calypso
+GSM devices: fc-loadtool and fluid-mnf.  Which one should you use?  In most
+practical use cases only fc-loadtool will work:
+
+* FLUID only works on D-Sample, Caramel and Openmoko targets.  If you are
+  working with an FCDEV3B, any Mot C1xx phone, Pirelli DP-L10 or a GTM900 module
+  with the newer Samsung K5L3316CAM flash chip, then fc-loadtool is the only
+  choice.
+
+* Both fc-loadtool and fluid-mnf can read flash dumps, saving them in either
+  binary or S-record format.  However, FLUID only accepts *.m0 S-record files
+  (16-bit moko-style by default, but 8-bit and 32-bit variants can be used too)
+  as the data source for flash programming.  Binary format is much more
+  convenient for flash backups, but restoring such backups with FLUID would be
+  a complicated matter, requiring an external converter that extracts the
+  desired subrange out of a binary flash dump file and makes an m0 image out of
+  it.
+
+* fc-loadtool and its loadagent back end are only one part of a larger loadtools
+  and target-utils suite that supports many other operations besides flash
+  manipulation.
+
+On the other hand, if your target is one of the few which are supported by FLUID
+and your desired operation is to flash a firmware image built in m0 format,
+then you can use fluid-mnf and enjoy faster speed - or enjoy the dancing LED
+patterns if the target is a TI D-Sample board.
+
+We got into the present situation we find ourselves in because of the culture
+of suppression that was built around our dear Calypso by the Closed Moko
+Company: back when we started FreeCalypso in 2013, the source for FLUID was
+wrongfully withheld from Humanity, thus producing a from-scratch replacement
+like our own fc-loadtool was the only viable option.  And because the project
+was essentially a battle for the liberation of Calypso, performance was not a
+major concern at that time, which is how we ended up with a tool that is not
+optimized for speed like FLUID is.
+
+If I (Mother Mychaela) had been a Calypso modem engineer for a truly Open kind
+of Moko instead of those NDA-worshipping Germans back in 2006-2008, with access
+to all documentation, firmware sources and FLUID from day 0, and working in a
+fully open culture with everything freely published like in current FreeCalypso,
+I would have initially produced something very similar to the present fluid-mnf
+port, just to get the existing and known working tool running under Linux
+instead of Windows.  If the project had stayed with Samsung K5A32xx or Spansion
+S71PL-J flash chips, such a Linux port of FLUID would have been sufficient.  If
+new requirements came along to support S71PL-N flash, second flash bank
+operations, significantly different Calypso targets like Mot C1xx, or anything
+else that does not fit well into FLUID architecture, then my solution would
+have been to produce a new tool that is free of unmaintainable FLUID gunk
+(support for hw that no longer exists and thus can't be tested, old FLUID
+bootloader protocol), but keeps those parts of FLUID architecture that make it
+so fast.  But as they say, history does not know subjunctive mood.
+
+So what can we do in the present?  We have targets and operations which would
+be very difficult to shoehorn into the architecture of FLUID, but which are
+well-supported by fc-loadtool - how can we make them as fast as FLUID?  One
+promising approach would be to extend our loadagent yet again, adding a flash
+programming protocol similar to FLUID, with parallelized flash operations and
+serial stream Rx and with LZ77 decompression, and change fc-loadtool to use
+this new protocol for flash programming while keeping all other functionality
+as it already works.  But given the sorry state of FreeCalypso funding, this
+idea may never get implemented. :-(