RTC about u-bmc HOT 9 CLOSED

Thinking about this some more. Maybe this is just all done by the PCH?

I see that facebook/openbmc does sync from the ME, which I don't really like. Ideally there would be some source we can query when everything is shut off.

from u-bmc.

@shenki How does OpenBMC handle RTC clock? I tried looking at the code and see some past discussions but it didn't jump at me how it's done.

from u-bmc.

In terms of providing it to the host? I don't know much about openbmc's handling of this.

On OpenPower host firmware queries the current time from the BMC at host boot time. This happens over IPMI BT. The source of this is the current time according to Linux.

Linux on the BMC grabs the current time/date from the RTC over i2c at BMC boot. All of the systems I've seen have a i2c attached RTC that has battery backup. ASPEED does have a RTC in SoC, but it loses state when the BMC loses power, so it's not very useful.

from u-bmc.

Thanks! I was curious about how the BMC gets its time - but you answered that.

I'll dig through some board schematics for other boards and see if I can figure it out.

Fwiw, on Yosemite I recall the RTC battery to be on each of the 4 host blades and I don't think the aspeed part had any.

from u-bmc.

This is what the Tioga Pass requires:

8.17 BMC Time Sync

During BMC initialization:

• If it’s the 1st time being powered on via an AC source (G3 exit), the BMC should receive
  its initial RTC time from PCH RTC. Otherwise, the BMC should keep its own RTC.

During BMC running time:

• If the system is in S0 and the BIOS POST has completed, the BMC should sync with
  PCH RTC every hour
• If the system is in S5, the BMC should retrieve the NTP UTC following the OEM
  command setting of NTP periodical sync interval (default =2x per hour)
• Log NTP status time sync failed event if a mismatch of > ±5 seconds is found, or if BMC
  cannot obtain NTP time after 3x retries. Retry interval is set to 30 seconds by default.

I have to research what the PCH can do when exiting G3 but my understanding is that it is very limited. I'm considering being very NTP centric instead, given that you need network connectivity to query the API anyway, having NTP should be fine. Reading the RTC from the PCH as a fallback, and potentially even power up the machine to do so should also work, but that's heading down a path of surprising behavior.

from u-bmc.

Pending discussion in u-root/u-root#961

from u-bmc.

I've requested a vendor pool for x.u-root.pool.ntp.org as is required to ship with NTP pool defaults in apps.

from u-bmc.

RTC is read up on boot but not set by us, will file an issue for that.

from u-bmc.

Pending u-root/u-root#982

from u-bmc.