Jump to content
6 posts in this topic

Recommended Posts

Hi!
There is a laptop:
HP Probook 4740s
CPU: i7-3632QM
RAM: 16 Gb
Graphics: Intel HD4000, 1600 x 900
Audio: IDT 92HD87B2/4
SDD: ADATA SU800 256 Gb
Ext. monitor (HDMI): Philips 223V, 1920x1080
 
OpenCore 0.5.7 with last driver and kext.
 
Installing Big Sur (masked as macbookpro11.1) from the installation flash drive.
It takes a very long time to install. Over 7 hours.
After installing it takes about 20 mins to boot and is very slow working.
The same situation when installing from the internet via the recovery.
 
Remove ssd from laptop and connect it via external usb.
Install to external drive.
Installation takes about 1.5 hours.
Booting in 1 minute.
Everything works: graphics, sound, network, hdmi.
Quick and stable. No problems.
 
Putting the ssd back in the notebook.
Booting 20 min, works very slowly. Same as after installing to internal disk.
 
In the boot log:
Couldn't alloc class "AppleIntelPchSeriesAHCI"
 
I think the problem is in the SATA driver Big Sur.
 
Here is what Dortania writes:
Certain SATA controllers dropped
For some reason, Apple removed the AppleIntelPchSeriesAHCI class from AppleAHCIPort.kext. Due to the outright removal of the class, trying to spoof to another ID (generally done by SATA-unsupported.kext) can fail for many and create instability for others.
A partial fix is to inject Catalina's version with any conflicting symbols being patched.
We recommend setting the MinKernel value to 20.0.0 for the kext CtlnaAHCIPort.kext to avoid any potential conflicts.
 
The install this kext didn't help.
The problem remains.
 
Any idea how to fix it?

Screenshot 2021-02-27 at 11.36.21.png

Some SSD (like older Intel SATA models) run dramatically slow when/if TRIM is enabled. You could check that out.

What about CPU power management; laptop may run very slow without it or if it's incorrectly set up.

 

The SATA controller matter you read about is more a cosmetic matter than an operational or performance one. Affected older SATA controllers and SATA disks still run perfectly under Big Sur.

 

If you want people to look deeper into your setup, please post a zipped copy of your bootloader EFI folder.

Your iGPU properties injection and patching look wrong to me:

iGPU_properties.jpg

 

HiRes Capri layout 0x01660004 only supports 1 x display/connector by default:

ID: 01660004, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 16 MB, MAX OVERALL: 17 MB (18354176 bytes)
Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz
Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1
[5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS
05030000 02000000 30020000

 1st connector is always con0 so you cannot patch connectors that don't exist like you did.

 

Your patch0 statements look Ok to convert HiRes layout from single port + 32MB stolen mem to 4 x port + 64MB stolen mem like the LoRes one but you can do that with properties injection instead; it's a lot simpler, just inject the same values for stolen memory, pipe count, port count and memory count as LoRes layout 01660003:

ID: 01660003, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB, MAX STOLEN: 32 MB, MAX OVERALL: 33 MB (34619392 bytes)
Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz
Mobile: 1, PipeCount: 2, PortCount: 4, FBMemoryCount: 2
[5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000407 - ConnectorDP
[3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP
[4] busId: 0x06, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP
05030000 02000000 30000000
02050000 00040000 07040000
03040000 00040000 81000000
04060000 00040000 81000000

You would therefore inject the following properties:

framebuffer-patch enable    1           NUMBER
framebuffer-fbstolenmem     00000004    DATA
framebuffer-pipecount       2           NUMBER
framebuffer-portcount       4           NUMBER
framebuffer-memorycount     2           NUMBER

All is explained in details in WEG user manual.

 

Then, what you need to do to add the other connectors is patch con0 with all the necessary data. You do that in a single statement with all the desired and relevant info for all subsequent connectors and without any further/subsequent connector patching (since there is absolutely no point of injecting data for con3 that you then modify!):

framebuffer-con0-enable    01000000    DATA
framebuffer-con0-alldata   050300000200000030020000020500000008000007040000030400000004000081000000040600000004000081000000    DATA

where:

05030000 02000000 30020000 are the 12bytes for vanilla connector con0 (unmodified)
02050000 00080000 07040000 are the 12bytes for new connector con1 (usually HDMI output, hence type 00080000)
03040000 00040000 81000000 are the 12bytes for new connector con2 (here set to DP type)
04060000 00040000 81000000 are the 12bytes for new connector con3 (here set to DP type)

Again, this is explained in details in the WEG user manual (see Custom Patching section).

 

The above properties injections will convert layout 01660004 from this default single connector arrangement:

04006601 01030101 00000002     // 1 x display output port
00000001 00000060 10070000
10070000 00000000 60290400
00000000 00000000 00000000
05030000 02000000 30020000     // LVDS port
00000000 01000000 40000000
00000000 01000000 40000000
00000000 01000000 40000000

to this 4 x connector arrangement:

04006601 01020402 00000004     // /!\ patch: 4 x display output port
00000001 00000060 10070000     // *** unmodified ***
10070000 00000000 60290400     // *** unmodified ***
00000000 00000000 00000000     // *** unmodified ***
05030000 02000000 30020000     // *** unmodified *** LVDS
02050000 00080000 07040000     // /!\ patch: HDMI (for audio)
03040000 00040000 81000000     // /!\ patch: DP/DVI
04060000 00040000 81000000     // /!\ patch: DP/DVI

 

If you want to inject HDMI type for con3, replace

04060000 00040000 81000000

by:

04060000 00080000 81000000

but there should be no need to replace anything else like you were trying to do.

 

 

You may then add a patch for the layout trail but it's probably not necessary so try without 1st:

framebuffer-patch0-enable           01000000    DATA
framebuffer-patch0-find             000000000000000000000000    DATA
framebuffer-patch0-replace          000000000002001100000000    DATA

 

On 3/2/2021 at 8:44 PM, Hervé said:

Your iGPU properties injection and patching look wrong to me:

iGPU_properties.jpg

 

HiRes Capri layout 0x01660004 only supports 1 x display/connector by default:


ID: 01660004, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 16 MB, MAX OVERALL: 17 MB (18354176 bytes)
Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz
Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1
[5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS
05030000 02000000 30020000

 1st connector is always con0 so you cannot patch connectors that don't exist like you did.

 

Your patch0 statements look Ok to convert HiRes layout from single port + 32MB stolen mem to 4 x port + 64MB stolen mem like the LoRes one but you can do that with properties injection instead; it's a lot simpler, just inject the same values for stolen memory, pipe count, port count and memory count as LoRes layout 01660003:


ID: 01660003, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000
TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB, MAX STOLEN: 32 MB, MAX OVERALL: 33 MB (34619392 bytes)
Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz
Mobile: 1, PipeCount: 2, PortCount: 4, FBMemoryCount: 2
[5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000407 - ConnectorDP
[3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP
[4] busId: 0x06, pipe: 0, type: 0x00000400, flags: 0x00000081 - ConnectorDP
05030000 02000000 30000000
02050000 00040000 07040000
03040000 00040000 81000000
04060000 00040000 81000000

You would therefore inject the following properties:


framebuffer-patch enable    1           NUMBER
framebuffer-fbstolenmem     00000004    DATA
framebuffer-pipecount       2           NUMBER
framebuffer-portcount       4           NUMBER
framebuffer-memorycount     2           NUMBER

All is explained in details in WEG user manual.

 

Then, what you need to do to add the other connectors is patch con0 with all the necessary data. You do that in a single statement with all the desired and relevant info for all subsequent connectors and without any further/subsequent connector patching (since there is absolutely no point of injecting data for con3 that you then modify!):


framebuffer-con0-enable    01000000    DATA
framebuffer-con0-alldata   050300000200000030020000020500000008000007040000030400000004000081000000040600000004000081000000    DATA

where:


05030000 02000000 30020000 are the 12bytes for vanilla connector con0 (unmodified)
02050000 00080000 07040000 are the 12bytes for new connector con1 (usually HDMI output, hence type 00080000)
03040000 00040000 81000000 are the 12bytes for new connector con2 (here set to DP type)
04060000 00040000 81000000 are the 12bytes for new connector con3 (here set to DP type)

Again, this is explained in details in the WEG user manual (see Custom Patching section).

 

The above properties injections will convert default layout 01660004 from this single connector arrangement:


04006601 01030101 00000002     // 1 x display output port
00000001 00000060 10070000
10070000 00000000 60290400
00000000 00000000 00000000
05030000 02000000 30020000     // LVDS port
00000000 01000000 40000000
00000000 01000000 40000000
00000000 01000000 40000000

to this 4 x connector arrangement:


04006601 01020402 00000004     // /!\ patch: 4 x display output port
00000001 00000060 10070000     // *** unmodified ***
10070000 00000000 60290400     // *** unmodified ***
00000000 00000000 00000000     // *** unmodified ***
05030000 02000000 30020000     // *** unmodified *** LVDS
02050000 00080000 07040000     // /!\ patch: HDMI (for audio)
03040000 00040000 81000000     // /!\ patch: DP/DVI
04060000 00040000 81000000     // /!\ patch: DP/DVI

 

If you want to inject HDMI type for con3, replace


04060000 00040000 81000000

by:


04060000 00080000 81000000

but there should be no need to replace anything else like you were trying to do.

 

 

You may then add a patch for the layout trail but it's probably not necessary so try without 1st:


framebuffer-patch0-enable           01000000    DATA
framebuffer-patch0-find             000000000000000000000000    DATA
framebuffer-patch0-replace          000000000002001100000000    DATA

 

 

 

Thanx!

But not work ((

 

(AppleIntelFramebufferCapri) Multi Planes are not supported for this config

(AppleIntelFramebufferCapri) Currently unsupported feature requested

(IOAcceleratorFamily2) bool IOAccelDisplayPipe::init_framebuffer_resource(IOAccelResource2 *): getPixelInformation for framebuffer 3 failed

(AppleIntelFramebufferCapri) Unsupported Extended capabilities type: 0x100

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...