Jump to content

CMOS Resets on Restarts after Sleep and Wake in 10.7 (Lion)


  • Please log in to reply
485 replies to this topic

#81
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK
Well I'm still pi**ing in the wind here with this, though I've read more of the ACPI spec and Intel ICH10 spec sheet. Trouble is trying to understand it and how it translates to the problem here.

I looked at DHP's question of 'Are people here still seeing this: "Only one ram bank..." message in kernel.log?' and rayap's response concur's here with the message only showing if a length of 0x02 is used. This makes more sense to me now as I know there are two banks (standard and extended) to my RTC.

When I looked through my kernel log though, I saw an occurence where the date had changed to December 24th with the message 'RTC: lost battery power - time may be invalid'.?? This happended yesterday when I was doing more of my 'stupidly undocumented (why don't I ever write down what I've done)' trial and error changes to my DSDT so unfortunately I can't remember what I did to cause it. This might be nothing, but at least it's something that shows me that making changes does effect the RTC in a manner that I can see.
Attached File  RTC_lost_power.png   40.26KB   99 downloads

#82
jacoweb

jacoweb

    InsanelyMac Protégé

  • Members
  • PipPip
  • 76 posts
  • Location:Norway
  • Interests:Apple<br />OSX86<br />Music
installed the AppleRTC kext from 10.6.7 and sleep is now working on my hack! Gigabyte x58a UD7. Thanks! But i hope for a proper fix later :blink:

#83
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK
Looking at both AppleRTC binaries (v1.3.1 and v1.4) in a hex editor I can see many more strings in v1.4 referring to RTC.

v1.3.1
AppleRTC Binary - v1.3.1rootAppleRTCUserClientAppleRTCRTC: %s setting ignoredWake TypeAlarmMaintenance maintenanceRTC:%s alarm %u/%u/%u %02u:%02u:%02u, sleep %u/%u/%u %02u:%02u:%02uIOHibernateRTCVariables/optionsRTC: disableAlarm failed (StatusB = %02x)RTC: map device memory failedRTC: invalid device register mapRTC: Only single RAM bank (128 bytes)RTC: no memory for RAM shadowRTC: lost battery power - time may be invalidFACPRTC: installInterruptForFixedEvent() failedRTC: registerInterrupt() failed %xWakeByCalendarDatePowerByCalendarDateWakeRelativeToSleepPowerRelativeToShutdownMaintenanceWakeCalendarDate"¬Multiple inheritance is not supported"@/System/Library/Frameworks/Kernel.framework/PrivateHeaders/libkern/c++/OSMetaClass.h:¬324IOPMRegisterNVRAMTracePointHandlerIOPlatformWakeActionIORTCIOHibernateStatecom.apple.driver.AppleRTC1.3.1

v1.4.1
rootAppleRTCUserClientAppleRTCRTC: rtcWrite( 0x%x ) errorRTC: rtcRead( 0x%x ) errorRTC: Invalid %s - Date %u/%u/%u Time %u:%u:%uRTC: %s setting ignoredRTC: calendar wake = %dRTC: calendar power-on = %dRTC: alarm seconds = %uRTC: power-on seconds = %uRTC: [%s] not handledRTC: [%s] Y %d, M %d, D %d, H %d, M %d, S %d (%x)Wake TypeAlarmRTC: acting on wake from AlarmRTC: updated wake type to maintenanceMaintenance maintenanceRTC:%s alarm %u/%u/%u %02u:%02u:%02u, sleep %u/%u/%u %02u:%02u:%02uRTC: setGMTTimeOfDay %ldRTC: fixedEventHandler %02xRTC: enableAlarm (StatusC = %02x)RTC: systemWillShutdown was not calledRTC: getGMTTimeOfDay %ldRTC: disableAlarmRTC: disableAlarm (%d retry)RTC: disableAlarm failed (StatusB = %02x)RTC: setPowerState %uRTC: rtcSafeRead( 0x%x ) error 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F-----------------------------------------------%02x RTC: alarm has already expired, alarm %ld, now %ldRTC: alarm time   Month %02x, Day %02x, Time %02x:%02x:%02xRTC: current time Month %02x, Day %02x, Time %02x:%02x:%02xRTC: setupDateTimeAlarm update retryRTC: setupDateTimeAlarm done (%d retry)rtcIOHibernateStateRTC: map device memory failedRTC: invalid device register mapRTC: Only single RAM bank (128 bytes)RTC: no memory for RAM shadowRTC: lost battery power - time may be invalidFACPRTC: DayAlarm register at 0x%xRTC: MonAlarm register at 0x%xRTC: installInterruptForFixedEvent() failedRTC: registerInterrupt() failed %xWakeByCalendarDatePowerByCalendarDateWakeRelativeToSleepPowerRelativeToShutdownMaintenanceWakeCalendarDate¬IOPMRegisterNVRAMTracePointHandlerRTC: registered tracepoint handler 0x%08x 0x%08xIOPlatformWakeActionIORTCRTC: rtcWriteBytes( %p, 0x%x, 0x%x ) errorRTC: writeBytes( data %p, offset 0x%x, size 0x%x ) took %llu usRTC: setHibernateState() errorIOHibernateRTCVariables/optionsRTC: Restored entire RTC RAMRTC: Restored hibernation controlRTC: rtcReadBytes( %p, 0x%x, 0x%x ) errorRTC: readBytes( data %p, offset 0x%x, size 0x%x ) took %llu usRTC: TracePoint(%08x, %08x, %08x) thread %p, writes %d, %ccrc %04x, hib %u, took %llu usRTC: setAlarmEnable 0x%xRTC: enabled wake alarmRTC: enabled power-on alarmcom.apple.driver.AppleRTC1.4

It seems Apple are doing much more with this version of the kext now....

EDIT:
This line looks interesting
RTC: writeBytes( data %p, offset 0x%x, size 0x%x ) took %llu us

#84
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
@BlackOSX

Refresh: http://www.insanelym...p...t&p=1200071

#85
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK

@BlackOSX

Refresh: http://www.insanelym...p...t&p=1200071

Hi rayap - Thanks for the link :wacko:

I see Azi posted about the 'RTC: lost battery power - time may be invalid' error when he changed the address range which is what I did the other night so that must have been the cause of me also seeing that particular error in the kernel.log.

I'll look more in to that post a bit later as I have to go out now.... be back later :)

EDIT:
Oh.. and the reason I/(we) use Device (RTC) and Device (TIMR) as we do now, without ATT0/ATT1 is mainly down to MasterChief when he posted this in the Gigabyte DSDT topic.

#86
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK
I thought I'd be clever (yes, I've been reading DHP's topic) and use otool to disassemble both v1.3.1 and v1.4 of the AppleRTC binaries and now I'm completely lost and drowning in a sea of mnemonics.... :)

I think now's the time to stop and just be happy to use JUN Ho's trick.

#87
stefano.85

stefano.85

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 229 posts
  • Gender:Male
  • Location:Italy

I thought I'd be clever (yes, I've been reading DHP's topic) and use otool to disassemble both v1.3.1 and v1.4 of the AppleRTC binaries and now I'm completely lost and drowning in a sea of mnemonics.... :)

I think now's the time to stop and just be happy to use JUN Ho's trick.


LOL i think you've already done so much work.... go to sleep for today :P and don't think so much to it...
Unfortunately i'm not a coder and i can't do so much...I think the solution is out there and that some gurus are already working on this. cheers!

#88
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK
Hi stefano.85.

Thanks. I'm no coder either (well, at least not low-level stuff) and yes, it's time to give it a rest. Hopefully somebody else will shine the light on this problem.. :)

#89
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY
I wish I was smarter to figure this out.

Bump. :)

#90
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
Yeah, me too…

And blackosx, you are not alone… I was working really hard in a last 24h to crack this one… What most is troubling me is the fact that I was managed to restart my computer properly a couple of times, but now it simply refuses to work… I’m really confused what happens, because as I said, I had 3 or 4 times CMOS reset and then I was made some changes in DSDT and managed to make 3 times sleep/wake/restart operation properly. After second rollback it didn’t want to work again… I regret now one thing and that is the fact that I didn’t backup my DSDT from that stage, but I was continue to mass with him further… During my work I was really made a lot of drastic changes in it and now I’m not sure anymore how some parts was looked like in that very moment. I was even manage to built another variation of my DSDT which is also working vanilla but this one is built from original code components for Device (RTC), (HPET) and (TIMR), which I was cut and paste directly from MacPro3,1 DSL. So here is my observation for that part…

This is a piece of code that I was using previously:
[codebox]
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (ATT3, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadWrite,
0xFED00000, // Address Base
0x00000400, // Address Length
)
})
Name (ATT4, ResourceTemplate ()
{
})
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}

Method (_CRS, 0, NotSerialized)
{
Return (ATT3)
}
}

Device (TMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (ATT6, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})

Method (_CRS, 0, NotSerialized)
{
Return (ATT6)
}
}

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (ATT0, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
Name (ATT1, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
Method (_CRS, 0, NotSerialized)
{
Return (ATT0)
}
}
[/codebox]
This is the MacPro3,1 code:
[codebox]
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y09)
})
Method (_STA, 0, NotSerialized)
{
If (LGreaterEqual (OSYS, 0x07D1))
{
If (HPAE)
{
Return (0x0F)
}
}
Else
{
If (HPAE)
{
Return (0x0B)
}
}

Return (0x00)
}

Method (_CRS, 0, Serialized)
{
If (HPAE)
{
CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y09._BAS, HPT0)
If (LEqual (HPAS, 0x01))
{
Store (0xFED01000, HPT0)
}

If (LEqual (HPAS, 0x02))
{
Store (0xFED02000, HPT0)
}

If (LEqual (HPAS, 0x03))
{
Store (0xFED03000, HPT0)
}
}

Return (BUF0)
}
}
Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x01, // Alignment
0x08, // Length
)
})
Name (BUF1, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x01, // Alignment
0x08, // Length
)
IRQNoFlags ()
{8}
})
Method (_CRS, 0, Serialized)
{
If (HPAE)
{
Return (BUF0)
}

Return (BUF1)
}
}

Device (TIMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x01, // Alignment
0x04, // Length
)
IO (Decode16,
0x0050, // Range Minimum
0x0050, // Range Maximum
0x10, // Alignment
0x04, // Length
)
})
Name (BUF1, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x01, // Alignment
0x04, // Length
)
IO (Decode16,
0x0050, // Range Minimum
0x0050, // Range Maximum
0x10, // Alignment
0x04, // Length
)
IRQNoFlags ()
{0}
})
Method (_CRS, 0, Serialized)
{
If (HPAE)
{
Return (BUF0)
}

Return (BUF1)
}
}
[/codebox]
So I was change my code with this one (MacPro3,1 routinne)...
[codebox]
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (BUF0, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y0D)
})
Method (_STA, 0, NotSerialized)
{
If (LEqual (OSFL (), Zero))
{
If (HPTE)
{
Return (0x0F)
}
}
Else
{
If (HPTE)
{
Return (0x0B)
}
}

Return (Zero)
}

Method (_CRS, 0, NotSerialized)
{
If (HPTE)
{
CreateDWordField (BUF0, \_SB.PCI0.SBRG.HPET._Y0D._BAS, HPT)
If (LEqual (HPTS, One))
{
Store (0xFED00000, HPT)
}
}

Return (BUF0)
}
}
Device (TIMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
})
Name (BUF1, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
IRQNoFlags ()
{0}
})
Method (_CRS, 0, Serialized)
{
If (HPTE)
{
Return (BUF0)
}

Return (BUF1)
}
}

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (BUF0, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
})
Name (BUF1, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x04, // Length
)
IRQNoFlags ()
{8}
})
Method (_CRS, 0, Serialized)
{
If (HPTE)
{
Return (BUF0)
}

Return (BUF1)
}
}
[/codebox]
This working 100% in SL, however didn't fix CMOS reset in Lion...
Eventually I was decide to rollback everything on my original BIOS code and this is what I'm using now...
[codebox]
Device (HPET)
{
Name (_HID, EisaId ("PNP0103"))
Name (CRS, ResourceTemplate ()
{
IRQNoFlags ()
{0}
IRQNoFlags ()
{8}
Memory32Fixed (ReadOnly,
0xFED00000, // Address Base
0x00000400, // Address Length
_Y0D)
})
OperationRegion (^LPCR, SystemMemory, 0xFED1F404, 0x04)
Field (LPCR, AnyAcc, NoLock, Preserve)
{
HPTS, 2,
, 5,
HPTE, 1,
Offset (0x04)
}

Method (_STA, 0, NotSerialized)
{
If (LEqual (OSFL (), Zero))
{
If (HPTE)
{
Return (0x0F)
}
}
Else
{
If (HPTE)
{
Return (0x0B)
}
}

Return (Zero)
}

Method (_CRS, 0, NotSerialized)
{
CreateDWordField (CRS, \_SB.PCI0.SBRG.HPET._Y0D._BAS, HPT)
Multiply (HPTS, 0x1000, Local0)
Add (Local0, 0xFED00000, HPT)
Return (CRS)
}
}

Device (TIMR)
{
Name (_HID, EisaId ("PNP0100"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x00, // Alignment
0x04, // Length
)
})
}

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x00, // Alignment
0x02, // Length
)
IRQNoFlags ()
{8}
})
}

[/codebox]

During this code exchange I notice two things...
When I rollback:
IRQNoFlags ()
{0}

for Device (TIMR), my sound is messed up, and...
IRQNoFlags ()
{2}

for Device (PIC), breaks sleep operation...

None of these changes was manage to fix CMOS reset in Lion!!!

#91
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,054 posts
  • Gender:Male
  • Location:UK

I wish I was smarter to figure this out.

Me too :P
But hey, lets keep looking.

I'm not 100% sure that I understand the principle of the problem here and why we get the CMOS error.

I know there is a checksum in the CMOS registers 0x2E and 0x2F. So are those registers being changed or the other registers (0x10->0x2D) which the checksum is calculated from?

If the CMOS registers are being written to, when exactly and how? Through ACPI or a low-level kernel driver? I think OS X communicates to ACPI which in turn communicates to BIOS/CMOS. If that's correct, that means OS X (and AppleRTC) doesn't communicate directly with BIOS/CMOS.

Therefore, what's missing from the ACPI tables (presumably the DSDT but could be another table?) that AppleRTC v1.4 needs? AppleRTC v1.3.1 works just fine as JUN Ho found out.

Overall. I don't understand nearly enough here to nail this problem and I guess we need all the help we can get. So maybe we should find some of the devs around the community to give us their opinion?

And blackosx, you are not alone…

Hi Vlada

Keep up the research and one day somebody will find the answer. :)

Gutted to hear you lost the DSDT that you say fixed the error.. (I did ask you to post it :( ). Hopefully you can re-trace your steps and reproduce it because I haven't a clue as to what you would have done to fix it.

The IRQ's have been know to cause problems with hackintosh so most DSDT's have them removed. See here for example.

I'm going away for a week tomorrow morning so I won't be able to do any further testing until I get back.

#92
albert E

albert E

    InsanelyMac Protégé

  • Members
  • PipPip
  • 50 posts

Heh, nice but I'd rather prefer that we find proper solution… :thumbsup_anim:


Good catch… I was become aware of that today, when I was left my room on 15 minutes… As for SL auto-sleep issue, I’m using Please Sleep…

Well, I don't know… First I was thinking that this is ICH9 chipset error only, but obviously it's not… It catches ICH10 too… Then I was suspect that perhaps Device (EHCI) could be related with this little issue, but again I was wrong… After I was made a couple of tests it appears eventually, that is not the problem (or at least not in my case)…

I really don't have a clue now, because it's seems that there is no pattern or at least I can't see any. Maybe we should put on pile all elements from the DSDT code related with sleep and then start from there…

Man, it would be nice if we could locate same motherboard in two different computers, where one haves CMOS error problem and other one don’t. Then we could just simply compare DSDT-s from both computers and easily locate what’s causing all this…



Put dsdt.aml in the root directory

#93
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia

Put dsdt.aml in the root directory


Eh? What's that gonna change?

#94
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
Hi blackosx

"So to summise at this point:
This all looks normal and doesn't really help here. Something is changing the CMOS data somehow?"

I think these dump utilites are not reading the cmos correctly beyond the first 64 bytes. In your results the top half is a mirror of the second half. i was able to read using 'DosBox" and 'CmosDos' the 128 bytes where the halfs are different. With Windows XP under Parallels we can read 256 bytes.

The cmos reading in Windows XP machine directly gives good and valid values for the whole of the standard bank of 128 bytes. The values in the second half of the standard bank changes. if you amend your cmos settings - say enabling startup alarm.

But for DosBox or XP in Parallels, similar changes in cmos settings are not reflected at all in the cmos readings. They appear as constant. Even if we schedule a startup in Enery Saver settings, there is no change in the particular cmos locations. Either we cannot read these cmos locations with our present means or these are kept elsewhere in a real mac.

An osx utilty to directly dump cmos will help.

CMOSTimer: http://www.boraxsoft...STimer_eng.html

#95
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
What you want to do is to locate the write action that is causing the CMOS reset. For this I have a few test in mind that need to be done with Apple RTC v1.4 Do it one at a time. Write down what you did (blackosx :) ) and return here with iyr findings. Oh. You will probably find two of each (one for 32-bit and one for 64-bit code) so patch them both!

Step-1: Open AppleRTC and search for the following byte combination:
AppleRTCUserClient::clientWriteBytes(void*, void*, void*, void*, void*, void*)	+0	00000560  55					  pushl		  %ebp	+1	00000561  89e5					  movl		  %esp,%ebp	+3	00000563  53					  pushl		  %ebx	+4	00000564  57					  pushl		  %edi	+5	00000565  56					  pushl		  %esi	+6	00000566  83ec1c				  subl		  $0x1c,%esp	+9	00000569  837d1000				  cmpl		  $0x00,0x10(%ebp)
Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble.

Step-2: Search for the following byte combination:
AppleRTC::rtcWrite(unsigned int, unsigned char)	+0	00000b6a  55					  pushl		  %ebp	+1	00000b6b  89e5					  movl		  %esp,%ebp	+3	00000b6d  57					  pushl		  %edi	+4	00000b6e  56					  pushl		  %esi	+5	00000b6f  83ec20				  subl		  $0x20,%esp	+8	00000b72  8b750c				  movl		  0x0c(%ebp),%esi
Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble.

Step-3: Search for the following byte combination:
AppleRTC::rtcWriteBytes(unsigned char*, unsigned int, unsigned int)	+0	00002d7a  55					  pushl		  %ebp	+1	00002d7b  89e5					  movl		  %esp,%ebp	+3	00002d7d  53					  pushl		  %ebx	+4	00002d7e  57					  pushl		  %edi	+5	00002d7f  56					  pushl		  %esi	+6	00002d80  83ec3c				  subl		  $0x3c,%esp	+9	00002d83  833de450000000		  cmpl		  $0x00,0x000050e4
Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble.

Step-4: Search for the following byte combination:
AppleRTC::rtcWriteBytesAndCRC(unsigned char*, unsigned int, unsigned int)	+0	00002ee6  55					  pushl		  %ebp	+1	00002ee7  89e5					  movl		  %esp,%ebp	+3	00002ee9  57					  pushl		  %edi	+4	00002eea  56					  pushl		  %esi	+5	00002eeb  83ec10				  subl		  $0x10,%esp	+8	00002eee  8b4514				  movl		  0x14(%ebp),%eax
Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble.

Note: C3 is the opcode for ret(urn).

No time to do this but this is a start. Good luck!

#96
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
Hi DHP you are a clever fella.

I only made the change for the rtcWriteBytesAndCRC in 64-bit. Tested with rtc register length of 0x04 and 0x08. Everything went well. No CMOS resets for the old problem of restarts which required a register length of 0x02 or sleep in Lion of this topic.
But what's next

#97
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
Right. Function rtcWriteBytesAndCRC is called from two places (read functions) and we need to narrow the scope to one, so please do this:

1.) Backup your current version.
2.) Restore the original / unmodified file.
3.) Follow step-1 to block clientWriteBytes.

And if that doesn't work, then I know where to look next aka function setHibernateState which is where I think {censored}e happens ;)

Thanks for testing this!

#98
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
Done that in 64-bit and the cmos reset reappears with rtc reg length 0x02. Looks like an extra call from setHibernateState to rtcWriteBytesAndCRC in this version of the kext. Hope this suffice. Rgds.

#99
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

Done that in 64-bit and the cmos reset reappears with rtc reg length 0x02. Looks like an extra call from setHibernateState to rtcWriteBytesAndCRC in this version of the kext. Hope this suffice. Rgds.

Ok so this appears to be done in function setHibernateState and thus there are a couple of things that you can do.

Step-1: Search for this and let it ret(urn) by replacing 55 with C3
AppleRTC::setHibernateState(unsigned long)	+0	00002f26  55					  pushl		  %ebp	+1	00002f27  89e5					  movl		  %esp,%ebp	+3	00002f29  53					  pushl		  %ebx	+4	00002f2a  57					  pushl		  %edi	+5	00002f2b  56					  pushl		  %esi	+6	00002f2c  83ec1c				  subl		  $0x1c,%esp	+9	00002f2f  8b7508				  movl		  0x08(%ebp),%esi
If returning there works, then we know that we're at the right spot.

I checked v1.3 and there I see two write calls, but in v1.4 I see three of them. My guess would be that it is either the last one you need to change, or the one before that. Replacing the calll with nop's (no operation / 90) to see if that works (and for which one).

One of the write operations reads: "RTC: Restored entire RTC RAM\n" so that might be the one :)

Note well that bin-patching AppleRTC might in the end not be required, but that is something to be seen at a later stage.

Good luck!

#100
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
Hi DHP
Blocking setHibernateState did not give desired result. Decided to go downstream. When blocking rtcWriteBytesAndCRC was looking good, went on to blocking updateChecksum. Consequently only blocking the Call ( with nops' as you suggested) from rtcRecordTracePoint to updateChecksum gave desired result. With rtc reg length 0x08. restarts after sleep do not gives cmos reset.

Is this helpful at all? So what's next?

Edit: Don't know how to replace equivalent jmp in v1.3.1 Used C3 and nops'

Update:
1. Blocking the jmp from recordTracePointHandler to rtcRecordTracePoint in both versions 1.3.1 & 1.4 of AppleRTC resolves the RTC register length cmos resets.
2. Blocking both the call and jmp from setAlarmEnable to rtcRecordTracePoint in ver1.4 of AppleRTC resolves the cmos rests after sleep.

Thus far all seems well.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy