view doc/FCDEV3B-V1-issues @ 673:62a5285e014a

Lorekeeping: allow tpudrv-leonardo.lib on Leonardo/Tango Back in 2015 the Mother's idea was to produce a FreeCalypso development board that would be a clone of TI Leonardo, including the original quadband RFFE; one major additional stipulation was that this board needed to be able to run original unmodified TCS211-20070608 firmware with all blobs intact, with only minimal binary patches to main.lib and tpudrv.lib. The necessary patched libs were produced at that time in the tcs211-patches repository. That plan was changed and we produced FCDEV3B instead, with Openmoko's triband RFFE instead of Leonardo quadband, but when FC Magnetite started in 2016, a TPUDRV_blob= provision was still made, allowing the possibility of patching OM's tpudrv.lib for a restored Leonardo RFFE. Now in 2020 we have FC Tango which is essentially a verbatim clone of Leonardo core, including the original quadband RFFE. We have also deblobbed our firmware so much that we have absolutely no real need for a blob version of tpudrv.lib - but I thought it would be neat to put the ancient TPUDRV_blob= mechanism (classic config) to its originally intended use, just for the heck of it.
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 29 May 2020 03:55:36 +0000
parents 29c0be5a1962
children
line wrap: on
line source

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.