McSonite 0 Posted December 11, 2020 Share Posted December 11, 2020 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. Link to post Share on other sites
Hervé 2,378 Posted December 11, 2020 Share Posted December 11, 2020 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. Link to post Share on other sites
McSonite 0 Posted December 12, 2020 Author Share Posted December 12, 2020 I knew that I hadn't grasped the patching even though I have read the manual. Here is the IOreg output. ioreg_20201212.zip Link to post Share on other sites
McSonite 0 Posted December 13, 2020 Author Share Posted December 13, 2020 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 Link to post Share on other sites
Hervé 2,378 Posted December 13, 2020 Share Posted December 13, 2020 I'm going to ignore that last IOReg labelled 20201213. Looking at the IOReg labelled 20201212, you may have noticed the following: no display listed under any of the 3 x connectors FB@0, port 5, pipe FFFF, type HDMI FB@1, port 6, pipe FFFF, type HDMI 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. Link to post Share on other sites
McSonite 0 Posted December 13, 2020 Author Share Posted December 13, 2020 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 Link to post Share on other sites
McSonite 0 Posted December 14, 2020 Author Share Posted December 14, 2020 Does @Hervé or anyone have any tips for this? These would be greatly appreciated. Link to post Share on other sites
Hervé 2,378 Posted December 14, 2020 Share Posted December 14, 2020 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? Link to post Share on other sites
McSonite 0 Posted December 14, 2020 Author Share Posted December 14, 2020 (edited) I was trying to be funny and refer to one great metal band's song by using the word blackened . 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 AAPL0x defined? Should I use AAPL00, AAPL01 or AAPL02? ioreg 3.zip config.plist.zip Edited December 14, 2020 by McSonite commented edid Link to post Share on other sites
McSonite 0 Posted December 14, 2020 Author Share Posted December 14, 2020 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. Link to post Share on other sites
McSonite 0 Posted December 15, 2020 Author Share Posted December 15, 2020 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. Link to post Share on other sites
McSonite 0 Posted December 15, 2020 Author Share Posted December 15, 2020 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 Link to post Share on other sites
Recommended Posts