FreeCalypso > hg > freecalypso-reveng
view compal/c139-boot.notes @ 395:00f5287db832
se_k200i/flash-notes: fix wrong number of zeros in 0x20000 address
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 01 Jan 2023 01:42:04 +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"