Jump to content

Catalina install stuck on IOConsoleUsers: gIOScreenLockState


Stig710
 Share

13 posts in this topic

Recommended Posts

Prior to the Big Sur installation, Catalina worked for several years.
I extracted the version that Catalina had from the archive.
OpenCore version 0.6.7
When booting it stuck after creating a ram disks (˜24 disks).

The hardware is the same. Nothing was changed.

Link to comment
Share on other sites

Your issue certainly appears graphics related (failure to initialise).

 

Your iGPU properties injection could gain from being revised. You correctly use Capri layout 0x01660004 for HiRes built-in LCDs (1600x900 and above) but, then, you inject connector properties and patches in a manner rather cumbersome to me:

iGPU_properties.jpg

 

As you probably know, this HiRes Capri layout is single port (built-in LCD) by default so you need to add connectors in order to use additional video outputs such as DP or HDMI (1st connector con0 remaining unchanged).

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

This is usually done by mirroring the port/connector configuration of 4port LoRes layout 0x01660003:

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

i.e. by changing framebuffer settings such as port number, pipe number, etc. However, these can simply be directly injected rather than use the framebuffer patch facility of Whatevergreen kext and if you use the alldata form to patch connectors, you should not then add further patches for con3 as you did.

 

Then, you're missing the framebuffer memory patch that's normally required for HD4000 to avoid graphics glitches (reduce FBMem from 16MB to 8MB).

 

I would suggest you try the following properties instead:

AAPL,ig-platform-id        04006601                    DATA
framebuffer-patch-enable   1                           NUMBER
framebuffer-fbmem          00008000                    DATA     -> FBMem to 8MB (to avoid glitches)
framebuffer-stolenmem      00000004                    DATA     -> StolenMem to 64MB as per 4port layout 0x01660003
framebuffer-pipecount      2                           NUMBER   -> PipeCount to 2 as per 4port layout 0x01660003
framebuffer-portcount      4                           NUMBER   -> PortCount to 4 as per 4port layout 0x01660003
framebuffer-memorycount    2                           NUMBER   -> MemoryCount to 2 as per 4port layout 0x01660003
framebuffer-con1-enable    1                           NUMBER   -> enables patching/properties injection for 2nd connector con1
framebuffer-con1-alldata   020500000008000007040000    DATA     -> con1 properties (HDMI type)
framebuffer-con2-enable    1                           NUMBER   -> enables patching/properties injection for 3rd connector con2
framebuffer-con2-alldata   030400000004000081000000    DATA     -> con2 properties (DP type)
framebuffer-con3-enable    1                           NUMBER   -> enables patching/properties injection for 4th connector con3
framebuffer-con3-alldata   040600000004000081000000    DATA     -> con3 properties (DP type)

and, of course, all 3 x additional connectors can alternatively be defined in a single shot with:

framebuffer-con1-enable    1    NUMBER
framebuffer-con1-alldata   020500000008000007040000030400000004000081000000040600000004000081000000    DATA

 

See the WEG User Manual for details.

 

All this will of course be 100% re-usable in Big Sur which will require you to use the -no_compat_check boot arg if you keep unsupported Capri/HD4000 MBP9,2 SMBIOS (boot arg not required for Catalina).

  • Like 2
Link to comment
Share on other sites

Here comes the fun part.
Late at night, I fixed something in the config.
Oh, my goodness! It booted. I didn't install it, because it was already 1:00 in the morning.
Turned off the laptop.
I thought I would install it tomorrow after work.
But, in the morning was not able to boot from the same flash drive!
Stuck on vodoops2controller.
At night everything worked! What a mystery!
Cleaned the nvram.
Tried a few more times to boot - same result.
Hangs either on voodoo or after creating a series of ram disks.
What to do?

 

Link to comment
Share on other sites

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.

 Share

×
×
  • Create New...