FreeCalypso > hg > freecalypso-reveng
changeset 18:123cb5021b64
boot ROM re: appears to be complete!
author | Michael Spacefalcon <msokolov@ivan.Harhan.ORG> |
---|---|
date | Thu, 25 Apr 2013 05:47:59 +0000 |
parents | d2206cb5f8b4 |
children | 2d9c927cc24b |
files | bootrom.disasm bootrom.notes |
diffstat | 2 files changed, 78 insertions(+), 24 deletions(-) [+] |
line wrap: on
line diff
--- a/bootrom.disasm Thu Apr 25 04:07:10 2013 +0000 +++ b/bootrom.disasm Thu Apr 25 05:47:59 2013 +0000 @@ -77,16 +77,21 @@ e8: 000080f5 ; end of the code copied to the internal RAM for booting type 1 images +; The routine at 0xec effects the jump to the serially loaded code +; upon the final '<b' command. + ec: e92d4010 stmdb sp!, {r4, lr} - f0: e59fcd0c ldr r12, [pc, #3340] ; 0xe04 + f0: e59fcd0c ldr r12, =0x800518 ; via 0xe04 f4: e59c4014 ldr r4, [r12, #20] - f8: e59f0d08 ldr r0, [pc, #3336] ; 0xe08 + f8: e59f0d08 ldr r0, =0x1FCC ; via 0xe08 fc: e5dcc008 ldrb r12, [r12, #8] 100: e790c10c ldr r12, [r0, r12, lsl #2] 104: e28c0005 add r0, r12, #5 ; 0x5 +; wait for all UART Tx to go out 108: e5d0c000 ldrb r12, [r0] 10c: e31c0040 tst r12, #64 ; 0x40 110: 0afffffc beq 0x108 +; jump! 114: eb000513 bl 0x1568 ; IND_CALL 118: eafffffe b 0x118 @@ -164,7 +169,7 @@ 200: e3a0c063 mov r12, #99 ; 0x63 'c' 204: e5c0c001 strb r12, [r0, #1] 208: e59fcbf4 ldr r12, =0x800518 ; via 0xe04 - 20c: e5dc1010 ldrb r1, [r12, #16] + 20c: e5dc1010 ldrb r1, [r12, #16] ; byte from 800528 210: e5c01002 strb r1, [r0, #2] 214: e5dc2008 ldrb r2, [r12, #8] 218: e3a01003 mov r1, #3 ; 0x3 @@ -665,6 +670,7 @@ 8dc: e25cc001 subs r12, r12, #1 ; 0x1 8e0: 1a000145 bne 0xdfc ; state 04 +; like in state 03, '<p' is ignored in this state 8e4: e250c001 subs r12, r0, #1 ; 0x1 8e8: 0a00003c beq 0x9e0 8ec: e25cc002 subs r12, r12, #2 ; 0x2 @@ -675,29 +681,40 @@ 900: 0a000017 beq 0x964 904: e25cc001 subs r12, r12, #1 ; 0x1 908: 1a00013b bne 0xdfc - 90c: e59f54f0 ldr r5, [pc, #1264] ; 0xe04 - 910: e59f0500 ldr r0, [pc, #1280] ; 0xe18 +; '<b' in state 04 + 90c: e59f54f0 ldr r5, =0x800518 ; via 0xe04 + 910: e59f0500 ldr r0, =0x800750 ; via 0xe18 914: e595c014 ldr r12, [r5, #20] 918: e15c0000 cmp r12, r0 91c: 3a000006 bcc 0x93c - 920: e59f14f4 ldr r1, [pc, #1268] ; 0xe1c + 920: e59f14f4 ldr r1, =0x7F8AF ; via 0xe1c 924: e0810000 add r0, r1, r0 928: e15c0000 cmp r12, r0 92c: 8a000002 bhi 0x93c +; all clear - respond with '<b' 930: e3a00008 mov r0, #8 ; 0x8 934: ebfffe00 bl 0x13c +; and leap! 938: ebfffdeb bl 0xec +; address bad +; respond with >B 93c: e3a00009 mov r0, #9 ; 0x9 940: ebfffdfd bl 0x13c +; baud rate reset to 19200 944: e5d51008 ldrb r1, [r5, #8] 948: e3a00004 mov r0, #4 ; 0x4 94c: eb0002a1 bl 0x13d8 +; var reset 950: e1a00005 mov r0, r5 954: ebfffdf0 bl 0x11c +; state back to 01 958: e3a0c001 mov r12, #1 ; 0x1 95c: e5c4c000 strb r12, [r4] 960: ea000125 b 0xdfc - 964: e59f5498 ldr r5, [pc, #1176] ; 0xe04 +; '<a' in state 04 +; same handling as in states 02 and 03: +; var reset, baud rate back to 19200, state back to 01, no response msg + 964: e59f5498 ldr r5, =0x800518 ; via 0xe04 968: e1a00005 mov r0, r5 96c: ebfffdea bl 0x11c 970: e5d51008 ldrb r1, [r5, #8] @@ -706,9 +723,11 @@ 97c: e3a0c001 mov r12, #1 ; 0x1 980: e5c4c000 strb r12, [r4] 984: ea00011c b 0xdfc +; '<c' in state 04 +; >C error, reset everything like other errors 988: e3a00006 mov r0, #6 ; 0x6 98c: ebfffdea bl 0x13c - 990: e59f546c ldr r5, [pc, #1132] ; 0xe04 + 990: e59f546c ldr r5, =0x800518 ; via 0xe04 994: e5d51008 ldrb r1, [r5, #8] 998: e3a00004 mov r0, #4 ; 0x4 99c: eb00028d bl 0x13d8 @@ -717,18 +736,26 @@ 9a8: e3a0c001 mov r12, #1 ; 0x1 9ac: e5c4c000 strb r12, [r4] 9b0: ea000111 b 0xdfc +; '<w' in state 04 +; respond with >W error 9b4: e3a00004 mov r0, #4 ; 0x4 9b8: ebfffddf bl 0x13c - 9bc: e59f5440 ldr r5, [pc, #1088] ; 0xe04 +; baud rate reset to 19200 + 9bc: e59f5440 ldr r5, =0x800518 ; via 0xe04 9c0: e5d51008 ldrb r1, [r5, #8] 9c4: e3a00004 mov r0, #4 ; 0x4 9c8: eb000282 bl 0x13d8 +; var init 9cc: e1a00005 mov r0, r5 9d0: ebfffdd1 bl 0x11c +; state back to 01 9d4: e3a0c001 mov r12, #1 ; 0x1 9d8: e5c4c000 strb r12, [r4] 9dc: ea000106 b 0xdfc - 9e0: e59f041c ldr r0, [pc, #1052] ; 0xe04 +; '<i' in state 04 +; same handling as in states 02 and 03: vars reset, but UART left alone +; and the state remains 04. + 9e0: e59f041c ldr r0, =0x800518 ; via 0xe04 9e4: ebfffdcc bl 0x11c 9e8: e3a00000 mov r0, #0 ; 0x0 9ec: ebfffdd2 bl 0x13c @@ -736,6 +763,7 @@ 9f4: e5c4c000 strb r12, [r4] 9f8: ea0000ff b 0xdfc ; state 03 +; '<p' is ignored in this state 9fc: e250c001 subs r12, r0, #1 ; 0x1 a00: 0a000037 beq 0xae4 a04: e25cc002 subs r12, r12, #2 ; 0x2 @@ -746,9 +774,11 @@ a18: 0a00000c beq 0xa50 a1c: e25cc001 subs r12, r12, #1 ; 0x1 a20: 1a0000f5 bne 0xdfc +; got '<b' in state 03 +; send >B, same error handling as in state 02 a24: e3a00009 mov r0, #9 ; 0x9 a28: ebfffdc3 bl 0x13c - a2c: e59f53d0 ldr r5, [pc, #976] ; 0xe04 + a2c: e59f53d0 ldr r5, =0x800518 ; via 0xe04 a30: e5d51008 ldrb r1, [r5, #8] a34: e3a00004 mov r0, #4 ; 0x4 a38: eb000266 bl 0x13d8 @@ -757,7 +787,9 @@ a44: e3a0c001 mov r12, #1 ; 0x1 a48: e5c4c000 strb r12, [r4] a4c: ea0000ea b 0xdfc - a50: e59f53ac ldr r5, [pc, #940] ; 0xe04 +; got '<a' in state 03 +; var reset, baud rate back to 19200, state back to 01, no response msg + a50: e59f53ac ldr r5, =0x800518 ; via 0xe04 a54: e1a00005 mov r0, r5 a58: ebfffdaf bl 0x11c a5c: e5d51008 ldrb r1, [r5, #8] @@ -766,7 +798,8 @@ a68: e3a0c001 mov r12, #1 ; 0x1 a6c: e5c4c000 strb r12, [r4] a70: ea0000e1 b 0xdfc - a74: e59fc388 ldr r12, [pc, #904] ; 0xe04 +; got '<c' in state 03 + a74: e59fc388 ldr r12, =0x800518 ; via 0xe04 a78: e3a010ff mov r1, #255 ; 0xff a7c: e1dc01b0 ldrh r0, [r12, #16] a80: e1c10000 bic r0, r1, r0 @@ -774,14 +807,17 @@ a88: e20cc0ff and r12, r12, #255 ; 0xff a8c: e150000c cmp r0, r12 a90: 1a000004 bne 0xaa8 +; checksum match - respond with >c and advance to state 04 a94: e3a00005 mov r0, #5 ; 0x5 a98: ebfffda7 bl 0x13c a9c: e3a0c004 mov r12, #4 ; 0x4 aa0: e5c4c000 strb r12, [r4] aa4: ea0000d4 b 0xdfc +; checksum mismatch: respond with >C, reset vars, reset the baud rate to 19200, +; reset the state to 01 aa8: e3a00006 mov r0, #6 ; 0x6 aac: ebfffda2 bl 0x13c - ab0: e59f534c ldr r5, [pc, #844] ; 0xe04 + ab0: e59f534c ldr r5, =0x800518 ; via 0xe04 ab4: e1a00005 mov r0, r5 ab8: ebfffd97 bl 0x11c abc: e5d51008 ldrb r1, [r5, #8] @@ -790,11 +826,17 @@ ac8: e3a0c001 mov r12, #1 ; 0x1 acc: e5c4c000 strb r12, [r4] ad0: ea0000c9 b 0xdfc +; got '<w' in state 03 ad4: ebffff15 bl 0x730 ad8: e3500000 cmp r0, #0 ; 0x0 - adc: 0a000038 beq 0xbc4 - ae0: ea00003a b 0xbd0 - ae4: e59f0318 ldr r0, [pc, #792] ; 0xe04 +; same outcome as in state 02 + adc: 0a000038 beq 0xbc4 ; good + ae0: ea00003a b 0xbd0 ; bad +; got '<i' in state 03 +; same as in state 02: the init routine is called (most notably the chksum +; accum is reset), the baud rate var is reset to 04, but the UART is not +; reprogrammed, and the state remains 03. + ae4: e59f0318 ldr r0, =0x800518 ; via 0xe04 ae8: ebfffd8b bl 0x11c aec: e3a00000 mov r0, #0 ; 0x0 af0: ebfffd91 bl 0x13c @@ -946,7 +988,7 @@ ccc: e3a0c002 mov r12, #2 ; 0x2 cd0: e5c4c000 strb r12, [r4] cd4: ea000048 b 0xdfc -; in the initial state, with [800108]==1, control comes here +; state 01 dispatch cd8: e250c001 subs r12, r0, #1 ; 0x1 cdc: 0a000040 beq 0xde4 ce0: e25cc001 subs r12, r12, #1 ; 0x1 @@ -954,6 +996,7 @@ ce8: e24cc001 sub r12, r12, #1 ; 0x1 cec: e35c0003 cmp r12, #3 ; 0x3 cf0: 8a000041 bhi 0xdfc +; everything other than '<i' and '<p' cf4: e59f5108 ldr r5, =0x800518 ; via 0xe04 cf8: e1a00005 mov r0, r5 cfc: ebfffd06 bl 0x11c @@ -965,7 +1008,7 @@ d0c: e3a0c001 mov r12, #1 ; 0x1 d10: e5c4c000 strb r12, [r4] d14: ea000038 b 0xdfc -; '<p' handler ([800108]==1) +; '<p' handler (state 01) d18: e59f60e4 ldr r6, =0x800518 ; via 0xe04 d1c: e5d6c000 ldrb r12, [r6] d20: e35c0000 cmp r12, #0 ; 0x0 @@ -2006,8 +2049,8 @@ ; The filler ends at 0x1FCC. Then we've got some data words: ; base addresses of the two UARTs - 1fcc: ffff5800 - 1fd0: ffff5000 + 1fcc: ffff5800 ; MODEM + 1fd0: ffff5000 ; IrDA ; UART baud rates 1fd4: 0700 ; /7 (115200?) 1fd6: 0e00 ; /14 (57600?)
--- a/bootrom.notes Thu Apr 25 04:07:10 2013 +0000 +++ b/bootrom.notes Thu Apr 25 05:47:59 2013 +0000 @@ -58,6 +58,12 @@ <c +Checksum verification command. The <c characters need to be followed by a +single binary byte, which need to equal the one's complement of the low byte +of the 800528 accumulator. + +Response: >c if good, >C if bad. Both are followed by the low byte of 800528. + <i Calls the 0x11c routine, then responds with '>i'. @@ -101,9 +107,13 @@ 4 bytes: load address for this block (MSB first) data -for a single block (both bytes after <w set to 01), the maximum allowed +For a single block (both bytes after <w set to 01), the maximum allowed payload length is 1015 (0x3F7) bytes. +No alignment required on the address or length - the copying from the +intermediate buffer at 80010C to the specified load address is done +with a loop that does one byte at a time with ldrb and strb instructions. + The checksum of each block is computed as a simple ripple-carry sum (in a 32-bit ARM register) of: + the word-sized payload byte count from the command @@ -136,7 +146,8 @@ 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? + state 03: after first successful <w, and subsequent successful <w's + state 04: after <c with matching checksum 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 @@ -168,7 +179,7 @@ checksum accum? 80052C: 32-bit var init to 0 by 0x11c ('<i' handler) - word holds the argument of the '<b' command + word holds the argument of the '<b' command, i.e., the branch address 800530: byte indicates validity of the received '<w' command: 0 means valid, 1 means something bad init to 0 by 0x11c