On Thu, 31 Mar 2005, ramesh bios wrote:
Well, I got things to work in the end by copying the standard bios's CR bit settings for the W83977AF. Regretably though, I have gained no understanding of why or how it's working. Amazingly, the standard bios sets CR30 on the W83977AF, ie: the RTC enable/disable bit to disabled. So the RTC appears to increment properly when that bit is disabled (which makes no sense to me at all, ie: disable the RTC and it ticks properly?). When that bit is enabled, and no other changes, the RTC has weird incrementation behavior. Almost seemed like random bits in mm:ss were changing. Also, I never understood why bytes in 0E-7F, the user ram changes during normal ticking of the clock. Oh well, it's working now so I guess I'll just push this mystery to the back of my mind. If anyone happens to understand this stuff, I'll sleep better once I've understood this.
Thanks.
--- ramesh bios ramesh_bios@yahoo.com wrote:
I was looking through linuxbios' freebios (v1) code and see the following:
rtc_checksum_valid(PC_CKS_RANGE_START,
PC_CKS_RANGE_END,PC_CKS_LOC); then rtc_checksum_valid(LB_CKS_RANGE_START,
LB_CKS_RANGE_END,LB_CKS_LOC); then finally rtc_set_checksum(PC_CKS_RANGE_START,
PC_CKS_RANGE_END,PC_CKS_LOC);
I looked in 2.6.11's mc146818 code and I don't see it writing a checksum so I'm not certain it's valid to check for a checksum on boot since stuff like hwclock may/would have written to the cmos during normal operation. Out of curiosity, how come there is a LB checksum and then a PC checksum and then we write a PC checksum at the end. Is it for legacy compatibility, I didn't find any mention of it in the mailing list and google.
Thanks.
The @clustermatic.org mail address is not to be used anymore.
If anyone knows anything about the above question please put this in the wiki-faq...
Best regards
Peter K
On Fri, 1 Apr 2005, Peter Karlsson wrote:
If anyone knows anything about the above question please put this in the wiki-faq...
I think it's another hardware bug, and I think the description as ramesh wrote it would be nice to have in the FAQ. One of these "set this bit, don't ask why" type situations.
ron
mystery to the back of my mind. If anyone happens to understand this stuff, I'll sleep better once I've understood this.
I think it's another hardware bug, and I think the description as ramesh wrote it would be nice to have in the FAQ. One of these "set this bit, don't ask why" type situations.
Check for errata notes on the part. Perhaps the polarity of the enable/disable bit is flipped and incorrect in datasheet.