FreeCalypso > hg > freecalypso-tools
view doc/Flash-boot-defect @ 336:ead4ee22ef62
uptools/libcoding: hex dump function implemented
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 04 Feb 2018 01:03:20 +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.