FreeCalypso > hg > freecalypso-reveng
view bootrom.notes @ 16:383a4ef12551
boot ROM re: getting the download state machine, <p parsed
author | Michael Spacefalcon <msokolov@ivan.Harhan.ORG> |
---|---|
date | Thu, 25 Apr 2013 03:16:17 +0000 |
parents | 3443b1b08af4 |
children | d2206cb5f8b4 |
line wrap: on
line source
Application images in flash: In order for the nCS0 flash content to be considered a valid bootable image (i.e., for the boot ROM to transfer control to it, rather than wait forever for a UART download), the 32-bit word at address 0x2000 (the first word after the ROM-overlaid portion) must contain either 0 or 1, corresponding to two supported environment options: * If the word at 0x2000 equals 0, it signifies an application image that is designed to run with the boot ROM still mapped at 0, with ARM exceptions vectoring through the 7 magic RAM locations at 0x80001C, and possibly through the 2nd level ("user-friendly") vector table at 0x800000 as well. If the word at 0x2000 equals 0, the following word at 0x2004 must contain the absolute address of the boot entry point; the boot ROM will transfer control to that address with the FFFF:FB10 register set to explicitly map the internal boot ROM at 0. It is a BX-style address: setting the least significant bit will result in control being transferred in the Thumb state. * If the word at 0x2000 equals 1, it signifies an application image that is at least conceptually independent of the Calypso boot ROM - one that would, at least in theory, function correctly with nIBOOT tied/pulled/driven HIGH, or even on an older DBB chip with no internal boot ROM. When the boot ROM code sees a 1 in the 0x2000 word, it copies a little piece of code into the internal ROM and runs it there; this code sets the FFFF:FB10 register to disable the internal boot ROM (map the external nCS0 memory at 0, as if nIBOOT were high) and causes the watchdog timer to go off, resetting the ARM core and causing it to execute the external nCS0 reset vector. UART protocol The external host initiates every operation by sending a command to the Calypso target running the boot ROM code. Every command begins with '<' and a lowercase ASCII letter; just the initial '<' is sufficient to interrupt the flash image autoboot. The external host shound send these commands at 19200 baud, 8N1, and the boot ROM will intuit whether the Calypso is being clocked with 13 or 26 MHz by trying the two possible clocking setups alternately, with the UART baud rate registers set to /42 in both cases, until a clean '<' is received. Once the initial '<' has been received on either UART, the boot ROM only listens on that port from there onward. There is a timeout between the successive bytes of a single command, but the ROM will wait forever for another '<'. Commands: <a <b Followed by 4 bytes, giving a 32-bit value in MSB-first order. The value is written to 80052C, and the 0x2c8 function returns code 6. <c <i Calls the 0x11c routine, then responds with '>i'. <p Followed by 9 bytes: 1 byte: goes into var at 800518, selects the baud rate: 0: 115200 1: 57600 2: 38400 3: 28800 4: 19200 1 byte: goes into var at 800521, controls the 0xef4 routine: bits <6:2>: R2 arg (PLL_MULT field) bits <1:0>: R1 arg (PLL_DIV field) 2 bytes: 16-bit MSB-first value goes into var at 800522 word gives arguments to 0xe2c routine, breaks down as follows: bit 15: unused <14:10> arg3 <9:5> arg2 <4:0> arg1 1 byte: goes into var at 800525 remaining arguments to 0xe2c: <7:4> arg5 <3:0> arg4 4 bytes: 32-bit MSG-first value goes into var at 80051C reloads the UART timeout variable 800104 Good response: >p 00 04 (4 bytes total) The baud rate is switched after the above response is sent. Error response: >P <w Followed by: 1 byte: block number (of this block) 1 byte: total # of blocks 2 bytes: # of payload bytes in this block (MSB first) 4 bytes: load address for this block (MSB first) data for a single block (both bytes after <w set to 01), the maximum allowed payload length is 1015 (0x3F7) bytes. RAM layout: 800000 7 words: soft-vector pointers: by default the following 7 words at 80001C are filled with ldr-jump instructions, which read from these 7 words and load them into PC 80001C 7 words: hard vectors: the physical vector locations in the ROM contain branch instructions to these 7 RAM addresses 800038: The helper routine for transferring control to type 1 flash images is copied to and run here. 800100: the last word of the above routine 800104: word initialized to 0x0001D4C0 - tells the 0x2c8 routine how long to wait for a character 800108: byte initialized to 0x01 state variable for the serial command interface in the initial state of 01, only <i and <p are accepted state 02: after successful <p, <w is allowed state 03: after first successful <w? 80010C: all bytes of a '<w' command after these two command chars are stored starting here this buffer is also used for other scratchpad functions: <p command bytes, all response messages 80050B: the above buffer ends here The group of vars starting at 800518 may have been envisioned as a struct - see the routine at 0x11c: 800518: byte variable receives the first parameter byte after '<p' baud rate code ([0,4] range) init to 04 by '<i' 80051C: 32-bit var set by the '<p' command reloads the UART timeout variable 800104 800520: byte variable filled every time the 0xfb4 routine is called holds the ID of the UART on which '<' came in, or FF if none 800521: byte variable receives the 2nd parameter byte after '<p' PLL config 800522: 16-bit var set by the '<p' command chip select wait state config 800524: byte variable filled every time the 0xfb4 routine is called filled with a copy of 800534 800525: byte var set by the '<p' command config for the FFFF:F900 register (0xe2c routine) 800526: 16-bit var init to 0 by 0x11c ('<i' handler) byte following the '<c' command is extended to a half-word and written here 800528: 16-bit var init to 0 by 0x11c ('<i' handler) checksum accum? 80052C: 32-bit var init to 0 by 0x11c ('<i' handler) word holds the argument of the '<b' command 800530: byte indicates validity of the received '<w' command: 0 means valid, 1 means something bad init to 0 by 0x11c 800534: byte initialized to 0x00, then may be set to 1 by the 0xfb4 routine if it selects /1 clock mode. 8005C0: appears to be the intended low address (bottom) of the stack 80074C: top of the stack (initial value loaded into SP) 800750: lowest address at which user code may be loaded