Still digging how timer interrupt works...
Thanks to the progress made after following leegong's pointer to the
REALOS kernel manual (should have RTFM sooner
), we now have a much clearer view of system calls.
I thought it would be interesting to follow the System Clock related calls, because as stated in section 2., the system clock is run by the hardware interrupt timer ticking every millisecond, so that should lead us to that interrupt.
So let's start with the set_tim() call described at paragraph 4.8.1. which takes as parameter a pointer (R4) to a 64-bit structure representing the time to set. Its 16 highest bits are unused, and the 48 lower ones count milliseconds since jan 1st, 1985.
In the D5100, its implementation goes :
- Code: Select all
000410E8 8B4E MOV R4,FP
000410EA 4015 LDUH @(FP,0x02),R5
000410EC 2016 LD @(FP,0x004),R6
000410EE 8B57 MOV R5,R7
000410F0 B107 LSR #16,R7
000410F2 E444 BC part_2_of_unknown_410e6_ ; (skip)
000410F4 83EF AND #0xEF,CCR
000410F6 9F8E 6800 0910 LDI:32 #0x68000910,FP
000410FC 3016 ST R6,@(FP,0x004)
000410FE 3005 ST R5,@(FP,0x000)
00041100 9310 OR #0x10,CCR
00041102 9F20 RET:D
00041104 C00C LDI:8 #0x00,R12
part_2_of_unknown_410e6_:
0004117C 9F20 RET:D
0004117E CDFC LDI:8 #0xDF,R12
In other words, the 16+32 bits pointed to by R4 are stored to addresses 0x68000910 / 0x68000914.
To make sure values are consistent, the calls are protected inside a "synchronized" block, as interrupts are disabled before (AND #0xEF,CCR) and reenabled after (OR #0x10,CCR) modifying the value.
The get_tim() at 0x41106 is the exact symmetric, reading back 0x68000910 / 14 in a synchronized block and writing the value back to the passed structure.
That address, 0x68000910 is also used by sys_def_alm(), which sounds logical, but also by sub_40c4e_() which starts with :
- Code: Select all
; ************************************************************************
; sub_40c4e_()
; ************************************************************************
00040C4E 1781 PUSH RP
00040C50 170E PUSH FP
00040C52 9F8E 6800 0910 LDI:32 #0x68000910,FP
00040C58 83EF AND #0xEF,CCR
00040C5A C003 LDI:8 #0x00,R3
00040C5C 2006 LD @(FP,0x000),R6
00040C5E 2017 LD @(FP,0x004),R7
00040C60 A417 ADD #0x1,R7
00040C62 A736 ADDC R3,R6
00040C64 3017 ST R7,@(FP,0x004)
00040C66 3006 ST R6,@(FP,0x000)
00040C68 9310 OR #0x10,CCR
...
How interesting : the clock value is read into R6 (higher) and R7 (lower), R7 is incremented and its carry bit is added to R6, and the clock gets written back.
So obviously this is the code incrementing the system clock and it is called by... int_0x18
Sounds like we can make that clock tick
Best regards,
Vicne
