嵌入式系统的系统时钟与硬件时钟(RTC)

Question

系统时钟由内核维护，硬件时钟由实时时钟(RTC)维护。

1. 这两个时钟的频率相同吗？
2. 都是相互独立的吗？
3. 当实时时钟出现故障时会发生什么？它会影响系统时钟吗？

有人能让我知道这两个钟的区别吗。

Answer 1

两个时钟以相同的频率运行？

不一定，但一般不是。硬件时钟(可能有很多，特别是在numa和嵌入式系统上)都是振荡器，频率取决于晶型，并提供专用的分频器。这些是时钟源。

系统时钟不是一个真正的时钟源，但它将取决于一个给定的硬件时钟，可以是一些RTC。

如果有多个RTC，系统将知道的RTC可以根据udev规则进行选择。

两者都是相互独立的？

一般不是，而是…可能吧。内核被提供了不同的硬件时钟源，最常见的是：

时间戳计数器(TSC)、高精度事件计时器(HPET)、ACPI电源管理定时器(ACPI_PM)、可编程间隔定时器(PIT)和实时时钟(RTC)。

您可以列出那些在您的系统cat-ing /sys/devices/system/clocksource/clocksource0/available_clocksource上可用的，您可以选择/sys/devices/system/clocksource/clocksource0/current_clocksource的首选系统时钟源回波。

因此，您实际上可以强制您的系统时钟依赖于RTC。

这通常是不可取的，因为RTC的读取成本很高，而且与基于cpu频率的时钟源相比，通常分辨率更低。

因此，对于实时内核的使用，它是次优的.

linux内核首选的时钟源是TSC.(启动进程时，系统将依赖它)我的引导日志告诉：

时钟源:切换到时钟源tsc-早期

但是，在无痒系统上，这个源肯定是不稳定的，不能可靠地使用。在这种情况下，当可用时，内核将切换到HPET，这是首选的第二个。

tsc:标记TSC不稳定，因为TSC在空闲时钟源中停止:切换到时钟源

当实时时钟发生故障时，它会影响系统时钟吗

在运行时，只要RTC不是首选的时钟源，就不会发生任何错误(从内核的角度来看)。

当然，由于看门狗通常是建立在RTCs的基础上的，它们的有效性就变成了…。不可预测，这确实是嵌入式系统的一个问题。

在重新启动时，您的系统可能会从一些不可预测的日期和时间开始，这可能会引起misc日志管理和cron决策的关注。

Answer 2

RTC通常是为了在重新启动时保持时间，这就是为什么它有自己的电池。这让系统对早期启动时的时间有了准确的了解，在NTP能够与“internet”同步之前。如果RTC失败，那么早期的启动时间戳将是无稽之谈，通常是1970年1月1日UTC，即Unix时代的开始；初始值为0。

有一点要注意:在RTC中，类似unix的商店UTC。Windows (是的，有嵌入式版本的Windows)在RTC中存储本地时间。来回切换可能会导致混乱，而双引导则是一团糟，除非类unix有特殊的处理( Linux在引导期间执行IIRC；某些内核参数)。