view target-utils/compalstage/README @ 497:74610c4f10f7

target-utils: added 10 ms delay at the end of abb_power_off() The deosmification of the ABB access code (replacement of osmo_delay_ms() bogus delays with correctly-timed ones, which are significantly shorter) had one annoying side effect: when executing the poweroff command from any of the programs, one last '=' prompt character was being sent (and received by the x86 host) as the Calypso board powers off. With delays being shorter now, the abb_power_off() function was returning and the standalone program's main loop was printing its prompt before the Iota chip fully executed the switch-off sequence! I thought about inserting an endless tight loop at the end of the abb_power_off() function, but the implemented solution of a 10 ms delay is a little nicer IMO because if the DEVOFF operation doesn't happen for some reason in a manual hacking scenario, there won't be an artificial blocker in the form of a tight loop keeping us from further poking around.
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 25 May 2019 20:44:05 +0000
parents 56b1bab3e09b
children
line wrap: on
line source

FreeCalypso loadtools have been designed from the beginning to work through
the Calypso chip's own boot ROM.  This approach works great for Openmoko and
Pirelli targets, but Compal phones unfortunately have this Calypso boot ROM
disabled at the board level.  To run our own code in these phones instead of
booting the regular firmware, we need to go through Compal's own boot code.
The latter allows loading code into IRAM and jumping to it, but not in the
same way as how we do it through the Calypso boot ROM.

One could argue that the "proper" way to support these Compal phones would be
to build a different version of our loadagent that is designed to be loaded
through Compal's boot code instead of the Calypso boot ROM, and then redesign
our fc-loadtool and fc-xram utilities to work with different loadagents loaded
in different ways on different target devices.  But I don't feel like doing
that - too invasive to the once-clean design of loadtools.

Hence I am adopting a different solution that works in the same way as
OsmocomBB's "chain loading": the IRAM image that is fed to Compal's boot code
is not our real loadagent, but a tiny piece of code that enables the Calypso
boot ROM and jumps to it.  All loadtools host programs will include this
optional "Compal stage" at the beginning, enabled for targets that need it,
but will then always fall into the Calypso boot ROM IRAM download path.

The approach I'm adopting is doubly inefficient for Mot C139/140 phones whose
bootloader effectively requires that the downloaded image be ~15 KiB long
even when we only need to download 32 bytes.  But hey, our ultimate goal is to
produce our own Calypso phones, rather than hack those made by diabolical
manufacturers who do not Respect Your Freedom; running our own firmware on the
Mot C139 is only a transitional step, so making fc-loadtool/fc-xram entry
slower by a second or two is probably an acceptable price for keeping the
code clean for the boot-ROM-enabled free world.

In this directory we build the several different versions of compalstage
needed for different C1xx models.