Our early FCDEV3B boards (the first two batches made in 2017, now retroactively
called FCDEV3B V1) had a hardware design defect that affected sleep modes; this
defect has been fixed on our current FCDEV3B V2 boards.  The design defect on
FCDEV3B V1 was as follows: the reset input to the flash chip was connected to
Calypso's FDP output per both TI's Leonardo reference schematics and Openmoko's
working design, but this arrangement turns out to be unsuitable for the high-
capacity Spansion S71PL129NC0HFW4B flash+pSRAM chip we are using, copied from
Pirelli DP-L10.  Calypso always drives its FDP output low during all sleep
periods, including small sleep which can be arbitrarily short, and while TI may
have thought it was a good idea to plunge the flash chip into reset during all
sleeps, even ultra-short ones, newer flash chips like our current Spansion part
are not happy with such reset timing.  The datasheet for S29PL-N flash (the
flash part of S71PL-N MCPs) says that the minimum reset pulse width must be
30 us, and the "dance" put out on FDP by the Calypso during certain rapid
sleep-wake sequences appears to violate this timing requirement.  Furthermore,
with our current flash chips (both our chosen Spansion part and OM's original
Samsung K5A32xx) there is no power saving advantage to putting the flash chip
into reset (in fact, with Spansion flash it is the opposite according to the
datasheet!), hence the solution is straightforward: on our current FCDEV3B V2
boards we have disconnected FDP from the flash chip, and we use a different
circuit to provide our flash chip with the reset which it requires.

The practical effect of the just-described hw defect on FCDEV3B V1 boards is
that all sleep modes must be disabled when the firmware is running from flash
(run-from-RAM firmwares are not affected), otherwise the firmware will
erratically hang or self-reboot on certain sleep-wake sequences.  If you have
an FCDEV3B V1 board and you would like to run our current FC Magnetite firmware
on it, you have two options for disabling sleep:

Option 1: You can flash a regular sleep-enabled fw build, and then on every
boot, before doing anything else, issue an AT%SLEEP=0 command to disable all
sleep modes.

Option 2: You can compile a special fw build that boots with all sleep modes
disabled:

./configure.sh fcdev3b hybrid DISABLE_SLEEP=1 SUFFIX=-nosleep

Additionally, there was one (only one) FCDEV3B V1 board from the very first
batch (kept by the Mother and not sold or given away to anyone) that had
trouble booting from flash on normal power-up.  By Murphy's law, it just
happened to be the one board on which our very initial bring-up work was done.
RAM-loaded fw booted fine, interrupting the boot process serially and having
the serially loaded code jump to the image in flash also worked fine, but
regular flash boot exhibited erratic behaviour.  Eventually it was found that
the flash boot problem on that one board occurs only when flash boot mode 1 is
used, whereas flash boot mode 0 works fine.  I (Mychaela) suspect that the
problem has something to do with the watchdog reset that happens as part of
flash boot mode 1, the FDP output behaviour during that watchdog reset, and the
flash chip's reaction to the latter.

The fcdev3b-hacks directory contains two hacks that can be applied to FCDEV3B
firmware images (fwimage.bin builds) as xxd binary patches:

* The first hack dating from 2017-05 patches the fw to use flash boot mode 0
  instead of TI's original flash boot mode 1, but after boot the FFFF:FB10
  register is set to put the flash and not the internal ROM at address 0, so
  the interrupt and exception vectors go to the flash like in TI's original fw,
  not through the internal ROM.  This hack was put together for the purpose of
  producing flashable fw images that boot without problems on that one board on
  which flash boot mode 1 didn't work, and worked successfully for that purpose.

* The second hack dating from 2018-03 patches the fw to not only use flash boot
  mode 0, but also route the interrupt and exception vectors through Calypso's
  internal ROM.  I was hoping that this hack would make the sleep mode problem
  go away without a hardware respin by having the Calypso execute some cycles
  out of its internal ROM and RAM before hitting the flash after wakeup, but
  nope, bringing up the SIM interface with AT+CFUN=1 in the l1reconst config
  when running from flash with small sleep enabled still triggers erratic
  misbehaviour even with this patch.

Just to reiterate, none of these hacks are needed for our current FCDEV3B V2
boards - instead I am merely preserving our development history here.