ARMv7 Generic Timers: Difference between revisions

From OSDev.wiki
Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content added Content deleted
No edit summary
No edit summary
Line 3: Line 3:
= Overview =
= Overview =


The ARM Generic Timers (henceforth, "GT") are architecturally specified in ARMv7 as an <tt>OPTIONAL</tt> extension to the ARMv7-a and ARMv7-r streams. The feature is specified to provide a timestamp-counter (upcounter) reference which operates independent of the CPU clock's frequency, allowing for TSC measurements which are invariant over time, regardless of processor scaling, power state and throttling.
The ARM Generic Timers (henceforth, "GT") are architecturally specified in ARMv7 as an <tt>OPTIONAL</tt> extension to the ARMv7-a and ARMv7-r streams. The feature is specified to provide a system-wide timestamp-counter (henceforth, "syscounter") reference which operates independent of the CPU clock's frequency, allowing for TSC measurements which are invariant over time, regardless of processor scaling, power state and throttling.


This upcounter can be read in two forms:
This upcounter can be read in two forms, and these readout-forms are logically distinct from the actual value of the syscounter (though the physcounter will usually reflect the syscounter exactly):
* Physical upcounter readout ("Physical counter").
* Physical upcounter readout ("physcounter"). This is read as a 64-bit read using the CNTPCT register.
* Virtual upcounter readout ("Virtual counter"). This is the value of the physical timer, minus a 64-bit virtual offset.
* Virtual upcounter readout ("virtcounter"). This is the value of the physical timer, minus a 64-bit virtual offset. This is read using the CNTVCT register.


The feature also specifies a set of 4 timers per CPU which base their operation on these two upcounters:
The feature also specifies a set of 4 timers per CPU which base their operation on these two upcounters:
* Secure Thysical timer.
* Secure phystimer: based on
* Non-secure Physical timer.
* Non-secure phystimer: based on
* Hypervisor timer.
* Hypervisor timer: based on
* Virtual timer.
* Virtual timer: based on


= System counters =
= System counters =


The GT's physical upcounter is specified to present the following behaviour to software:
The GT's syscounter is specified to present the following behaviour to software:
* At least 56 bits wide. Any read from the upcounter is ''zero-extended'' to 64 bits.
* At least 56 bits wide. Any read from the syscounter, physcounter or virtcounter is ''zero-extended'' to 64 bits.
* The upcounter increments at a fixed frequency, with architecturally supported ranges being from 1-50 MHz.
* The syscounter increments at a fixed frequency, with architecturally supported ranges being from 1-50 MHz.
* Supports clock multiplication to save power. I.e, the hardware crystal may operate at a lower frequency than the frequency claimed by the platform, and a multiplier may applied to the readout value to present the illusion of operation at a higher frequency. The underlying crystal's frequency may change dynamically at runtime.
* Supports clock multiplication to save power. I.e, the hardware crystal may operate at a lower frequency than the frequency claimed by the platform, and a multiplier may applied to the readout value to present the illusion of operation at a higher frequency. The underlying crystal's frequency may change dynamically at runtime.
* Roll-over time is guaranteed to be at least 40 years.
* Roll-over time is guaranteed to be at least 40 years.
* Clock drift is not required to be at any level of accuracy, but ARM <tt>RECOMMENDS</tt> that drift be not greater than 10 seconds per 24 hours. The use of clock multiplication must not change the drift behaviour of the upcounter.
* Clock drift is not required to be at any level of accuracy, but ARM <tt>RECOMMENDS</tt> that drift be not greater than 10 seconds per 24 hours. The use of clock multiplication must not change the drift behaviour of the sysupcounter.
* The upcounter is architecturally specified to begin counting from 0 at #RESET.
* The syscounter is architecturally specified to begin counting from 0 at #RESET.
* The upcounter must be implemented in the always-on power domain.
* The syscounter must be implemented in the always-on power domain.


All agents (including devices in the system other than the host processors) reading the system upcounter must be presented with a uniform view of passing time.
All agents (including devices in the system other than the host processors) reading the syscounter must be presented with a uniform view of the passage of time.


== Registers ==
The <tt>CNTFREQ</tt> register is only ''writeable'' by ''secure'' PL1 mode software, and must be initialized to state the frequency of the system upcounter.

The control registers for the system counter are not accessible as coprocessor interface registers, and are only accessible through a memory mapped interface. The controls include enabling/disabling the syscounter, setting the syscounter's value, changing the syscounter's frequency and multiplier, and enabling/disabling halt-on-debug, so that a debugger can halt the syscounter when a processor enters halting debug-mode.

The physical and virtual upcounters as well as the timer registers are architecturally configurable.

=== CNTKCTL ===
Enables PL1 software to control access to the counters and timers from PL0 modes.
* Bits PL0PCTEN and PL0VCTEN enable/disable access to <tt>CNTVCT</tt>, <tt>CNTPCT</tt> and <tt>CNTFREQ</tt> from PL0 modes.
* Bit PL0PTEN enables/disables access to <tt>CNTP_CTL</tt>, <tt>CNTP_CVAL</tt> and <tt>CNTP_TVAL</tt> from PL0 modes.
* Bit PL0VTEN enables/disables access to <tt>CNTV_CTL</tt>, <tt>CNTV_CVAL</tt> and <tt>CNTV_TVAL</tt> from PL0 modes.
* Bits EVENTEN, EVENTDIR and EVENTI enable and control the direction and bit-position of the bit that triggers the events generated by the virtual counter (CNTVCT).

=== CNTHCTL ===
Enables PL2 software to control access to the counters and timers from non-secure PL1 and PL0 modes.
* Bit PL1PCTEN enables/disables access to CNTPCT from non-secure PL1 and PL0 modes.
* PL1PCEN enables/disables access to the phyisical timer registers (CNTP_CTL, CNTP_TVAL, CNTP_CVAL) from non-secure PL1 and PL0 mode.

=== CNTFREQ ===
The <tt>CNTFREQ</tt> register is only ''writeable'' by ''secure'' PL1 mode software, and must be initialized to state the frequency of the system upcounter, '''in Hz'''.
<tt>CNTFREQ</tt> is ''readable'' by PL2, secure and non-secure PL1 by default. <tt>CNTKCTL.PL0PCTEN</tt> enables <tt>CNTFREQ</tt> to be read from secure and non-secure PL0.
<tt>CNTFREQ</tt> is ''readable'' by PL2, secure and non-secure PL1 by default. <tt>CNTKCTL.PL0PCTEN</tt> enables <tt>CNTFREQ</tt> to be read from secure and non-secure PL0.

=== CNTPCT ===

* Is always accessible from PL2.
* Is always accessible from PL1 modes. However, if hypervisor extensions are supported accesses to CNTPCT will generate a hyp-trap from PL1 unless CNTHCTL.PL1PCTEN is set to 1.
* Is only accessible from PL0 modes if CNTKCTL.PL0CTEN is set to 1. If CNTKCTL.PL0CTEN


= Timers =
= Timers =
Line 38: Line 63:
*
*


= Registers =
== Registers ==

== CNTFREQ ==

Revision as of 03:50, 7 September 2017

This page is current with the description of the ARM Generic Timer behaviour specified in the ARMv7 manual. There may have been differences introduced in ARMv8 and AArch64. This page does not take such differences, if they exist, into account.

Overview

The ARM Generic Timers (henceforth, "GT") are architecturally specified in ARMv7 as an OPTIONAL extension to the ARMv7-a and ARMv7-r streams. The feature is specified to provide a system-wide timestamp-counter (henceforth, "syscounter") reference which operates independent of the CPU clock's frequency, allowing for TSC measurements which are invariant over time, regardless of processor scaling, power state and throttling.

This upcounter can be read in two forms, and these readout-forms are logically distinct from the actual value of the syscounter (though the physcounter will usually reflect the syscounter exactly):

  • Physical upcounter readout ("physcounter"). This is read as a 64-bit read using the CNTPCT register.
  • Virtual upcounter readout ("virtcounter"). This is the value of the physical timer, minus a 64-bit virtual offset. This is read using the CNTVCT register.

The feature also specifies a set of 4 timers per CPU which base their operation on these two upcounters:

  • Secure phystimer: based on
  • Non-secure phystimer: based on
  • Hypervisor timer: based on
  • Virtual timer: based on

System counters

The GT's syscounter is specified to present the following behaviour to software:

  • At least 56 bits wide. Any read from the syscounter, physcounter or virtcounter is zero-extended to 64 bits.
  • The syscounter increments at a fixed frequency, with architecturally supported ranges being from 1-50 MHz.
  • Supports clock multiplication to save power. I.e, the hardware crystal may operate at a lower frequency than the frequency claimed by the platform, and a multiplier may applied to the readout value to present the illusion of operation at a higher frequency. The underlying crystal's frequency may change dynamically at runtime.
  • Roll-over time is guaranteed to be at least 40 years.
  • Clock drift is not required to be at any level of accuracy, but ARM RECOMMENDS that drift be not greater than 10 seconds per 24 hours. The use of clock multiplication must not change the drift behaviour of the sysupcounter.
  • The syscounter is architecturally specified to begin counting from 0 at #RESET.
  • The syscounter must be implemented in the always-on power domain.

All agents (including devices in the system other than the host processors) reading the syscounter must be presented with a uniform view of the passage of time.

Registers

The control registers for the system counter are not accessible as coprocessor interface registers, and are only accessible through a memory mapped interface. The controls include enabling/disabling the syscounter, setting the syscounter's value, changing the syscounter's frequency and multiplier, and enabling/disabling halt-on-debug, so that a debugger can halt the syscounter when a processor enters halting debug-mode.

The physical and virtual upcounters as well as the timer registers are architecturally configurable.

CNTKCTL

Enables PL1 software to control access to the counters and timers from PL0 modes.

  • Bits PL0PCTEN and PL0VCTEN enable/disable access to CNTVCT, CNTPCT and CNTFREQ from PL0 modes.
  • Bit PL0PTEN enables/disables access to CNTP_CTL, CNTP_CVAL and CNTP_TVAL from PL0 modes.
  • Bit PL0VTEN enables/disables access to CNTV_CTL, CNTV_CVAL and CNTV_TVAL from PL0 modes.
  • Bits EVENTEN, EVENTDIR and EVENTI enable and control the direction and bit-position of the bit that triggers the events generated by the virtual counter (CNTVCT).

CNTHCTL

Enables PL2 software to control access to the counters and timers from non-secure PL1 and PL0 modes.

  • Bit PL1PCTEN enables/disables access to CNTPCT from non-secure PL1 and PL0 modes.
  • PL1PCEN enables/disables access to the phyisical timer registers (CNTP_CTL, CNTP_TVAL, CNTP_CVAL) from non-secure PL1 and PL0 mode.

CNTFREQ

The CNTFREQ register is only writeable by secure PL1 mode software, and must be initialized to state the frequency of the system upcounter, in Hz. CNTFREQ is readable by PL2, secure and non-secure PL1 by default. CNTKCTL.PL0PCTEN enables CNTFREQ to be read from secure and non-secure PL0.

CNTPCT

  • Is always accessible from PL2.
  • Is always accessible from PL1 modes. However, if hypervisor extensions are supported accesses to CNTPCT will generate a hyp-trap from PL1 unless CNTHCTL.PL1PCTEN is set to 1.
  • Is only accessible from PL0 modes if CNTKCTL.PL0CTEN is set to 1. If CNTKCTL.PL0CTEN

Timers

  • The timers can be used as either count-up or count-down timers.
  • The timers can operate in either physical or virtual time.
  • The timers output signals can be configured as level-sensitive PPI IRQ signals to the GICC.

Registers

CNTFREQ