The patch moves ACPI parsing code to a separate function
GetCenturyRtcAddress() and the next patch will call this
function in driver entry point.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Anbazhagan Baraneedharan <anbazhagan@hp.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
The patch fixes a regression bug caused by last check-in which
causes Daylight setting cannot be set when timezone is unspecified.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
When SetTime() is called with EFI_UNSPECIFIED_TIMEZONE, the code
can optimally not create the private timezone variable because
absence of timezone variable indicates the timezone is unspecified.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19783 6f19259b-4bc3-4df7-8a09-765794883524
The patch updates the Century value in CMOS location specified
by FADT.Century to avoid UEFI Win7 hang during booting.
Per the ACPI spec if the FADT.Century is zero, it's not needed
to store the century value in CMOS. But UEFI Win7 treats the
Century storage is optional only when FADT.Century is 0x80.
While Linux strictly follows the ACPI spec and treats Century
storage is optional when FADT.Century is 0.
So if a platform wants to support both UEFI Win7 and Linux,
it needs to report FADT.Century to a traditional value which
doesn't equal to 0 or 0x80 (0x32 mostly). And RTC driver is
enhanced to save the century value to the location specified
by FADT.Century.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19442 6f19259b-4bc3-4df7-8a09-765794883524
The original driver cannot handle the case when system time runs from 1999/12/31 23:59:59
to 2000/1/1 0:0:0.
A simple test to set system time to 1999/12/31 23:59:59 can expose this bug.
The patch limits the driver to only support year in 100 range and decide the century value based
on the supporting range: Century either equals to PcdMinimalYear / 100 or equals to PcdMinimalYear / 100 + 1.
The patch passed the Y2K test.
However with year range [1998, 2097], when system time is 2097/12/31 23:59:59,
the next second system time will become 1998/1/1 0:0:0. I think it's a acceptable limitation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17624 6f19259b-4bc3-4df7-8a09-765794883524
1. RtcTimeFieldsValid() has bug checking the validity of TIME fields, which causes SetTime() will not return EFI_INVALID_PARAMETER when it is fed with invliad time fields.
2. Logical error in handling Time Zone and Day Light Saving.GetTime() won't return Time Zone and Day Light Saving set by last SetTime() call.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8948 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni
Elvin Li
li-elvin
erictian
ydong10
hhtian
gikidy
rsun3
klu2