FreeCalypso > hg > freecalypso-reveng
diff compal/boot/c139-boot.notes @ 399:81cda18b0487
compal: move all bootloader analysis work into boot subdir
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 14 Jan 2023 06:17:56 +0000 |
parents | compal/c139-boot.notes@49c7cda96f04 |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/compal/boot/c139-boot.notes Sat Jan 14 06:17:56 2023 +0000 @@ -0,0 +1,49 @@ +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"