diff options
author | Laszlo Ersek <lersek@redhat.com> | 2015-02-02 12:01:58 +0000 |
---|---|---|
committer | lersek <lersek@Edk2> | 2015-02-02 12:01:58 +0000 |
commit | ab879e4cb3f5a168d9902e307e44de01300ac9a7 (patch) | |
tree | b322a6c9a74e862558104e000cabfd46d90902b8 /CryptoPkg/Application/Cryptest | |
parent | 16b7aff06b4379eaac48dc6e78c7a3944c0bdbad (diff) | |
download | edk2-platforms-ab879e4cb3f5a168d9902e307e44de01300ac9a7.tar.xz |
ArmVirtualizationQemu: ask the hardware for the timer frequency
Roughly, there are two ways to "measure ticks" in UEFI:
- the SetTimer() boot service, which sets up a one-shot or periodic event
callback, and takes the interval length in units of 100ns,
- the Stall() boot service, which stalls the caller (but does not yield
the CPU) for the interval specified. The interval is taken as a number
of microseconds.
If the platform in question also follows the PI (Platform Init)
specification, then it is recommended to implement the above UEFI services
on top of the following DXE Architectural Protocols (described in PI
Volume 2):
- Timer Architectural Protocol:
"Used to set up a periodic timer interrupt using a platform specific
timer, and a processor-specific interrupt vector. This protocol enables
the use of the SetTimer() Boot Service. [...]"
- Metronome Architectural Protocol:
"Used to wait for ticks from a known time source in a platform. This
protocol may be used to implement a simple version of the Stall() Boot
Service. [...]"
Edk2 in general, and ArmVirtualizationQemu in particular, follow the above
pattern.
SetTimer() works correctly. The underlying Timer Architectural Protocol is
provided by "ArmPkg/Drivers/TimerDxe", and that driver calls the internal
function ArmGenericTimerGetTimerFreq() to retrieve the timer frequency.
Ultimately it boils down to reading the CNTFRQ_EL0 register.
The correct behavior of SetTimer() can be observed for example:
- in the grub-efi countdown ("grub-core/kern/arm/efi/init.c"),
- in the Intel BDS front page countdown
("IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c").
However, Stall() doesn't work correctly. The underlying Metronome
Architectural Protocol is provided by "EmbeddedPkg/MetronomeDxe", which
further delegates the job to the TimerLib library class. That in turn is
resolved to the "ArmPkg/Library/ArmArchTimerLib" instance, which
(finally!) takes the timer frequency from "PcdArmArchTimerFreqInHz".
In ArmVirtualizationQemu we currently specify 100MHz for this PCD. Alas,
that's incorect for:
- both QEMU/TCG (which emulates 62.5MHz, see GTIMER_SCALE in
"target-arm/internals.h"),
- and KVM (where the host's virtualized timer can tick at 50 MHz, for
example).
Set the PCD to 0, asking ArmArchTimerLib to interrogate CNTFRQ_EL0 as
well.
The change can be tested with eg. the following callers of Stall():
- the UEFI Shell's countdown -- before it runs "startup.nsh" -- relies on
Stall(),
- the UEFI shell command "stall" also uses Stall(). (Time it with a
stopwatch.)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16692 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'CryptoPkg/Application/Cryptest')
0 files changed, 0 insertions, 0 deletions