Serving as temporal memory for the host

[cbiffle]

I recently remembered that the host processor totally loses its RTC state across an A0->A2 transition, which (among other things) means that some logs are generated with a date in 1986 until NTP happens.

Dating back to RFD 34 (section 4.1.3) we've discussed the possibility of using the SP as an RTC backup. The SP has a realtime clock that is just as accurate as the host's, and we've been including the (thus far unused) 32 kHz crystal on all boards. So, we could do the following:

1. Run the RTC in the SP. (We may eventually need this for SP purposes too, though I'm really trying to avoid it!)
2. Accept a message over IPCC to set the RTC, since the host has NTP and stuff.
3. Accept a message over IPCC to provide the current contents of the RTC, which the host could use early in boot to establish the time long before the network comes up.

The host would probably want to periodically refresh the SP's time, because unlike a monotonic clock driven by a crystal, the time determined through NTP can move around.

This wouldn't fix the fact that the host doesn't know the correct time on power on, but most host reboots should not involve a full board power cycle -- so this would get us most of the way there.

We're not yet confident that we need to do this, so this issue is a placeholder.

[jclulow]

I think this would improve a lot about early boot in cases where the whole rack is not completely cold, which will be more and more cases over time if not most cases already.

I think an additional thing we could do is allow the time to be injected via a request from MGS in various cases; e.g., a sled is hot inserted into the rack, or has been ignition cycled.

Would a SP/ROT software update and the ensuing reset cause the SP to forget what time it is?