--- a/doc/Loadtools-performance	Sun Mar 08 22:53:30 2020 +0000
+++ b/doc/Loadtools-performance	Sun Mar 08 22:56:31 2020 +0000
@@ -85,42 +85,6 @@
 flash program operation times between K5A3281CTM and S71PL129N flash chips seems
 to be the most likely explanation.
 
-Programming flash using program-m0 or program-srec
-==================================================
-
-Prior to fc-host-tools-r12 flash programming via flash program-m0 or
-program-srec commands was much slower than flash program-bin.  The reason for
-this performance discrepancy was that the original implementation of these
-commands from 2013 was very straightforward: they operated in one pass, reading
-the S-record image file, and as each individual S-record was read, it was turned
-into an AMFW or INFW command to loadagent.  In the case of *.m0 files generated
-by TI's hex470 post-linker, each S-record carries 30 bytes of payload, thus the
-flashing operation proceeded in 30-byte units, incurring the overhead of a
-command-response exchange for every 30 bytes.  In contrast, our current flash
-program-bin implementation sends 256 bytes of payload per each AMFW or INFW
-command; this larger unit size decreases the overhead of command-response
-exchanges between fc-loadtool and loadagent.
-
-Why do we need flash program-m0 and program-srec commands at all, why not
-simply convert all SREC images to straight binary first and then program with
-flash program-bin?  The reason is that S-record images can contain multiple
-discontiguous program regions with gaps in between.  All of our current
-FreeCalypso firmwares built with TI's TMS470 toolchain contain a few small gaps
-in the fwimage.m0 file, filled with 0xFF bytes when converted to straight binary
-with mokosrec2bin, but TI's own firmwares built for 8 MiB flash configurations
-often had much bigger gaps in them.
-
-As of fc-host-tools-r12 we finally have a more efficient solution for flashing
-discontiguous SREC images: our new implementation of flash program-m0 and
-program-srec commands begins with a preliminary pass (pure host operation, no
-target interaction) of reading the S-record image file; the payload bits are
-written into a temporary binary file (automatically deleted afterward), while
-the address and length of each discontiguous region are remembered internally.
-Then the actual flash programming operation proceeds just like program-bin,
-reading from the internal binary file and sending 256 bytes of payload at a time
-to loadagent, but using the remembered knowledge of where the discontiguous
-regions lie.
-
 XRAM loading via fc-xram
 ========================