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
Ruiyu Ni
li-elvin
ydong10
hhtian
klu2