view doc/Flash-boot-defect @ 218:c44f31353f2f
doc/TIFFS-IVA-usage updated
author
Mychaela Falconia <falcon@freecalypso.org>
date
Sat, 20 May 2017 18:28:34 +0000 (2017-05-20)
parents
de8f75783b3b
children
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.