Scott, I debugged the issue further and had the below findings: According to the ACPI spec 6.0 5.2.9 Fixed ACPI Description Table (FADT), the FADT.Century can be set to 0 indicating the RTC doesn't support to store century value. But the Win7 boot loader hal!HalpInitializeCmos() will firstly read and save the FADT.Century to a 4-byte location pointed by hal!_HalpCmosCenturyOffset. When the FADT.Century is 0, it will save 0x32 (default value) to that location. Later hal!HalpReadCmosTime() skips to read the century value from CMOS when BIT 7 of the value poited by hal!_HalpCmosCenturyOffset is set. So in order to tell Windows that RTC doesn't support to store century, we need to set the FADT.Century to 0x80 other than 0. In summary, if FADT.Century is 0, Win7 boot loader reads century from 0x32; if FADT.Century & BIT7 != 0, it doesn't read century from CMOS; otherwise, it reads century from CMOS index FADT.Century.
But that caused another issue. Linux code strictly follows the ACPI spec which reads the century value from FADT.Century if it doesn't equal to zero. If we leave 0x80 in FADT.Century, Linux kernel will reads century from 0x80 location (actually from location 0 because CMOS address is 7-bit). Location 0 stores the seconds of the time which means Linux will read random century value. So do you agree if a platform needs to support booting both Windows and Linux, it had better to set FADT.Century to 0x32 and save correct century value (0x20) to CMOS address 0x32? Regards, Ray -----Original Message----- From: Scott Duplichan [mailto:sc...@notabs.org] Sent: Friday, November 20, 2015 10:56 PM To: Ni, Ruiyu <ruiyu...@intel.com> Cc: 'Paolo Bonzini' <pbonz...@redhat.com>; 'edk2-devel@lists.01.org' <edk2-de...@ml01.01.org>; Zeng, Star <star.z...@intel.com> Subject: RE: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: ]Sent: Friday, November 20, 2015 01:37 AM ]To: Scott Duplichan <sc...@notabs.org> ]Cc: Paolo Bonzini <pbonz...@redhat.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Zeng, Star ]<star.z...@intel.com> ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue ] ]Scott, ]The UEFI Windows 7 is fresh installed. Could you please tell me how to check ]whether a platform turns on the RTC alarm? ] ]Thanks, ]Ray Hello Ray, I think just about every system that can run UEFI supports RTC alarm, at least in the x86 world. It is support for the century feature that could possibly be disabled on some systems. For example, an internet search for "RTC Century support" finds an AMD Bolton document that describes a CenturyEn bit: Enable RTC Century support. So apparently systems using AMD Bolton could be configured for no RTC century support at all. I don't know if anyone would actually do this. But if they did, it would make sense for UEFI to not write a value into a CMOS century byte. Tahnks, Scott > 在 2015年11月20日，10:49，Scott Duplichan <sc...@notabs.org> 写道： > > Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: > > ]Sent: Thursday, November 19, 2015 06:37 PM > ]To: Paolo Bonzini <pbonz...@redhat.com>; Zeng, Star <star.z...@intel.com>; > edk2-devel@lists.01.org <edk2-]de...@ml01.01.org> > ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang > issue > ] > ]If we strictly follow the spec, it's only needed to save the century value > ]in CMOS when FADT.CenturyOffset is not zero. But the fact is even we set > ]the FADT.CenturyOffset to 0 indicating the platform doesn't store century > ]value in CMOS, UEFI Win7 still hang during booting until we updates the value > ]in CMOS location. So we have to always save the century value in CMOS. > ] > ]Regards, > ]Ray > > It sounds like you are testing on a machine that requires programming of > the RTC century value in order for the RTC alarm interrupt to work. If the > century value is not programmed, the alarm interrupt will never occur and > Windows 7 bootup will hang waiting for the interrupt. So a boot hang after > setting FADT.CenturyOffset to zero with no CMOS x32 write is expected. It > could be said that this machine requires FADT.CenturyOffset be set in order > to boot Windows 7. I don't see how this justifies writing CMOS x32 > unconditionally. > > What if a different system keeps some important value in CMOS x32 that is > unrelated to the RTC alarm function? The UEFI developer will set > FADT.CenturyOffset to zero and that will keep the OS from overwriting it. > But with this patch, UEFI itself will overwrite the value at CMOS x32. The > developer no longer has a configuration mechanism that prevents both the OS > and UEFI itself from writing to CMOS. > > Thanks, > Scott > > > ]-----Original Message----- > ]From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > ]Sent: Friday, November 20, 2015 6:17 AM > ]To: Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>; > edk2-devel@lists.01.org > ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang > issue > > > >> On 18/11/2015 06:08, Zeng, Star wrote: >> >> @@ -508,6 +509,7 @@ PcRtcSetTime ( >> RtcWrite (RTC_ADDRESS_DAY_OF_THE_MONTH, RtcTime.Day); >> RtcWrite (RTC_ADDRESS_MONTH, RtcTime.Month); >> RtcWrite (RTC_ADDRESS_YEAR, (UINT8) RtcTime.Year); >> + RtcWrite (RTC_ADDRESS_CENTURY, Century); > > Should it be written only if the FADT CenturyOffset is zero? > > Paolo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
