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.

Commands:

<a

<b

Followed by 4 bytes, giving a 32-bit value in MSB-first order.  The value is
written to 800538, and the 0x2c8 function returns code 6.

<c

<i

<p

Followed by 9 bytes:
	1 byte: goes into var at 800518
	1 byte: goes into var at 800521
	2 bytes: 16-bit MSB-first value goes into var at 800522
	1 byte: goes into var at 800525
	4 bytes: 32-bit MSG-first value goes into var at 80051C

<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
80010C: all bytes of a '<w' command after these two command chars
	are stored starting here
80050B: the above buffer ends here

800518:	byte variable receives the first parameter byte after '<p'
80051C: 32-bit var set by the '<p' command
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'
800522:	16-bit var set by the '<p' command
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

80052C: byte following the '<c' command is extended to a half-word and
	written here

800534: byte initialized to 0x00, then may be set to 1 by the 0xfb4
	routine if it selects /1 clock mode.
800538: word holds the argument of the '<b' command
80053C: byte indicates validity of the received '<w' command:
	0 means valid, 1 means something bad

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