| Age | Commit message (Collapse) | Author |
|---|
|
http://netbsd.gw.com/cgi-bin/man-cgi?date++NetBSD-current
The NetBSD manual tells us the date in NetBSD doesn't take any flags
to enable or disable padding in the format.
By default, date pads numeric fields with zeroes. This will convert the
number to octal one. So add "0x" to convert it to BCD directly.
Change-Id: Icd44312acf01b8232f1da1fbaa70630d09007b40
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1804
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
The range of weekday in CMOS is 01-07, while the Sunday is 1, and
Saturday is 7. The comand date in coreutils defines
%u day of week (1..7); 1 is Monday
%w day of week (0..6); 0 is Sunday
There are 1 day offset for each week day. So we use "%w" and plus 1
before we update the weekday in CMOS.
Change-Id: I3fab4e95f04924ff0ba10a7012b57da1d3f0d1a5
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1802
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
The linux kernel relies on the RTC reporting pending interrupts if
the RTC alarm was used to wake the system. If we clear these flags
here then the rtc-cmos driver in the kernel will think that no
interrupts are pending and will not re-start the timerqueue to
handle the alarm timerqueue node.
This flag doesn't exist in SMM but the rtc code is compiled there.
Since rtc_init() is not called by SMM it is guarded with an ifdef.
I performed several thousand suspend/resume cycles without seeing
an issue where hwclock was unable to read from /dev/rtc. There
still is a potential kernel issue where the timerqueue can stall
but this makes that much less likely to happen on resume.
Change-Id: I5a343da4ce5c4c8ec4783b4e503869ccfa5077f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Check the RTC on boot after RTC battery failure and ensure
that the reported build date matches what is reported:
> grep ^rtc /proc/driver/rtc
rtc_time : 01:00:21
rtc_date : 2012-08-16
Change-Id: If23f436796754c68ae6244ef7633ff4fa0a93603
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1709
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
|
|
When a power failure happens on the RTC rail, the CMOS memory (including
the RTC registers) is filled with garbage.
So, we erase the full first bank (112 bytes) and we reset the RTC date
to the build date.
To test, disconnect the CMOS battery to produce an RTC power
failure, then boot the machine and observe the RTC date is the build
date using "cat /sys/class/rtc/rtc0/date"
Change-Id: I684bb3ad5079f96825555d4ed84dc0f7914e9884
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1697
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
|
|
On Panther Point PCH (and maybe cougar point), when some of the register
D reserved bits are set, the RTC starts misbehaving (e.g. incrementing
the year byte every second).
There are probably undocumented features implemented behind those bits.
Let's reset register D to a known state to ensure we get the expected
RTC behavior.
Change-Id: I7e2c2a2c6130a974bccb3d760b41eaa579a58b67
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: http://review.coreboot.org/1695
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
|
|
If the CMOS is cleared or someone writes some random date/time
on purpose, the CMOS date register has a invalid date. This will
hurts some OS, like Windows 7, which hangs at MS logo forever.
When we detect that, we need to write a reasonable date in CMOS.
Alexandru Gagniuc:
Hmm, it would be interesting to use the date the coreboot image
was built and set that as the default date. At least until time
travel is invented.
Change-Id: Ic1c7a2d60e711265686441c77bdf7891a7efb42e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1389
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
There is no reason for this to be a top level directory.
Some stuff from lib/ should also be moved to drivers/
Change-Id: I3c2d2e127f7215eadead029cfc7442c22b26814a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/939
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
