关于主板RTC没有电场景下BMC时间同步问题

bmc_core SIG
1

我们在验证RTC没有电场景下BMC时间同步问题，发现，通过 ipmitool sel set time 设置的时间不能继续计时，而是直接更新成 2000-01-01，bmc_core 日志显示更新 RTC 时间成功，原则上来说应该更新失败才对。

日志：

image
image1516×281 19.9 KB

RTC时间更新是通过CPLD实现的，这里要分析下，是否合理。

2

答案内容由AI生成，仅供参考：

总结

  1. 根本原因：RTC芯片无电，无法保持写入的时间。
  2. 现象成因：BMC的周期性时间同步机制（每6秒从RTC同步一次）覆盖了您通过ipmitool设置的时间。
  3. 流程合理性：
    • 通信层面：CPLD和BMC之间的通信流程是成功的，因此日志显示“更新成功”是合理的。
    • 架构层面：通过CPLD实现是合理的硬件抽象设计。
    • 缺陷点：当前软件流程缺乏对RTC芯片写入结果的校验和硬件失效场景的处理，这是不合理之处。

建议：在设计上，可以考虑在RTC写入成功后增加一个逻辑：读取验证写入值。若读取结果与写入值不符（如发现为默认的2000-01-01），则判定RTC异常，并阻止后续的RTC同步覆盖BMC时间，同时在日志中记录明确的RTC芯片电源异常告警。

点击此处查看详细分析解答

好的，我们来分析一下您遇到的RTC没电场景下BMC时间同步问题。

根据您提供的Context信息，我将从核心机制、问题根因和流程评估三个层面进行解析。

核心机制分析：BMC与RTC的时间同步

首先，需要理解BMC与RTC（实时时钟）之间的时间同步机制：

  1. RTC的角色：RTC是一个硬件组件，负责在系统断电时维持准确的系统时间。它在系统中的角色是时间基准源。BMC Time（BMC内部维护的时间）会定期与RTC Time同步。
  2. 同步过程：
    • 当使用 ipmitool sel time set 命令设置时间时，它修改的是BMC Time。根据zhangbaocun的描述，BMC时间每隔6秒又会从RTC同步时间，所以设置了又会被修改。
    • 这意味着，即使通过ipmitool命令成功设置了BMC时间，在下一个同步周期（每6秒），BMC会尝试用RTC Time来覆盖（同步）自己维护的BMC时间。
  3. RTC无电的状态：当RTC没有电源供应（例如主板电池没电）时，RTC芯片无法维持正确计时。它通常会恢复到一个默认的硬件初始时间（例如，很多系统的epoch时间或一个特定值，如2000-01-01）。

问题现象解释

您描述的“通过ipmitool sel time set设置的时间不能继续计时，而是直接更新成2000-01-01”现象，完全符合上述机制：

  1. 您的操作：使用ipmitool sel time set将BMC时间设置为一个有效时间（例如，当前时间）。
  2. BMC内部动作：BMC收到了命令，将BMC Time设置为您指定的值。同时，它也尝试将这个时间写入RTC芯片。这解释了日志中显示的“更新RTC时间成功”。
  3. RTC无电的后果：尽管BMC日志显示“更新成功”，但由于RTC芯片没有电，它无法持久化存储这个新时间。当这个写入操作完成后，RTC芯片立刻（或非常短的时间内）因电源缺失而复位到其默认的硬件初始时间（这里是2000-01-01）。
  4. 周期性同步：在接下来的6秒同步周期中，BMC发现RTC的时间是2000-01-01，于是根据同步机制，BMC Time会被RTC Time覆盖，即重置为2000-01-01。

结论：您看到的现象是BMC时间被周期性同步机制从已失效的RTC中拉取时间而覆盖的结果。

流程合理性评估

您提出的“原则上来说应该更新失败才对”和“通过CPLD实现是否合理”这两个问题，可以直接从Context中找到评估依据：

  1. 关于“应该更新失败”的评估：

    • 不完全是“失败”：BMC组件认为它成功地将时间数据发送给了CPLD/RTC硬件链路。从软件组件的角度看，发送指令没有返回错误，所以它记录为成功。
    • 合理的架构：在正常的、有电的场景下，这套流程（ipmitool → BMC Time → RTC → 周期性同步）是正确且高效的。问题出现不在流程本身，而是在异常场景（RTC无电）下的容错处理。BMC的imekeeping组件没有检测RTC芯片是否真正持久化了写入的时间。
    • 关键点：软件组件不具备检测RTC芯片是否成功存储数据的能力，它只能检测到I2C通信是否完成。RTC的无电状态属于硬件故障层面的问题，软件层的“更新成功”日志是正常的通信确认，不代表数据物理持久化。

  2. 关于“通过CPLD实现”的评估：

    • 合理性：通过CPLD（复杂可编程逻辑器件）来实现对RTC芯片的控制（如SetRtcTime方法）是一种常见的硬件抽象设计。CPLD可以作为RTC芯片的访问代理，处理底层的时序和I2C协议。
    • 问题所在：问题不在于“是否通过CPLD实现”不合理，而在于现有的软件流程没有考虑RTC芯片硬件失效（如失去后备电源）的情况。合理的增强做法是：在SetRtcTime或后续的同步环节中，增加一个读回校验步骤。即写入后，立即或在一个短间隔内，从RTC芯片读取时间，与写入值进行比较。如果发现读回的值并非写入的值（例如，读回了2000-01-01），则可以判定RTC芯片状态异常，并进行相应的告警或处理（比如阻止后续的同步覆盖）。

总结

  1. 根本原因：RTC芯片无电，无法保持写入的时间。
  2. 现象成因：BMC的周期性时间同步机制（每6秒从RTC同步一次）覆盖了您通过ipmitool设置的时间。
  3. 流程合理性：
    • 通信层面：CPLD和BMC之间的通信流程是成功的，因此日志显示“更新成功”是合理的。
    • 架构层面：通过CPLD实现是合理的硬件抽象设计。
    • 缺陷点：当前软件流程缺乏对RTC芯片写入结果的校验和硬件失效场景的处理，这是不合理之处。

建议：在设计上，可以考虑在RTC写入成功后增加一个逻辑：读取验证写入值。若读取结果与写入值不符（如发现为默认的2000-01-01），则判定RTC异常，并阻止后续的RTC同步覆盖BMC时间，同时在日志中记录明确的RTC芯片电源异常告警。