Contribute
Register

[Guide] Alternative to the minStolenSize patch with 32mb DVMT-prealloc

headkaze said:
Yeah the data is no longer in nice structs so it's going to be more difficult to support. Unfortunately I don't think I will be able to update FB-Patcher to support Mojave.
Click to expand...

There is evidence to suggest it builds the ig-platform table dynamically, but it is still the same otherwise. For example there are loops that go through the table and still assume it is 184 bytes. If it was dramatically changed, such loops would not likely still be using 184 byte increment.

But patching it will likely require a Lilu based solution. There was a commit in IntelGraphicsFixup that claimed to add a dumper, likely a start on this.
 
RehabMan said:
There is evidence to suggest it builds the ig-platform table dynamically, but it is still the same otherwise. For example there are loops that go through the table and still assume it is 184 bytes. If it was dramatically changed, such loops would not likely still be using 184 byte increment.

But patching it will likely require a Lilu based solution. There was a commit in IntelGraphicsFixup that claimed to add a dumper, likely a start on this.
Click to expand...

Yeah in memory the framebuffer structs are basically the same with a couple of slight offset differences (Eg. Framebuffer flags are at offset 0x61 instead of 0x60 now). Instead of the framebuffer data being read directly from structs it's read into them in __GLOBAL__sub_I_AppleIntelOSInfoList_cpp (which is part of the code in my previously attached image).

Yes it looks like Lilu will be the best way to patch it now although after some thought I think I can add support to FB-Patcher it will just be a bit of work.
 
RehabMan said:
But patching it will likely require a Lilu based solution.
Click to expand...

I contacted vit9696 and showed him my info on Mojave and he came up with an idea for a Lilu based solution and I've been working through implementing it. So the good news is I have something working now.

So the future of framebuffer patching is going to be using Lilu + WhateverGreen which is going to support AMD, Intel and nVidia patching and will include other patches like CoreDisplayFixup. It's going to be an all-in-one solution.

The way to patch framebuffers will be using SSDT patching or Devices->Properties Clover patching.

Eg. 0x591b0000, 32MB BIOS, 19MB stolenmem (framebuffer) 9MB fbmem (cursor)

Code: 
<key>Devices</key>
<dict>
    <key>Properties</key>
    <dict>
        <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
        <dict>
            <key>framebuffer-patch-enable</key>
            <integer>1</integer>
            <key>framebuffer-stolenmem</key>
            <integer>0x01300000</integer>
            <key>framebuffer-fbmem</key>
            <integer>0x00900000</integer>
        </dict>
    </dict>
</dict>

You can include framebuffer-framebufferid and framebuffer-patch0-framebufferid respectively to patch a particular framebuffer address Eg. 0x59120000 or 0x591B0000 otherwise the kext will detect and use your current one.

This will be the only practical and reliable way to patch framebuffers with Mojave and above.
 
Last edited:
headkaze said:
I contacted vit9696 and showed him my info on Mojave and he came up with an idea for a Lilu based solution and I've been working through implementing it. So the good news is I have something working now.

So the future of framebuffer patching is going to be using Lilu + WhateverGreen which is going to support AMD, Intel and nVidia patching. Also it will likely include other patches like CoreDisplayFixup. It's going to be an all-in-one solution.

The way to patch framebuffers will be using SSDT patching or Devices->Properties Clover patching.

Eg. 0x591b0000, 32MB BIOS, 19MB stolenmem (framebuffer) 9MB fbmem (cursor)

Code: 
<key>Devices</key>
<dict>
    <key>Properties</key>
    <dict>
        <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
        <dict>
            <key>framebuffer-stolenmem</key>
            <integer>0x01300000</integer>
            <key>framebuffer-fbmem</key>
            <integer>0x00900000</integer>
        </dict>
    </dict>
</dict>

You can include framebuffer-framebufferid and framebuffer-patch0-framebufferid respectively to patch a particular framebuffer address Eg. 0x59120000 or 0x591B0000 otherwise the kext will detect and use your current one.

This will be the only practical and reliable way to patch framebuffers with Mojave and above.
Click to expand...

That's what I expected to happen... glad you have the time to implement it.

Better to use config.plist/Devices/AddProperties instead of config.plist/Devices/Properties.
Using Devices/AddProperties disables all normal Clover injection methods (eg. disables Graphics/Inject, Devices/USB/Inject, etc).
 
RehabMan said:
That's what I expected to happen... glad you have the time to implement it.

Better to use config.plist/Devices/AddProperties instead of config.plist/Devices/Properties.
Using Devices/AddProperties disables all normal Clover injection methods (eg. disables Graphics/Inject, Devices/USB/Inject, etc).
Click to expand...

I've pretty much finished implementing it now so it should hopefully be merged into WhateverGreen soon. I also installed Mojave on my desktop and can confirm the patching is working on it.
 
Great job headkaze i m waiting for your patch for mojave and i suggest merge with Intelgraphicfixup.kext instead of whatevergreen.kext because whatevergreen is for Nvidea and AMD and intelgraphicfixup is only for intel graphics
 
anmool said:
Great job headkaze i m waiting for your patch for mojave and i suggest merge with Intelgraphicfixup.kext instead of whatevergreen.kext because whatevergreen is for Nvidea and AMD and intelgraphicfixup is only for intel graphics
Click to expand...

IntelGraphicsFixup.kext has been merged into WhateverGreen.kext so Intel users will no longer be using IntelGraphicsFixup.kext going forward. As I said it's going to be an all-in-one solution for all video hardware.
 
Good idea for all in one solution when will be availabe
 
anmool said:
Good idea for all in one solution when will be availabe
Click to expand...

Very close actually. Just ironing out some issues mainly with the way Clover reads certain data types from config.plist. Once that's sorted I will make a post about it.
 
headkaze said:
I contacted vit9696 and showed him my info on Mojave and he came up with an idea for a Lilu based solution and I've been working through implementing it. So the good news is I have something working now.

So the future of framebuffer patching is going to be using Lilu + WhateverGreen which is going to support AMD, Intel and nVidia patching and will include other patches like CoreDisplayFixup. It's going to be an all-in-one solution.

The way to patch framebuffers will be using SSDT patching or Devices->Properties Clover patching.

Eg. 0x591b0000, 32MB BIOS, 19MB stolenmem (framebuffer) 9MB fbmem (cursor)

Code: 
<key>Devices</key>
<dict>
    <key>Properties</key>
    <dict>
        <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
        <dict>
            <key>framebuffer-patch-enable</key>
            <integer>1</integer>
            <key>framebuffer-stolenmem</key>
            <integer>0x01300000</integer>
            <key>framebuffer-fbmem</key>
            <integer>0x00900000</integer>
        </dict>
    </dict>
</dict>

You can include framebuffer-framebufferid and framebuffer-patch0-framebufferid respectively to patch a particular framebuffer address Eg. 0x59120000 or 0x591B0000 otherwise the kext will detect and use your current one.

This will be the only practical and reliable way to patch framebuffers with Mojave and above.
Click to expand...
Hi,
headkaze said:
Very close actually. Just ironing out some issues mainly with the way Clover reads certain data types from config.plist. Once that's sorted I will make a post about it.
Click to expand...
Hi,
Can you check please what I need to find for 10.14.D3 in my AppleIntelSKLGraphicsFramebuffer (Dev. Beta 3).
My card is Intel hd 540 UHD 4K with 0x19260004 and my DVMT in BIOS 64MB. I need 128 or 192 MB.

Here is the code:
04002619 488D35F8 17020048 89354C27 08004488 154D2708 0041B401 44883544 27080044 88353E27 08004488 35382708 00B90000 2002890D 2E270800 89052C27 08004489 0D292708 00B96C05 0000890D 22270800 890D2027 08004889 051D2708 00488B0D 56700100 48890D3F 27080048 8B0D4070 01004889 0D292708 00488B0D 2A700100 48890D13 27080048 8B0D1470 01004889 0DFD2608 00488B0D FE6F0100 48890DE7 26080048 8B0DE86F 01004889 0DD12608 00C705F7 2608000A 0B030088 05F52608 0041B307 44881DEC 26080041 B0064488 05E32608 00B90300 0000890D DA260800 891DD826 0800BB80 DF171089 1DD12608 008905CF 26080041 B9780500 0044890D C6260800 41BDD205 00004489 2DBD2608 00BA4006 00008915 B6260800 8905B426 08008905 B2260800 488D3D73 CA070048 893DAC26 0800488D 0D15CB07 0048890D A6260800 48890DA7 26080041 BA020000 00448915 A2260800 41BF0800 00004489 3D992608 00890597 260800C7 05952608 00040027 19488935 96260800 44882597 26080044 88359126 08004488 358B2608 00448835 85260800 41BC0000 90034489 25792608 00890577 260800BE 00000060 89357026 080041BC 6C050000 44892567 26080044 89256426 08004889 05612608 004C8B25 126F0100 4C892583 26080048 8B35FC6E 01004889 356D2608 00488B35 E66E0100 48893557 26080048 8B35D06E 01004889 35412608 00488B35 BA6E0100 4889352B 26080048 8B35
I cannot make FB Patcher working, because it cannot define the Address field, it is empty.
Thanks a lot
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top