FreeCalypso > hg > freecalypso-reveng
changeset 14:3443b1b08af4
boot ROM re: starting to unravel the serial command handling
messed up earlier with some var locations: the darned offsets were decimal
author | Michael Spacefalcon <msokolov@ivan.Harhan.ORG> |
---|---|
date | Wed, 24 Apr 2013 23:49:39 +0000 |
parents | e0ce45f043c0 |
children | 2e3cecd6716c |
files | bootrom.disasm bootrom.notes |
diffstat | 2 files changed, 45 insertions(+), 25 deletions(-) [+] |
line wrap: on
line diff
--- a/bootrom.disasm Wed Apr 24 22:48:12 2013 +0000 +++ b/bootrom.disasm Wed Apr 24 23:49:39 2013 +0000 @@ -90,6 +90,9 @@ 114: eb000513 bl 0x1568 ; IND_CALL 118: eafffffe b 0x118 +; This routine handles the '<i' command - it initializes the vars +; starting at 800518. It is called with R0=0x800518. + 11c: e3a0c004 mov r12, #4 ; 0x4 120: e5c0c000 strb r12, [r0] 124: e3a0c000 mov r12, #0 ; 0x0 @@ -99,30 +102,35 @@ 134: e5c0c018 strb r12, [r0, #24] 138: e12fff1e bx lr +; This routine at 0x13c apparently generates the serial response messages +; back to the host, using the buffer at 80010C as its scratchpad. +; The argument in R0 encodes what type of message to generate: + 13c: e92d4000 stmdb sp!, {lr} 140: e1a0c000 mov r12, r0 - 144: e59f0cc0 ldr r0, [pc, #3264] ; 0xe0c + 144: e59f0cc0 ldr r0, =0x80010C ; via 0xe0c 148: e3a0103e mov r1, #62 ; 0x3e 14c: e5c01000 strb r1, [r0] 150: e35c0009 cmp r12, #9 ; 0x9 154: 88bd8000 ldmhiia sp!, {pc} 158: e28f1000 add r1, pc, #0 ; 0x0 15c: e791f10c ldr pc, [r1, r12, lsl #2] - 160: 000002ac andeq r0, r0, r12, lsr #5 - 164: 00000280 andeq r0, r0, r0, lsl #5 - 168: 00000264 andeq r0, r0, r4, ror #4 - 16c: 00000248 andeq r0, r0, r8, asr #4 - 170: 00000224 andeq r0, r0, r4, lsr #4 - 174: 00000200 andeq r0, r0, r0, lsl #4 - 178: 000001dc ldreqd r0, [r0], -r12 - 17c: 000001c0 andeq r0, r0, r0, asr #3 - 180: 000001a4 andeq r0, r0, r4, lsr #3 - 184: 00000188 andeq r0, r0, r8, lsl #3 - - 188: e3a0c042 mov r12, #66 ; 0x42 +; switch table, absolute addresses + 160: 000002ac + 164: 00000280 + 168: 00000264 + 16c: 00000248 + 170: 00000224 + 174: 00000200 + 178: 000001dc + 17c: 000001c0 + 180: 000001a4 + 184: 00000188 +; case 9: + 188: e3a0c042 mov r12, #66 ; 0x42 'B' 18c: e5c0c001 strb r12, [r0, #1] 190: e3a01002 mov r1, #2 ; 0x2 - 194: e59fcc74 ldr r12, [pc, #3188] ; 0xe10 + 194: e59fcc74 ldr r12, =0x800520 ; via 0xe10 198: e5dc2000 ldrb r2, [r12] 19c: eb000458 bl 0x1304 1a0: e8bd8000 ldmia sp!, {pc} @@ -225,11 +233,11 @@ ; 01 = got 'i' ; 02 = got 'p', 9 additional bytes received, a bunch of vars filled ; 03 = got 'w', the rest of the command read into the buffer at -; 80010C, the flag at 80053C set +; 80010C, the flag at 800530 set ; 04 = got 'c', 1 additional byte received, extended to a half-word -; and written to 80052C +; and written to 800526 ; 05 = got 'a' -; 06 = got 'b', 4 bytes written to 800538 +; 06 = got 'b', 4 bytes written to 80052C 2c8: e92d4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr} 2cc: e24dd004 sub sp, sp, #4 ; 0x4 @@ -258,7 +266,7 @@ 328: e25cc007 subs r12, r12, #7 ; 0x7 'w' 32c: 1a0000fc bne 0x724 ; got 'w' -; R4=0x800518, byte at 80053C used for something, init to 0 +; R4=0x800518, byte at 800530 used for something, init to 0 330: e5c45018 strb r5, [r4, #24] 334: e3a0a000 mov r10, #0 ; 0x0 338: e3a06000 mov r6, #0 ; 0x0 @@ -635,7 +643,7 @@ 8b4: e92d4070 stmdb sp!, {r4, r5, r6, lr} 8b8: e24dd008 sub sp, sp, #8 ; 0x8 - 8bc: e59f4560 ldr r4, [pc, #1376] ; 0xe24 + 8bc: e59f4560 ldr r4, =0x800108 ; via 0xe24 8c0: e5d4c000 ldrb r12, [r4] 8c4: e25cc001 subs r12, r12, #1 ; 0x1 8c8: 0a000102 beq 0xcd8 @@ -898,6 +906,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 cd8: e250c001 subs r12, r0, #1 ; 0x1 cdc: 0a000040 beq 0xde4 ce0: e25cc001 subs r12, r12, #1 ; 0x1 @@ -965,7 +974,8 @@ dd8: e3a0c002 mov r12, #2 ; 0x2 ddc: e5c4c000 strb r12, [r4] de0: ea000005 b 0xdfc - de4: e59f0018 ldr r0, [pc, #24] ; 0xe04 +; response to '<i' is handled here + de4: e59f0018 ldr r0, =0x800518 ; via 0xe04 de8: ebfffccb bl 0x11c dec: e3a00000 mov r0, #0 ; 0x0 df0: ebfffcd1 bl 0x13c
--- a/bootrom.notes Wed Apr 24 22:48:12 2013 +0000 +++ b/bootrom.notes Wed Apr 24 23:49:39 2013 +0000 @@ -90,9 +90,15 @@ 800108: byte initialized to 0x01 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' + init to 04 by '<i' 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 @@ -101,15 +107,19 @@ 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 +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) -80052C: byte following the '<c' command is extended to a half-word and - written here +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. -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)