From: pbonzini@redhat.com (Paolo Bonzini)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v2] ARM VM System Specification
Date: Tue, 10 Jun 2014 20:56:37 +0200 [thread overview]
Message-ID: <539754E5.3030408@redhat.com> (raw)
In-Reply-To: <CAFEAcA8RttCvbOAw-m-W6C-mh1o4hj6nqGMkDbRsSF6ZoQZ7Kg@mail.gmail.com>
Il 10/06/2014 20:08, Peter Maydell ha scritto:
> On 10 June 2014 18:04, Christopher Covington <cov@codeaurora.org> wrote:
>> On 06/10/2014 10:42 AM, Peter Maydell wrote:
>>> I just noticed that this doesn't mandate that the platform
>>> provides an RTC. As I understand it, the UEFI spec mandates
>>> that there's an RTC (could somebody more familiar with UEFI
>>> than me confirm/deny that?) so we should probably put one here.
>>
>> Pardon my ignorance, but what exactly disqualifies Generic Timer
>> implementations from being used as Real Time Clocks?
>
> So my naive view was that an RTC actually had to have
> support for dealing with real (wall) clock time, ie
> knowing it's 2014 and not 1970. The generic timers are
> just timers. Or am I wrong and UEFI doesn't really
> require that?
The real-time clock provides four UEFI runtime services (GetTime,
SetTime, GetWakeupTime, SetWakeupTime). The spec says that you can
return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be
retrieved/set due to a hardware error", but I don't think this is enough
to make these two optional. By comparison, GetWakeupTime/SetWakeupTime
can also return EFI_UNSUPPORTED.
So I agree that the RTC is required in UEFI.
Paolo
next prev parent reply other threads:[~2014-06-10 18:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 18:45 [RFC v2] ARM VM System Specification Christoffer Dall
2014-03-30 22:10 ` Olof Johansson
2014-03-31 17:26 ` Christoffer Dall
2014-04-01 9:49 ` Ian Campbell
2014-04-01 9:57 ` Michael Casadevall
2014-04-01 10:16 ` Grant Likely
2014-04-29 14:42 ` Christoffer Dall
2014-04-30 8:14 ` Grant Likely
2014-06-10 14:42 ` Peter Maydell
2014-06-10 15:03 ` Ian Campbell
2014-06-10 17:00 ` Paolo Bonzini
2014-06-10 17:04 ` Christopher Covington
2014-06-10 18:08 ` Peter Maydell
2014-06-10 18:56 ` Paolo Bonzini [this message]
2014-06-10 19:18 ` Paolo Bonzini
2014-06-10 19:18 ` Paolo Bonzini
2014-06-11 6:54 ` Christoffer Dall
2014-06-11 8:16 ` Paolo Bonzini
2014-06-11 9:06 ` Arnd Bergmann
2014-06-30 16:19 ` Jon Masters
2014-06-30 20:46 ` Christoffer Dall
2014-06-30 21:14 ` Peter Maydell
2014-07-01 17:03 ` Stefano Stabellini
2014-07-01 17:10 ` Peter Maydell
2014-07-02 10:13 ` Christoffer Dall
2014-06-11 11:33 ` Grant Likely
2014-06-11 11:58 ` Arnd Bergmann
2014-06-11 12:02 ` Grant Likely
2014-06-11 14:14 ` Peter Maydell
2014-06-10 16:44 ` Claudio Fontana
2014-06-10 19:21 ` Arnd Bergmann
2014-06-11 9:50 ` Stefano Stabellini
2014-06-11 9:55 ` Christoffer Dall
2014-06-11 11:28 ` Grant Likely
2014-06-11 12:04 ` Christoffer Dall
2014-06-11 10:27 ` Arnd Bergmann
2014-06-11 11:22 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=539754E5.3030408@redhat.com \
--to=pbonzini@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).