Aims
----
To remove the RTC hardware knowhow from the kernel.

Background
----------
Currently the handling of real time clocks is somewhat diffuse, some platforms present a HAL device which describes the RTC, and some rely on the kernel to probe known IIC addresses after which the kernel manages the hardware using its built in drivers. The kernel doesn't need an RTC to boot (compare with the other hardware it knows about: RAM, ROM, CPU, CMOS) so doesn't need to hang on to managing this driver.

The RTCAdjust module also talks to the clock, effectively containing a duplicate (read only) set of hardware drivers for the IIC addresses the kernel understands. Currently RTCAdjust doesn't support the HAL device based clocks, hence platforms presenting their clocks via that interface can be subject to drift while the computer is running.

Lastly, where enabled, the NetTime module can request updates to the clock from a remote time server. It contains yet another duplicate set of clock correction code, using the same algorithm as RTCAdjust. 

Proposed SWIs
-------------
The RTC module provides 4 SWIs.

For a definition of 'rtctime' see the HALDeviceSysPeri_RTC. All rtctime values are in UTC, any timezone and daylight saving changes are applied higher up the software stack.

_kernel_oserror *RTC_Features(int *flags);
A rough parallel to FileCore_Features allowing functionality to be added later and for clients to be able to determine the extra (potentially incompatible) programmer interfaces. Also, can be used as a cheap test of whether the module is present or not. All flags are initially zero.

_kernel_oserror *RTC_Read(struct rtctime *);
This is broadly equivalent to the kernel's ReadTime function. The time is read from the hardware.

_kernel_oserror *RTC_Write(const struct rtctime *);
This is broadly equivalent to the kernel's SetTime function. The time is written to the hardware.

_kernel_oserror *RTC_Adjust(int64_t correction, uint32_t period, uint32_t priority);
Propose a time slew 'correction' to apply over the next 'period'. The value of 'priority' will indicate the quality of the time correction, allowing adjustments potentially from multiple sources - for example a default adjustment by checking the hardware clock and an external adjustment from a trusted time server. The priority values will be centrally allocated, possibly in a simple text description (in a similar manner to the task priority assignments as used by the RTSupport scheduler).

Proposed commands
-----------------
No star commands offered.

Implementation
--------------
The module will be written in C.

This module will only operate on HAL based systems, since there's no net increase in functionality and the RTC is currently served by the kernel's driver and the RTCAdjust module, both of which are further abstracted by OS_Word 14 and 15.

Where the HAL device indicates that the RTC hardware doesn't store years (or centuries) these will be saved in the conventional 'YearCMOS' CMOS locations.

If the HAL does not offer any RTC peripherals a fallback software clock will be run, resetting to 01-Jan-1970 (the Unix epoch) on every power cycle.

Affected components
-------------------
NetTime current kills the RTCAdjust module and attempts to adjust the clock itself when network time updates are available. this module will need updating to preferentially use the RTC_Adjust SWI instead (falling back to its old behaviour when used on earlier systems).

The RTCAdjust module will be removed from ROM builds.

The kernel will be updated to exclusively call the RTC module, and no longer probe for one at power up. Probing for CMOS will still be performed, so in the case of a combined clock and CMOS (eg. on IOMD) the kernel may also require access to the IIC peripheral at times.

The Tungsten HAL will be updated to add a HALDeviceSysPeri_RTC device.

The IOMD HAL will be updated to add a HALDeviceSysPeri_RTC device.

The HALDeviceSysPeri_RTC will use RISCOS_IICOpV and drop the 'iicop' function pointer, as well as permitting the IIC device to be on a bus other than bus 0.
