For my nvidia mcp79 based system, I was able to fix the bios reported CMOS checksum error by making updateChecksum() return without updating anything. The lion GM patch that only skips the updateChecksum() call from rtcRecordTracePoint() was insufficient in my case.
In my case using an unconditional jump over the rtcWrites within updateChecksum proc and is ok the last couple of weeks.
Anyway, with the heavyweights around I dread to add my two cents worth.
Nevertheless better to put it out. With a RTC register length of 0x02 nothing seems to be disturbed in the CMOS memory map. When the RTC register length is set to 0x04, we can read some values in 0x58 & 0x59 of the CMOS memory map, but 0x2e & 0x2f remains as before. These changes would appear to occur at startup. Subsequently with every sleep and wake before reboot, 0x2e is reduced by one, invalidating the real CMOS checksum.
However, even without any sleep/wake before reboot, with a RTC register length of 0x04 and with 0x2e & 0x2f unchanged but 0x58 & 0x59 populated, a CMOS Checksum error occurs at reboot. So it seems the CMOS memory map Checksum is updated at shutdown or just before reboot. Tried my hand to modify DumpCMOS.kext to write zeros to 0x58 & ox59 in the CMOS memory map, to test but failed to alter them.
Hence I would surmise that AppleRTC writes to some global memory area from where, these and others like RTC Alarms are reevaluated and written to the CMOS memory map when the system starts or stops by another agent - maybe the kernel itself or other.
Wonder if real intel-Macs have a 'CMOS memory map' and whether similar changes occur at those affected addresses. Haven't figured out what those values at 0x58 & 0x59 represent.