Jump to content
Followers 0
McSonite

HP EliteOne 800 G1 Built-in display black screen (Catalina)

12 posts in this topic

Recommended Posts

I have done a lot of WEG patching in this case but whatever (<- :) ) I do the built-in display stays black. I would appreciate if I got some help with this issue. @Hervé suggested that I should concentrate my efforts on con2 because it seems to be the FB for the built-in display. I have done this and more and now I'm out of ideas.

 

Only way I'm getting this PC to start to the OS is to use framebuffer layout 0D220003 and when I do this the only way to access it is to connect with VNC or attach an external display with DP cable to the additional DP port on the PC after the built-in display has gone black.

 

If I try to start the PC with display connected to DP the boot halts to a point where it says: Adding AGDP mode validate property. This happens also if I try to boot the PC with other Haswell Desktop ig-platform-ids.

 

This is what I have interpreted from the IOreg:

 

FB@0 = port 5

FB@1 = port 6 (this is where the external display connects to with DP cable)

FB@2 = port 0

 

The things I have done with the FB@2 are:

 

framebuffer-patch-enable    01000000                    DATA
framebuffer-con0-enable     01000000                    DATA
framebuffer-con0-busid      00000000                    DATA
framebuffer-con1-enable     01000000                    DATA
framebuffer-con1-busid      00000000                    DATA
framebuffer-con2-enable     01000000                    DATA
framebuffer-con2-type       02000000                    DATA
framebuffer-con2-busid      01000000                    DATA 
framebuffer-patch-enable    01000000                    DATA
framebuffer-con0-enable     01000000                    DATA
framebuffer-con0-busid      00000000                    DATA
framebuffer-con1-enable     01000000                    DATA
framebuffer-con1-busid      00000000                    DATA
framebuffer-con2-enable     01000000                    DATA
framebuffer-con2-type       02000000                    DATA
framebuffer-con2-busid      02000000                    DATA

and so forth for all the busids from 1-6 and with connector type LVDS. Idea for setting the con0 and con1 busid to 0 is to avoid them to clash with con2 busid.

 

framebuffer-patch-enable    01000000                    DATA
framebuffer-con0-enable     01000000                    DATA
framebuffer-con0-busid      00000000                    DATA
framebuffer-con1-enable     01000000                    DATA
framebuffer-con1-busid      00000000                    DATA
framebuffer-con2-enable     01000000                    DATA
framebuffer-con2-type       00040000                    DATA
framebuffer-con2-busid      01000000                    DATA 
framebuffer-patch-enable    01000000                    DATA
framebuffer-con0-enable     01000000                    DATA
framebuffer-con0-busid      00000000                    DATA
framebuffer-con1-enable     01000000                    DATA
framebuffer-con1-busid      00000000                    DATA
framebuffer-con2-enable     01000000                    DATA
framebuffer-con2-type       00040000                    DATA
framebuffer-con2-busid      02000000                    DATA

and so forth for all the busids from 1-6 and with connector type DP. 

 

I have also tested with boot-args: agdpmod=pikera, agdpmod=vit9696 and without these arguments. (Only one argument at a time)

 

One thing with this PC is that I don't know if this built-in display is LVDS or eDP type. BIOS suggests that it is LVDS, service manual refers to LVDS cable as spare part but Windows Intel HDA manager tells me that it is an eDP connector.

 

This might be a tough nut to crack or maybe not to you gurus out there.

Share this post

OMG! You need to read the WhateverGreen manual to try and understand how framebuffer layouts are constructed. One just does not go and reassign indexes and BusIds the way you did...

 

macOS defines Azul FB 0x0d22003 as follows:

0300220D 00030303 00000002 00003001
00000000 00000060 99140000 99140000
00000000 00000000 01050900 00040000
87000000 02040A00 00040000 87000000
03060800 00040000 11000000 FF000000
01000000 40000000 020C0000 01010000
04000000 00000000 0E000000 00000000

i.e.

0300220D -> Azul layout id
00030303 -> Mobile=00 (false), PipeCount=03, PortCount=03, FBMemoryCount=03
00000002 -> StolenMem=32MB
00003001 -> FB Memory size=19MB
00000000 -> FB Cursor size=0
00000060 -> VRAM=1536MB
99140000 -> Freq=5273Hz
99140000 -> Max Freq=5273Hz
00000000 00000000
01050900 00040000 87000000 -> FB@0 (con0), BusId=05 (Port 5), Pipe=9 (0900), Type=DP (00040000)
02040A00 00040000 87000000 -> FB@1 (con1), BusId=04 (Port 6), Pipe=10 (0A00), Type=DP (00040000)
03060800 00040000 11000000 -> FB@2 (con2), BusId=06 (Port 7), Pipe=8 (0800), Type=DP (00040000)
FF000000 01000000 40000000
020C0000 01010000 04000000
00000000 0E000000 00000000

which translates to (see WEG manual and/or Hackintool):

ID: 0D220003, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x00000402
TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes)
Camellia: CamelliaDisabled (0), Freq: 5273 Hz, FreqMax: 5273 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000087 - ConnectorDP
[3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x00000011 - ConnectorDP
01050900 00040000 87000000
02040A00 00040000 87000000
03060800 00040000 11000000

and you need to understand that, in Haswell Azul framebuffer kext, output ports (i.e. connectors) tend to follow the trend below when there is an LVDS/eDP screen:

  • 0000 -> con0 (FB@0), BusId 00 (port 0) -> LVDS/eDP built-in LCD normally goes there
  • 0105 -> con1 (FB@1), BusId 05 (port 5) -> HDMI output often goes there
  • 0204 -> con2 (FB@2), BusId 04 (port 6) -> DP output usually goes there
  • 0306 -> con3 (FB@3), BusId 06 (port 7) -> DP output usually goes there

 

Connect to your hack through VNC (screen sharing), leave DP external display disconnected and take an IOreg extract from IORegistryExplorer app. Zip it and post it here.

 

Basically, we need to try and identify if your built-in screen registers at all and, if it does, where. We can then either look at changing the connector type of the port or convert your layout from 3 output ports to 4 by redefining PortCount + the connectors, i.e. change layout 0x0d220003 to ressemble 4-port layout 0x0D26000E:

ID: 0D26000E, STOLEN: 96 MB, FBMEM: 34 MB, VRAM: 1536 MB, Flags: 0x0000031E
TOTAL STOLEN: 131 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 323 MB, MAX OVERALL: 324 MB (340279296 bytes)
Camellia: CamelliaV2 (2), Freq: 1953 Hz, FreqMax: 1953 Hz
Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS
[1] busId: 0x05, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[2] busId: 0x04, pipe: 11, type: 0x00000400, flags: 0x00000107 - ConnectorDP
[3] busId: 0x06, pipe: 3, type: 0x00000800, flags: 0x00000006 - ConnectorHDMI
00000800 02000000 30000000
01050B00 00040000 07010000
02040B00 00040000 07010000
03060300 00080000 06000000

 

For instance you could inject the following properties:

framebuffer-patch-enable 01000000 DATA
framebuffer-portcount    4        NUMBER
framebuffer-con0-enable  1        NUMBER
framebuffer-con0-alldata 00000800020000003000000001050900000400008700000002040A000004000087000000030608000004000011000000 DATA

to define 4 x ports in a single shot,

framebuffer-con0-alldata 00000800 02000000 30000000 01050900 00040000 87000000 02040A00 00040000 87000000 03060800 00040000 11000000 DATA

basically injecting the following output port characteristics:

00000800 02000000 30000000 -> FB@0 (con0), BusId=00 (port 0), Pipe=8 (0800), Type=LVDS (02000000)
01050900 00040000 87000000 -> FB@1 (con1), BusId=05 (Port 5), Pipe=9 (0900), Type=DP (00040000)
02040A00 00040000 87000000 -> FB@2 (con2), BusId=04 (Port 6), Pipe=10 (0A00), Type=DP (00040000)
03060800 00040000 11000000 -> FB@3 (con3), BusId=06 (Port 7), Pipe=8 (0800), Type=DP (00040000)

 

But all this is just theoretical until we see your IOReg output. 

Share this post

I have now injected the parameters you, @Hervégave above (for testing purposes). Now there is another connector FB@3 and the port number for that is 0x0. Port number for FB@0 is also 0x0.

 

I have attached the IOreg from this setup.

 

Do you have ideas which FB is for the in-built display and what to test as parametrs for it? This help would be greatly appreciated.

ioreg_20201213.zip

Share this post

I'm going to ignore that last IOReg labelled 20201213.

 

Looking at the IOReg labelled 20201212, you may have noticed the following:

  1. no display listed under any of the 3 x connectors
  2. FB@0, port 5, pipe FFFF, type HDMI
  3. FB@1, port 6, pipe FFFF, type HDMI
  4. FB@2, port 0, pipe FFFF, type HDMI, boot display

so clearly not the native/vanilla characteristics of Azul FB 0x0d220003. Of course, it would have been of great help if you'd attached your config file too so that we'd know what you had injected but...

 

Given what we see for FB@2, i.e. boot display, it'd be fair to assume this is your built-in screen. I therefore suggest you concentrate your efforts on that connector. For instance, you could set its connector-type to LVDS (and nothing else!):

framebuffer-con2-enable    1           NUMBER
framebuffer-con2-type      02000000    DATA

 

Boot with arg agdpmod=pikera to bypass possible display restrictions imposed natively by AGDP.

 

You currently use iMac14,1 SMBIOS, you may also experiment with iMac14,4 SMBIOS.

Share this post

Thanks again for your answer. I noticed that there is no display under con2 and now I actually also found the parameter that says the con2 display is the boot display (AAPL,boot-display = True). Con2 is now set to type LVDS but unfortunately situation with the in-built display remains the same.

 

Just to check this boot argument agdp=pikera ... Is it like this? I have been using agdpmod=pikera

 

I have also earlier experimented with SMBIOS 14,4 and when running that SMBIOS and if a display is connected to the additional DP connector then the graphics get glitchy. With SMBIOS 14,4 the in-built display ... blackened.

 

Do you have any ideas what to do next? Or is this a lost cause?

 

I attached current config.plist and IOreg. 

config.plist.zip

ioreg.zip

Share this post

Boot arg is indeed agdpmod=pikera, sorry for my earlier typo (corrected in the post).

 

22 hours ago, McSonite said:

With SMBIOS 14,4 the in-built display ... blackened.

What do you mean by that? "blackened"? What difference compared to using iMac14,1 ? Did you take an IOReg extract then?

 

Did you try to inject your screen's EDID by the way?

Share this post

I was trying to be funny and refer to one great metal band's song by using the word blackened :D. What I meant was that the situation was the same and in-built display still has a black screen.

 

Strangely enough with SMBIOS 14,1 all connectors seem somehow change to HDMI (0008000). If I use boot-arg -igfxnohdmi then they are as the layout defines them - that is all DP. With SMBIOS 14,4 there is no need to use boot-arg -igfxnohdmi and the connector types are as they should. 

 

Actually I took IOreg extract with SMBIOS 14,4 now. I have attached it here. Also config.plist uploaded.

 

I have once tried to inject the EDID with: AAPL00,override-no-connect | DATA | EDID (EDID being the actual edid of the display, extracted w/ Linux)

 

How is the AAPL0defined? Should I use AAPL00, AAPL01 or AAPL02? 

 

 

ioreg 3.zip

config.plist.zip

Edited by McSonite
commented edid
Share this post

Thank you for being so kind and giving me help @Hervé. I have read loads of information about WEG patching and some of these guides have been written by you. I have tried almost everything that I have found under different Hackintosh sites but none of these guides have helped me out to get the display to register.

 

When I started this project I though that this might have something to do with fbmem, stolenmem and stuff like that but now I have learned that it didn't. Then I tried to change the indexes by using WEG patching but I also learned that you cannot do that. I also tried the busID patching following the guide by Dortania and that also left me out cold (went through all the possible iterations) . Somethings that I haven't played so much with are the pipe and flags settings - maybe that is something to look into. 

 

I'm trying to set this computer up as a Christmas present for my daughter so if anyone has anything that I could possibly try with this PC to get the in-built screen to work then that would be more than greatly appreciated.

Share this post

I have now generated a new EDID by reading https://github.com/acidanthera/WhateverGreen/blob/master/Manual/edid-gen.sh

 

I don't have the display.plist because the display is never attached to the framebuffer so I had to get creative. I just edited the EDID with the parameters that the script would do.

 

My guess is black screen but let's see. 

Share this post

I guessed right (all iterations AAPL00,..01,..02, override-no-connect, override-no-edid,.. connector types LVDS & DP) . Thank you, good bye. It's Linux for this PC then.

 

 

1 hour ago, McSonite said:

I have now generated a new EDID by reading https://github.com/acidanthera/WhateverGreen/blob/master/Manual/edid-gen.sh

 

I don't have the display.plist because the display is never attached to the framebuffer so I had to get creative. I just edited the EDID with the parameters that the script would do.

 

My guess is black screen but let's see. 

 

Original EDID

 

00FFFFFFFFFFFF0022F08910010000001517010380331D780AA040A656529D2710505400000001010101010101010101010101010101193880007138144060408400FE1F11000078000000FE005630370A202020202020202020000000FC00485051203830302041494F0A20000000FE004C4D3233305746332D534C4C3100A0

 

Edited EDID

 

00FFFFFFFFFFFF0022F08910010000001517010409331D780AA040A656529D2710505400000001010101010101010101010101010101193880007138144060408400FE1F11000078000000FE005630370A202020202020202020000000FC00485051203830302041494F0A20000000FE004C4D3233305746332D534C4C31008F

 

Share this post

×