Our current FCDEV3B boards exhibit a hardware bug: the reset input to the flash
chip is 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.  This hardware bug has manifested itself
in two different ways so far:

* Out of the 20 boards we've built so far, on just one board there was an issue
  where our standard Magnetite fw would have trouble booting from flash, but
  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.
  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.

* On all of the boards there is a problem with sleep modes: when the firmware
  is running from flash as opposed to RAM, certain sleep-wake sequences cause
  an erratic self-reboot or a hang.  Oscilloscope probing on a decased Pirelli
  DP-L10 motherboard on which Calypso's FDP output is accessible seems to
  confirm my (Mychaela's) suspicion that this FDP signal goes low during all
  sleep modes, and the current working hypothesis is that our Spansion flash
  chip gets unhappy with the reset timing it gets subjected to, and some flash
  reads (instruction fetches) don't work after wakeup.  So far the only workable
  solution has been to disable all sleep modes in all FCDEV3B fw builds;
  nothing else has been successful.  However, re-enabling all of these sleep
  modes with AT%SLEEP=4 works fine when the firmware image executes out of RAM
  instead of flash, further supporting our current working hypothesis as to the
  root cause.

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 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.

The proper fix will require a new PCB spin to change the flash reset wiring:
instead of driving it with Calypso's FDP output, use the ON_nOFF master reset
signal from Iota's VRPC block, fed through a logic voltage level translating
buffer to change it from 1.5 V to 2.8 V logic.  The flash chip we are using has
lower power consumption when it is NOT held in reset, hence unlike TI's intent
with FDP, we don't want our flash chip to go into reset during any sleep at all.

The new PCB revision with this change is now in the process of being finalized,
and we will soon need the funding to produce the new boards.  Anyone who is
interested in helping to make FCDEV3B V2 a reality should email Mychaela.