☰

組み込みシステムのシステムクロックとハードウェアクロック(RTC)

tag-icon • tag-icon linux hardware embedded clock cpu-frequency
組み込みシステムのシステムクロックとハードウェアクロック(RTC)

システムクロックはカーネルによって維持され、ハードウェアクロックはリアルタイムクロック（RTC）によって維持されます。

  1. 両方の時計は同じ周波数で動作しますか？
  2. 2つは互いに独立していますか？
  3. リアルタイムクロックが失敗した場合はどうなりますか？システムの時計に影響しますか？

誰もがこれら2つの時計の違いを教えてもらえますか？

答え1

  1. 両方の時計が同じ周波数で動作しますか？

    通常、コンピュータ/デバイス/システムの内部には2つの時計があります。そのうちの1つはバッテリー（通常はメインバッテリーまたは組み込みシステムのスーパーキャパシターである可能性があるCR2032）で駆動され、専用チップで動作します。もう1つは、CPUクロックソース（自己石英水晶を含む）によって駆動されます。

    通常は32.768kHz水晶で動作します。もう1つはCPU水晶MhzまたはGHzの範囲から来ます。 CPUモデルが多いので違いも多いです。

  2. 2つは互いに独立していますか？

    はい、ほとんどそうです。ただし、1つは別のものを調整できます（組み込みLinuxでは通常、またはhwclockオプションでコマンドを使用します）。 CPUクロックは起動時にチップクロックによって設定されます（CPUは起動時の現在時刻が不明です）。ネットワーク上のシステムでは、CPUクロックはNTP（Network Time Protocol）を介してネットワーク上のより良い時間値を見つけて、クロックチップ内の値を調整または変更できます。-r-w

  3. リアルタイムクロックエラーがシステムクロックに影響を与えるとどうなりますか？

    はい、もちろんです。たとえば、バッテリが放電されると、コンピュータは完全に時代遅れのリアルタイム概念で起動しますが、今日のほとんどのシステムはネットワークに接続されており、NTPプロトコルを介して起動してすぐにリアルタイムの概念を更新します。 。

  4. 誰もがこれら2つの時計の違いを教えてもらえますか？

    前述のように、1つのクロックソースはチップで、もう1つはCPUです。

CPUにはRTCとも呼ばれる内部値があるため、チップクロックをRTCクロックと呼ぶことは避けてください。しかし、そうです。それは一般的な名前です。

関連:

答え2

両方の時計が同じ周波数で動作しますか？

必ずしもそうではありませんが、一般的にそうではありません。 ハードウェア時計（特にNumaおよび組み込みシステムには多くあります）は、特定の周波数で走る発振器です。決定そして特別なパーティションを提供してください。これらはすべてクロックソース。

これシステム時計実際のクロックソースではありませんが、特定のハードウェアクロックによって異なります。できるいくつかのRTCです。
RTC が複数ある場合、システムが RTC と呼ぶ RTC を udev の規則に従って選択できます。

2つは互いに独立していますか？

普通はそうではありませんが…おそらく。 カーネルはさまざまなハードウェアクロックソースを提供し、最も一般的なソースはタイム
スタンプカウンタ（TSC）、高精度イベントタイマ（HPET）、ACPI電源管理タイマ（ACPI_PM）、プログラム可能なインターバルタイマ（PIT）、およびリアルタイムタイミングデバイスクロックです。あります。 (RTC).

システムクロックに使用可能なクロックソースを一覧表示でき、/sys/devices/system/clocksource/clocksource0/available_clocksourceエコーするデフォルトのシステムクロックソースを選択できます。/sys/devices/system/clocksource/clocksource0/current_clocksource

だからあなたはできるシステムクロックがRTCに依存するように効果的に強制します。

これは一般的に言えばRTCは読み取りに費用がかかり、通常はCPU周波数に基づくクロックソースよりも解像度が低いため推奨されません。
したがって、リアルタイムカーネルでの使用には適していません。

Linux カーネルに好ましいクロックソースは TSC です。。 （起動プロセスを開始すると、システムはそれに依存します。）私の起動ログには、次の内容が表示されます。

クロックソース：クロックソースtsc-earlyに切り替える

ただし、チックレスシステムでは、このソースは確実に不安定で安定して使用できません。この場合、カーネルは2番目に好ましいオプションであるHPETに切り替えられます（利用可能な場合）。

tsc：アイドル状態のTSC停止によりTSCを不安定としてマークします。

クロックソース：クロックソースに切り替えるhpet

リアルタイムクロックにエラーが発生すると、システムクロックに影響を与えます。

実行時には、RTCがデフォルトのクロックソースでない限り、カーネルの観点からエラーは発生しません。
もちろん、監視装置はRTCに基づいていることが多いため、その効率は予測できなくなり、これは組み込みシステムで実際の問題になる可能性があります。
再起動すると、システムが予測できない日時から始まる可能性があります。できるその他のログ管理やcronの決定に問題がある可能性があります。

答え3

RTCは通常、再起動後の時間を維持するために使用されるため、独自のバッテリがあります。これにより、NTP が「インターネット」と時刻を同期させる前の初期起動中の時刻に関する正確な情報がシステムに提供されます。 RTCが失敗した場合、以前の開始タイムスタンプは通常1970年1月1日UTCであり、初期値は0です。

1つの注意点：UnixシリーズシステムはUTCをRTCに保存します。 Windows（Windowsの組み込みバージョンなど）はRTCに現地時間を保存します。前後に切り替えると混乱を招く可能性があり、UNIXなどの特別な処理機能がないと、デュアルブートが混乱する可能性があります（LinuxはIIRCを実行し、起動中のカーネルパラメータの一部）。

関連情報