RehabMan
Moderator
- Joined
- May 2, 2012
- Messages
- 181,006
- Motherboard
- Intel DH67BL
- CPU
- i7-2600K
- Graphics
- HD 3000
- Mac
- Mobile Phone
[Guide] Lenovo Y50
Just so you know, not all the framebuffer data is understood.
For example on the HD4000 we commonly need to use 0x1660004 for displays that are dual-link (usually high resolution displays). And we use 0x1660003 for displays that are single link (usually lower resolution displays).
But if you look at 0x01660003 and 0x01660004 you discover that 0003 uses 64MB for BIOS memory, where 0004 uses 32MB for BIOS memory. Clearly a display with less resolution would not need more BIOS memory than a display with more resolution. And it seems also unlikely that BIOS would change the allocation (especially smaller) upon replacing a low resolution screen with a higher resolution screen. One would think the BIOS allocation is fixed and does not depend on the screen that is connected.
And yet we have this situation that 0004 works with dual-link and 0003 does not. It must be some other data.
Being curious, I decided to take a look at it. Besides many other differences in the connector data (01660004 has no external connections), the connector data for LVDS is slightly different:
01660003: 05030000 02000000 30000000
01660004: 05030000 02000000 30020000
Note that the only difference is the '02' instead of '00'. On the hunch that this difference is what makes the connector dual-link, I changed my 4540s configuration (it has 1080p upgraded screen) to use 01660003 instead of the usual 01660004 by using a Clover patch (and injecting ig-platform-id = 01660003). The patch is this:
Name: AppleIntelFramebufferCapri
Find: 05030000 02000000 30000000
Repl: 05030000 02000000 30020000
The find pattern is unique enough to find only the LVDS connector data in the 01660003 framebuffer config.
And... it works. I was able to sucessfully boot with 01660003 injection with this patch and it confirms that the data where we changed 0 to 2 has something to do with dual-link LVDS displays. At least as far as HD4000/Capri is concerned.
I post this here, just to give you an idea of the type of reverse engineering required here.
I still find it interesting that this machine will work with either a 32mb or 64mb BIOS memory, a data value that is often believed to need an exact match.
Just so you know, not all the framebuffer data is understood.
For example on the HD4000 we commonly need to use 0x1660004 for displays that are dual-link (usually high resolution displays). And we use 0x1660003 for displays that are single link (usually lower resolution displays).
But if you look at 0x01660003 and 0x01660004 you discover that 0003 uses 64MB for BIOS memory, where 0004 uses 32MB for BIOS memory. Clearly a display with less resolution would not need more BIOS memory than a display with more resolution. And it seems also unlikely that BIOS would change the allocation (especially smaller) upon replacing a low resolution screen with a higher resolution screen. One would think the BIOS allocation is fixed and does not depend on the screen that is connected.
And yet we have this situation that 0004 works with dual-link and 0003 does not. It must be some other data.
Being curious, I decided to take a look at it. Besides many other differences in the connector data (01660004 has no external connections), the connector data for LVDS is slightly different:
01660003: 05030000 02000000 30000000
01660004: 05030000 02000000 30020000
Note that the only difference is the '02' instead of '00'. On the hunch that this difference is what makes the connector dual-link, I changed my 4540s configuration (it has 1080p upgraded screen) to use 01660003 instead of the usual 01660004 by using a Clover patch (and injecting ig-platform-id = 01660003). The patch is this:
Name: AppleIntelFramebufferCapri
Find: 05030000 02000000 30000000
Repl: 05030000 02000000 30020000
The find pattern is unique enough to find only the LVDS connector data in the 01660003 framebuffer config.
And... it works. I was able to sucessfully boot with 01660003 injection with this patch and it confirms that the data where we changed 0 to 2 has something to do with dual-link LVDS displays. At least as far as HD4000/Capri is concerned.
I post this here, just to give you an idea of the type of reverse engineering required here.
I still find it interesting that this machine will work with either a 32mb or 64mb BIOS memory, a data value that is often believed to need an exact match.