view compal/c139-boot.notes @ 239:7a394cc1c72a

pirelli/fw-disasm: spi_env code located
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 23 Dec 2017 01:13:07 +0000
parents 49c7cda96f04
children
line wrap: on
line source

Download protocol, attempted first at 406250 baud, then 115200, only on the
MODEM UART:

The boot code begins by transmitting 1B F6 02 00 41 01 40, then calls the
Rx-with-timeout function 7 times, expecting this seq: 1B F6 02 00 52 01 53.
Getting anything else or timeout causes the 0xbac function to return,
ending that download attempt.  If this seq was received, the boot code then
sends 1B F6 02 00 41 02 43 and expects to receive 3 bytes as follows:

* one dummy byte (stored into an automatic var, but then not used)
* payload length MSB
* payload length LSB

The boot code then expects to receive the specified # of bytes [0,65535]
and stores them beginning at 0x800100.  Then the Rx-with-timeout function
is called again to receive the XOR checksum byte, not counted in the length.
If the checksum fails to match, 0xbac function sends 1B F6 02 00 45 53 16
and returns.  If this check passes, the "1003" check is performed next:
the 4 bytes starting at 0x803ce0 must match.  If the downloaded image was
shorter, the comparison will be made against pre-powerup IRAM content,
i.e., law of chance.  Furthermore, the comparison is actually an inequality:
each "signature" byte in the downloaded image needs to be >= (in the signed
sense) than the "1003" reference.  (0x7F7F7F7F thus ought to be a passing
value.)

If this last check passes, the 0xbac function jumps to the downloaded image
instead of returning.  Control is transferred to 0x800100 in the ARM state.
If the "1003" check fails, 0xbac function sends 1B F6 02 00 41 03 57
and returns.

If the boot process is not diverted to a successful serial download as above,
the boot code does one strange thing before it jumps to 0x20f8 (main app entry
point).  The boot code unconditionally transmits "ftmtool" on the MODEM UART
and waits a certain time for a "yes" response.  If it receives that "yes",
it responds with "modemerror", otherwise just "error".  Either way, it then
proceed to jump to the main app entry point at 0x20f8!  There is also a bunch
of "dead" code in the 8 KiB "boot block", code which does not seem to be
reachable from any path.  There is no check for whether or not the "main app"
is present; if the flash contains the 8 KiB "boot block" followed by blank
space, the boot code will happily jumps to those FFs - but it will still
provide an opportunity for serial download as usual, so no real problem.

IRAM variables used by the boot code:

83FF00	holds UART base addr, set to FFFF5800 (MODEM)
83FF08	32-bit var init to 0
83FF10	32-bit var init to 0
83FF80	byte var init to 0 at the beginning of ftmtool function (0xdbe),
	set to 1 if "yes" received in response to "ftmtool"