--- a/doc/Flash-boot-defect	Fri Oct 26 07:03:21 2018 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,49 +0,0 @@
-As of this writing (2017-05-01), there is an unexplained hardware problem on
-some of our FCDEV3B boards in that flashed firmware images which use flash boot
-mode 1 (see the Flash-boot-modes article) fail to boot.  It is not currently
-known how many boards are affected by this problem; it is possible that the
-Mother's S/N 001 board is the only one that exhibits this oddity.
-
-This problem particularly affects our FC Magnetite firmware, as the latter uses
-flash boot mode 1 just like TI's TCS211 fw from which it originates.  OTOH, our
-FC Citrine firmware, which uses flash boot mode 0, boots just fine.  A minimal
-test case has been created under target-utils/flash-boot-test in this
-repository: it is a simple loadagent-like standalone application that is built
-to be booted from flash instead of expecting to be loaded serially, and it is
-built in two versions, one for mode 0 and another for mode 1.  Both versions
-work on an Openmoko-made GTA02 (the mode 1 version continuously reboots every
-few seconds because it doesn't disable the watchdog timer, but it is still very
-clearly alive) as well as on those FCDEV3B boards which aren't affected, but on
-FCDEV3B S/N 001 the mode 1 version fails to boot just like the full Magnetite
-firmware.
-
-The Mother of FreeCalypso does not currently have any prognosis as to when or
-even if the mysterious hardware problem that causes flash boot mode 1 to fail
-can be fixed.  Logical reasoning tells us that it must be a hardware problem,
-as the flash boot mode in question works without a hitch on every pre-existing
-Calypso device known to us, and similar logical reasoning tells us that the
-watchdog timer probably has to be involved in some way, as it is the mechanism
-underlying flash boot mode 1 (again, see the Flash-boot-modes article), but I
-am at a total loss when it comes to what kind of board-level problem could
-possibly produce such behaviour.  But then if only the S/N 001 board is affected
-and no others, it could just be a defective chip.  More data points need to be
-gathered before we shall know whether or not we have a real problem.
-
-For those who do have a flash-boot-challenged FCDEV3B board, two workarounds
-have been developed, in this chronological order:
-
-1. One can boot the board in the serial download mode, and download a
-   teensy-tiny piece of code that disables the boot ROM and jumps to address 0.
-   If the flash contains a firmware image meant to be booted in mode 1, this
-   image will get indirectly booted in this manner.  Run a command like this:
-
-fc-iram -h fcfam /dev/ttyXXX /opt/freecalypso/target-bin/flash-boot-wa.srec rvinterf
-
-(fc-iram has been extended to support second program invokation just like
- fc-xram, just for this peculiar use case.  The flash-boot-wa.srec helper can
- also be booted via fc-xram.)
-
-2. After doing the above, I found a way to patch the Magnetite firmware image
-   to boot in mode 0 - see the Flash-boot-mode-hack write-up in the Magnetite
-   source tree.  With this patch applied, FC Magnetite happily boots directly
-   from flash on my board without needing fc-iram or fc-xram assistance.

--- a/doc/Loadtools-usage	Fri Oct 26 07:03:21 2018 +0000
+++ b/doc/Loadtools-usage	Fri Oct 26 07:11:08 2018 +0000
@@ -257,4 +257,5 @@
 rvinterf or rvtdump.
 
 This second program invokation capability was later extended to fc-iram for no
-purpose other than to support a hack described in the Flash-boot-defect article.
+purpose other than to facilitate a boot hack that was only needed on one (1)
+defective FCDEV3B board.