Jump to content

Help to boot with Opencore


22 posts in this topic

Recommended Posts

Hi again my friends...

I want migrate to Opencore bootloader but I can't boot with it.
With clover I haven't any problem.
@MaLd0nor another member... I need help with Opencore bootloader.
Can anyone see my EFI Folder and test it please?
Tranks in advance...

 

EFI.zip

Edited by kali2000

Maldon or other users do not have a magic ball to recognize what hardware it is from what you have uploaded. You should be familiar with the forum rules, so enter your hardware specification in your signature

4 hours ago, spakk said:

Maldon or other users do not have a magic ball to recognize what hardware it is from what you have uploaded. You should be familiar with the forum rules, so enter your hardware specification in your signature

Sorry... I updated it...

1 hour ago, Hervé said:

@kali2000 Seriously! Please! Signature, not Interests! And avoid comments, just stick to main specs. When you post full specs, do so once, in your opening post. You've been a member for 8 years, so a bit of common sense would be appreciated and is expected...

I can't send a full report because I can't boot with OpenCore, also, when I try to boot with OpenCore, all my boots entries are erased from the BIOS and I have to reset my BIOS to recover them.

please also post your working clover EFI so that I have a comparison.  since I have not worked with your laptop I am unable to assist without a working boot loader to compare settings with.  as your system is a laptop, there may also be some configuration needed in the firmware.

 

HBP

Ok... Send me file are my files from Clover and EFI file are my OpenCore files.
Also, after update to 10.15.7, my laptop have a new issue with Clover. My laptop restart when exit from sleep.

I ned help to fix sleep issue and help to boot with OpenCore.

Thanks in avance.

EFI

Send me MacBook-Pro-de-Kali.zip

 

Edited by kali2000
6 hours ago, BALDY_MAN said:

I believe  Yosemite 10.10.4 (14E46). was the last time your GPU was supported in Mac OS

Forgives? Until 10.15.4 I have had full work with my HD 4600 iGPU (QE/CI & HDMI), but since then, not even directly patching the framebuffer from the kext, I have had any luck.
I'm out of the picture for some time and I thought that now with OpenCore there might have been a way.
However, thank you for your comment.

1 hour ago, kali2000 said:

Forgives? Until 10.15.4 I have had full work with my HD 4600 iGPU (QE/CI & HDMI), but since then, not even directly patching the framebuffer from the kext, I have had any luck.
I'm out of the picture for some time and I thought that now with OpenCore there might have been a way.
However, thank you for your comment.

I Did not mention your CPU built in graphics (iGPU) The GPU. Your GeForce 820M. Driver support up to.Yosemite 10.10.4 (14E46)

 

12 hours ago, BALDY_MAN said:

I Did not mention your CPU built in graphics (iGPU) The GPU. Your GeForce 820M. Driver support up to.Yosemite 10.10.4 (14E46)

 

GeForce 820M is Optimus technology, it was never supported.

 

So... If anyone can help me to fix my HDMI connection from HD 46000, he is welcome...
My old methods are not properly and I can't fix it.

Thanks in advance...

Edited by kali2000

I'm not sure referring to an old El Capitan thread is the best thing to do today for Catalina 10.15.7. If the principles related to the original patches have not changed much, Clover and OC today tend to concentrate on alternatives to kexts/kextcache binary patching such as device properties injection.

 

Anyway, looking at your debug stuff, you correctly fake desktop HD4600 id (0x0412), correctly use Azul framebuffer layout #12 (0x0A260006) but, imo, you probably use an inappropriate SMBIOS (MacBookPro11,3). MBP11,3 is a Crystalwell platform with dual-graphics (Intel Iris 5200 Pro + nVidia GeForce GT750M) and you should probably be using MacBookPro11,1 SMBIOS instead (Haswell platform with Iris 5100 graphics). My Haswell/HD4600 Hackintosh laptop was replaced a couple of years ago so I can't confirm this theory but using MBP11,3 may not be an issue at all.

 

Focusing on HD4600 HDMI output -which I believe is what you're trying to obtain today-, 1st identify your output port in IOReg then inject the following properties to your iGPU device @00020000 (i.e. PciRoot(0x0)/Pci(0x2,0x0)...) in your bootloader config. Refer to WhateverGreen's documentation for guidance.

 

Looking at Catalina's 10.15.7 (19H15) Azul framebuffer #12 through a Hex editor app such as HexFiend for instance, we see:

0600260A 01030303 00000002 00003001
00006000 00000060 D90A0000 D90A0000
00000000 00000000 00000800 02000000
30000000 01050900 00040000 87000000
02040900 00040000 87000000 FF000000
01000000 40000000 0F000000 01010000
04000000 00000000 0E000000 00000000

which we can decode as follows:

0600260A -> Framebuffer platform/layout id (Azul FB #12)
01030303 -> Mobile=Yes, PipeCount=3, PortCount=3, FBMemCount=3
00000002 -> StolenMem=32MB
00003001 -> FBMem=19MB
00006000 -> CusorMemSize=6MB
00000060 -> VRAM=1536MB
D90A0000 -> BacklightFreq=2777Hz
D90A0000 -> BacklightMaxFreq=2777Hz
00000000 00000000
00000800 02000000 30000000 -> output #1, FB@0 Port #0 (0000), Pipe 8 (0800), built-in screen LVDS (02000000), Flags 0x30 (30000000)
01050900 00040000 87000000 -> output #2, FB@1 Port #5 (0105), Pipe 9 (0900), external screen DP (00040000), Flags 0x87 (87000000)
02040900 00040000 87000000 -> output #3, FB@2 Port #6 (0204), Pipe 9 (0900), external screen DP (00040000), Flags 0x87 (87000000)
FF000000 01000000 40000000 0F000000 01010000
04000000 00000000 0E000000 00000000

 

This has been detailed in various places for many years and I recommend Pike R Alpha's old blog entry on the matter; it makes for a most excellent and thorough reading:

https://pikeralpha.wordpress.com/2014/09/05/preview-of-appleintelframebufferazul-sh-v3-0/

 

By far and large, in most cases, HDMI port registers against FB@1 and getting full support for HDMI output just requires 2 x things:

  1. replace 01050900 by 01051200 (Pipe 0x09 to Pipe 0x12) to avoid freeze on HDMI hot plugging/unplugging
  2. replace 00040000 by 00080000 (DP connector-type to HDMI connector-type) and this is actually for HDMI audio

so, apart from the aforementioned requirements for mobile HD4600, i.e.:

device-id -> 12040000 (type DATA) to fake desktop HD4600 iGPU id
AAPL,ig-platform-id -> 0600260A (type DATA) to select mobile Azul FB #12
framebuffer-patch-enable -> 1 (type NUMBER) to enable framebuffer patching
framebuffer-cursormem -> 00009000 (type DATA) to patch Cursor Memory Size from 6MB to 9MB (optional, only if you experience glitches)
+
disable-external-gpu -> 1 (type NUMBER) to disable nVidia dGPU (you may use a specific SSDT to ensure dGPU is powered off)

all you should basically need in terms of properties for HDMI output with your HD4600 iGPU@2 is as follows:

framebuffer-con1-enable -> 1 (Type NUMBER) to enable connector (i.e. output port) patching
framebuffer-con1-type -> 00080000 (type DATA) to set connector-type to HDMI
framebuffer-con1-pipe -> 12000000 (type DATA) to set Pipe to 0x12 (though I'm not 100% sure about that one...)

Of course, if your HDMI port does not attach to FB@1 but FB@2 (there are only 3 x output ports in Azul FB #12), replace con1 by con2 in the above properties injection.

 

Looking at your OC config, I see this:

iGPU_properties_inj.jpg

 

and I'm tempted to say that these are totally wrong:

#1.jpg

#2.jpg

#3.jpg

  1. Afaik, conX-alldata applies to the selected connector (i.e. output port) only, not all of them. As such, con0-alldata can only apply to the port attached to FB@0, i.e. the built-in screen port index/number/pipe + connector-type + flags (activation delay), not all 3 x connectors/ports of the framebuffer platform/layout. Your entire injection in that respect is therefore entirely incorrect. If you refer to WEG's documentation, you'll see such patch is limited to 12 bytes. In addition, changing the pipe value of the built-in screen looks not only unnecessary but totally wrong to me.
  2. If you look at my above explanations and either WEG documention or Hackintool to that effect, it looks like you mixed things up between StolenMemFBMem and CursorMem. You may patch cursor memory size to 9MB though it's not always necessary (only if you experience glitches). As for StolenMem + FBMem, there's absolutely no need to patch those for mobile HD4600. What you seem to have actually applied is the config usually applied to Broadwell HD5500 graphics but that never applies to HD4600.
  3. As a general rule, FBMem + CursorMem must total less than StolenMem (DVMT) but, outside the CursoMem patch to 9MB, one does not usually change StolenMem on a HD4600 laptop, yet you reduce this to 19MB. I'm pretty certain that's what causes the KP and bootloops you experience.
  4. On the other hand, your property injection to increase VRAM to 2GB is correct.
  5. hda-gfx injection arguably not necessary given that it's already injected through a DSDT patch.

I would suggest you remove all those entries from (and including) enable-hdmi20 to (and including) framebuffer-stolenmem and, in their stead, inject the reduced properties set I listed above.

 

i've not experimented this but alternatives to the HDMI properties injection I listed above may be:

framebuffer-con1-enable -> 1 (Type NUMBER)
framebuffer-con1-all-data -> 010512000008000087010000 (type DATA)
                                 /\    /\

or the more traditional binary patching with features detailed in WEG's documentation linked above (framebuffer-patchN-...) but this may be considered less elegant and less efficient.

 

Oh and remove all those FakePCIID kexts, they're totally unnecessary these days and may even cause issues. It's all covered by your OC config + Lilu & WEG PlugIn now.

 

Good tuning!

@HervéThanks a lot off for your reply.
I write a new device property with no luck to fix my HDMI.

105 & 204 ports, reboots my laptop when connect my HDMI, only with 306 port not reboot, but I don't have response nor of image and not audio.

I run out of ideas.

Could there be something in my DSDT that is preventing the HDMI patch?

See my files again please...

2129481773_Capturadepantalla2020-11-11alas1_41_58.png.a7a115d47390bda59ad0ac886d4085bf.png

Send me MacBook-Pro-de-Kali.zip

You're still not doing it right despite my efforts to explain things in details...

 

If you use the con1-alldata, obviously you don't need to inject properties for connector's pipe and type! So do either/or not both. Obviously, no need to waste your time with connector/port 0306, it's irrelevant. I'm pretty sure your HDMI port with be on the 2nd connector 0105. Try this and this only:

device-id                    12040000                 DATA
AAPL,ig-platform-id          0600260A                 DATA
framebuffer-patch-enable     1                        NUMBER (or 01000000 DATA)
framebuffer-con1-enable      1                        NUMBER (or 01000000 DATA)
framebuffer-con1-alldata     010512000008000087000000 DATA

If that does not work, try this and this only:

device-id                    12040000                 DATA
AAPL,ig-platform-id          0600260A                 DATA
framebuffer-patch-enable     1                        NUMBER (or 01000000 DATA)
framebuffer-con2-enable      1                        NUMBER (or 01000000 DATA)
framebuffer-con2-alldata     020412000008000087000000 DATA

 

I must admit that I don't understand this reported behaviour. I've had a look at the last debug info you posted. I cannot seen anything wrong with your config and on looking at the text IOReg output (a proper .ioreg file from IORegistryExplorer app would be a millions times better though), I can clearly see the injected device id, ig-platform-id, and the connector's property, including HDMI connector type registered under FB@1.

 

Something odd nevertheless: same IOReg output shows "AAPL,slot-name" parameter set to "Airport" under IGPU device!!! I can't understand this, nor see where this would come from. I checked your DSDT and all I see with regards to Airport is a patch in the form of a _DSM method to inject properties for a wireless card under RP06.PXSX ACPI device:

                    Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
                    {
                        If (LEqual (Arg2, Zero))
                        {
                            Return (Buffer (One)
                            {
                                 0x03                                           
                            })
                        }

                        Return (Package (0x0C)
                        {
                            "AAPL,slot-name", 
                            "Built In", 
                            "built-in", 
                            Buffer (One)
                            {
                                 0x00                                           
                            }, 

                            "model", 
                            Buffer (0x2A)
                            {
                                "Broadcom BCM43xx Wireless Network Adapter"
                            }, 

                            "name", 
                            Buffer (0x13)
                            {
                                "AirPort Controller"
                            }, 

                            "device_type", 
                            Buffer (0x10)
                            {
                                "AirPort Extreme"
                            }, 

                            "empty", 
                            Zero
                        })
                    }

It all looks Ok to me but I've never seen this "empty" property ever before. What on earth is this for? I would recommend you try and remove it.

 

I'd also try an NVRAM reset when you reboot OpenCore but maybe you already do that after you change your config. Afaik, it's necessary.

 

Outside offering a binary pre-patched kext, that's all I can offer, sorry; for the rest it beats me.

Patched_AppleIntelFramebufferAzul.kext.zip

* up'ed to v914.7.8

* patched for CursorMem 9MB, VRAM 2048MB and connector 0105 to pipe 0x12 + connector-type to HDMI 00080000

* try to cache from /L/E

×
×
  • Create New...