view doc/Flash-boot-defect @ 412:a5dab452be0d

mokosrec2bin utility imported from the old freecalypso-reveng tree, header comments changed for new understanding and new usage in forward rather than reverse engineering
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 25 Oct 2018 19:23:35 +0000
parents de8f75783b3b
children
line wrap: on
line source

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.