Yosemite 10.10.2 - No wakeup from sleep

[the-darkvoid]

Ok, so it still works successfully with a bios size of 64MB.

Less then that will cause a kernel panic because the frame buffer size would be larger than the stolen memory size.

Now I cannot remember for the life of me what the default value of the Dell XPS9530 before unlocking was...

If it was 64MB, then it would work without touching the BIOS. I will update the guide accordingly.

 

[RehabMan]

Ok, so it still works successfully with a bios size of 64MB.

Less then that will cause a kernel panic because the frame buffer size would be larger than the stolen memory size.

Now I cannot remember for the life of me what the default value of the Dell XPS9530 before unlocking was...

If it was 64MB, then it would work without touching the BIOS. I will update the guide accordingly.

Interesting stuff. 64MB for BIOS is typical...

Sounds like the framebuffer is perhaps allocated out of the stolen memory and therefore has to be smaller (an efficiency trick?).

Maybe someone with an unmodified Dell BIOS can try.

 

[the-darkvoid]

Interesting stuff. 64MB for BIOS is typical...

Sounds like the framebuffer is perhaps allocated out of the stolen memory and therefore has to be smaller (an efficiency trick?).

Maybe someone with an unmodified Dell BIOS can try.

Thats is what the assertion says "fFramebufferSize > fStolenMemorySize"

 

[syscl]

10.0.1 (or possibly 10.10.0, in any case working framebuffer):

08 00 2E 0A 
01 03 03 03 00 00 00 04 00 00 20 02 
00 00 50 01 00 00 00 60 6C 05 00 00
6C 05 00 00 00 00 00 00 00 00 00 00 
00 00 08 00 02 00 00 00 30 00 00 00 
01 05 09 00 00 04 00 00 07 01 00 00 
02 04 0A 00 00 04 00 00 07 01 00 00 
FF 00 00 00 01 00 00 00 40 00 00 00 
1E 00 00 00 05 05 09 01 00 00 00 00 
00 00 00 00 80 [COLOR=#FF0000]76[/COLOR] 04 00 00 00 00 00 
C0 [COLOR=#FF0000]7F[/COLOR] 04 00 00 00 00 00 32 00 00 00 
00 00 00 00 0C

10.10.2:

08 00 2E 0A
01 03 03 03 00 00 00 04 00 00 20 02 
00 00 50 01 00 00 00 60 6C 05 00 00 
6C 05 00 00 00 00 00 00 00 00 00 00 
00 00 08 00 02 00 00 00 30 00 00 00 
01 05 09 00 00 04 00 00 07 01 00 00 
02 04 0A 00 00 04 00 00 07 01 00 00 
FF 00 00 00 01 00 00 00 40 00 00 00 
1E 00 00 00 05 05 09 01 00 00 00 00 
00 00 00 00 80 [COLOR=#FF0000]86[/COLOR] 04 00 00 00 00 00 
C0 [COLOR=#FF0000]8F[/COLOR] 04 00 00 00 00 00 32 00 00 00 
00 00 00 00 0C

Unsure if these changes are still part of the frame-buffer data itself.

Sorry for the late reply since my laptop has a motherboard replacement. And after some research recently and get to know more about AppleIntelFramebufferAzul.kext, I found the point to enable lid wake after sleep (OS X ver >=10.10.2 and etc.), the key point is to replace 1E -> 0F, here's the two binary patch comes:

[COLOR=#0433FF][FONT=Menlo]<dict>[/FONT][/COLOR][FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Comment[COLOR=#0433ff]</key>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<string>[/COLOR]Enable lid wake after sleep for 0a2e0008 (c) syscl/lighting/Yating Zhou[COLOR=#0433ff]</string>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Disabled[COLOR=#0433ff]</key>[/COLOR][/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<false/>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<key>[COLOR=#000000]Find[/COLOR]</key>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<data>[/FONT][/COLOR]
[FONT=Menlo]                QAAAAB4AAAAFBQkB[/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]</data>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<key>[COLOR=#000000]Name[/COLOR]</key>[/FONT][/COLOR]
[FONT=Menlo]                [COLOR=#0433ff]<string>[/COLOR]AppleIntelFramebufferAzul[COLOR=#0433ff]</string>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Replace[COLOR=#0433ff]</key>[/COLOR][/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<data>[/FONT][/COLOR]
[FONT=Menlo]                QAAAAA8AAAAFBQkB[/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]</data>[/FONT][/COLOR]
[COLOR=#000000][FONT=Menlo]            [/FONT][/COLOR][COLOR=#0433FF][FONT=Menlo]</dict>[/FONT][/COLOR]

the second patch is to change framebuffer size

[COLOR=#0433FF][FONT=Menlo]<dict>[/FONT][/COLOR][FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Comment[COLOR=#0433ff]</key>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<string>[/COLOR]Enable 128MB BIOS, 48MB Framebuffer, 48MB Cursor for Azul framebuffer 0xa2e0008[COLOR=#0433ff]</string>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Disabled[COLOR=#0433ff]</key>[/COLOR][/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<false/>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<key>[COLOR=#000000]Find[/COLOR]</key>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<data>[/FONT][/COLOR]
[FONT=Menlo]                CAAuCgEDAwMAAAAEAAAgAgAAUAE=[/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]</data>[/FONT][/COLOR]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<key>[COLOR=#000000]Name[/COLOR]</key>[/FONT][/COLOR]
[FONT=Menlo]                [COLOR=#0433ff]<string>[/COLOR]AppleIntelFramebufferAzul[COLOR=#0433ff]</string>[/COLOR][/FONT]
[FONT=Menlo]                [COLOR=#0433ff]<key>[/COLOR]Replace[COLOR=#0433ff]</key>[/COLOR][/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]<data>[/FONT][/COLOR]
[FONT=Menlo]                CAAuCgEDAwMAAAAIAAAAAwAAAAM=[/FONT]
[COLOR=#0433FF][FONT=Menlo][COLOR=#000000]                [/COLOR]</data>[/FONT][/COLOR]
[COLOR=#000000][FONT=Menlo]            [/FONT][/COLOR][COLOR=#0433FF][FONT=Menlo]</dict>[/FONT][/COLOR]

I use 0a2e0008 for both M3800 and XPS 15 9530 since some users with resolution other than 1920x1080p have the problem to power up the HD4600 by 0a260006(unless use RehabMan's suggestion to use an external monitor or use 0a2e0008 to force HD5000 and Azul load in kernel cache). With 0a2e0008, both M3800 and XPS 15 9530 can run smoothly and flawlessly. [Fixed typo from 0a280008 to 0a2e0008 credit RehabMan]

 

[RehabMan]

I found the point to enable lid wake after sleep (OS X ver >=10.10.2 and etc.), the key point is to replace 1E -> 0F,

Interesting... a well known patch for 0xa2e000a and 0xa26000a is to replace the byte at the same location from 0xd6 -> 0x1e.

I use 0a28000e for both M3800 and XPS 15 9530p

0xa28000e is not a valid ig-platform-id. Perhaps you meant 0xa2e0008.

 

[syscl]

Interesting... a well known patch for 0xa2e000a and 0xa26000a is to replace the byte at the same location from 0xd6 -> 0x1e.



0xa28000e is not a valid ig-platform-id. Perhaps you meant 0xa2e0008.

Yes, sorry for my typo, I mean 0a2e0008

Hi, RehabMan, can you add this patch to the config.plist so that more people will benefit from this patch.(since your repositories from Github is so so popular )

 

[RehabMan]

Yes, sorry for my typo, I mean 0a2e0008

You should probably edit your post... (most people do not have the background to notice the typo).

Hi, RehabMan, can you add this patch to the config.plist so that more people will benefit from this patch.(since your repositories from Github is so so popular )

I was thinking of doing that...

diff --git a/config_HD4600_4400_4200.plist b/config_HD4600_4400_4200.plist
index ae3ab10..99e54b6 100644
--- a/config_HD4600_4400_4200.plist
+++ b/config_HD4600_4400_4200.plist
@@ -372,6 +372,18 @@
 			</dict>
 			<dict>
 				<key>Comment</key>
+				<string>Enable internal display after sleep for 0x0a2e0008, credit syscl/lighting/Yating Zhou</string>
+				<key>Disabled</key>
+				<true/>
+				<key>Name</key>
+				<string>AppleIntelFramebufferAzul</string>
+				<key>Find</key>
+				<data>AQAAAEAAAAAeAAAABQUJAQ==</data>
+				<key>Replace</key>
+				<data>AQAAAEAAAAAPAAAABQUJAQ==</data>
+			</dict>
+			<dict>
+				<key>Comment</key>
 				<string>Enable internal display after sleep for 0x0a2e000a, 0x0a26000a</string>
 				<key>Disabled</key>
 				<true/>
diff --git a/config_HD5000_5100_5200.plist b/config_HD5000_5100_5200.plist
index d3a132d..c4ccd6f 100644
--- a/config_HD5000_5100_5200.plist
+++ b/config_HD5000_5100_5200.plist
@@ -367,6 +367,18 @@
 			</dict>
 			<dict>
 				<key>Comment</key>
+				<string>Enable internal display after sleep for 0x0a2e0008, credit syscl/lighting/Yating Zhou</string>
+				<key>Disabled</key>
+				<true/>
+				<key>Name</key>
+				<string>AppleIntelFramebufferAzul</string>
+				<key>Find</key>
+				<data>AQAAAEAAAAAeAAAABQUJAQ==</data>
+				<key>Replace</key>
+				<data>AQAAAEAAAAAPAAAABQUJAQ==</data>
+			</dict>
+			<dict>
+				<key>Comment</key>
 				<string>Enable internal display after sleep for 0x0a2e000a, 0x0a26000a</string>
 				<key>Disabled</key>
 				<true/>

The patch encompasses the same bytes as the related patch for 0xa2x000a...

Do you know of a link where the contents of this byte are explained, or is this just "random replace and see what happens"?

 

[syscl]

You should probably edit your post... (most people do not have the background to notice the typo).

Fixed spelling mistakes as RehabMan's guide.

The patch encompasses the same bytes as the related patch for 0xa2x000a...

Do you know of a link where the contents of this byte are explained, or is this just "random replace and see what happens"?

Nope, I was inspired by the search of editing AppleIntelFramebufferCapri.kext. Since there's no lid wake problem after sleep in 0x0a26006, I think maybe the problem is located in the binary framebuffer data, I compare those two from 10.11.4 (15E56a), here's what I get the difference between 0x0a2e0008 and 0x0a260006:

[FONT=Times]08 00 2E 0A [/FONT][FONT=Times]01 03 03 03 00 00 00 04 00 00 20 02 [/FONT]
[FONT=Times]00 00 [COLOR=#e32400]5[/COLOR]0 0[COLOR=#e32400]1[/COLOR] 00 00 00 60 [COLOR=#b51a00]6C 05[/COLOR] 00 00    [/FONT]
[FONT=Times][COLOR=#e32400]6C 05[/COLOR] 00 00 00 00 00 00 00 00 00 00    backlight max 056C [/FONT]
[FONT=Times]00 00 08 00 02 00 00 00 30 00 00 00    eDP[/FONT]
[FONT=Times]01 05 09 00 00 04 00 00 [COLOR=#b51a00]0[/COLOR]7 0[COLOR=#e32400]1[/COLOR] 00 00    digital [/FONT]
[FONT=Times]02 04 0[COLOR=#e32400]A[/COLOR] 00 00 04 00 00 [COLOR=#e32400]0[/COLOR]7 0[COLOR=#ff4013]1[/COLOR] 00 00   unknown(digital) [/FONT]
[FONT=Times]FF 00 00 00 01 00 00 00 40 00 00 00   empty[/FONT]
[FONT=Times][COLOR=#ff4013]1E[/COLOR] 00 00 00 0[COLOR=#ff4013]5[/COLOR] 0[COLOR=#e32400]5[/COLOR] 0[COLOR=#ff4013]9[/COLOR] 0[COLOR=#ff4013]1[/COLOR] 0[COLOR=#ff4013]0[/COLOR] 00 00 00 [/FONT]
[FONT=Times][COLOR=#ff4013]32[/COLOR] 00 00 00 00 00 00 00 00 00 00 00 [/FONT]
[FONT=Times]0C 00 16 0A 01 03 03 03 00 00 00 04   [/FONT]
[FONT=Times]00 00 20 02 00                                        [/FONT]

[FONT=Times]06 00 26 0A[/FONT][FONT=Times]01 03 03 03 00 00 00 02 00 00 30 01 [/FONT]
[FONT=Times]00 00 [COLOR=#e32400]6[/COLOR]0 0[COLOR=#e32400]0[/COLOR] 00 00 00 60 [COLOR=#e32400]D9 0A[/COLOR] 00 00    [/FONT]
[FONT=Times][COLOR=#ff4013]D9 0A[/COLOR] 00 00 00 00 00 00 00 00 00 00  backlight max 0AD9 [/FONT]
[FONT=Times]00 00 08 00 02 00 00 00 30 00 00 00    eDP[/FONT]
[FONT=Times]01 05 09 00 00 04 00 00 [COLOR=#e32400]8[/COLOR]7 0[COLOR=#e32400]0[/COLOR] 00 00   digital [/FONT]
[FONT=Times]02 04 0[COLOR=#e32400]9[/COLOR] 00 00 04 00 00 [COLOR=#e32400]8[/COLOR]7 0[COLOR=#e32400]0[/COLOR] 00 00   digital [/FONT]
[FONT=Times]FF 00 00 00 01 00 00 00 40 00 00 00   [/FONT]
[FONT=Times][COLOR=#e32400]0F[/COLOR] 00 00 00 0[COLOR=#e32400]1[/COLOR] 0[COLOR=#ff4013]1[/COLOR] 0[COLOR=#ff4013]0[/COLOR] 0[COLOR=#ff4013]0[/COLOR] 0[COLOR=#ff4013]4[/COLOR] 00 00 00 [/FONT]
[FONT=Times][COLOR=#ff4013]00[/COLOR] 00 00 00 0E 00 00 00 00 00 00 00  [/FONT]
[FONT=Times]08 00 2E 0A 01 03 03 03 00 00 00 04 [/FONT]
[FONT=Times]00 00 20 02 00[/FONT]

And finally, I found what affect the lid wake problem comes from the byte 1E. And then, I remember you have the similar patch that is "Enable internal display after sleep for 0x0a2e000a, 0x0a26000a", same place, hence I guess this location has some other meaning, still have to explore. Anyway, thx!