svan71 Posted October 12, 2022 Share Posted October 12, 2022 I have successfully booted 12.6 with opencore 0.8.5. Everything works but for internal display, it goes black right before entering OS. This all-in-one has a HDMI out which connects perfectly to my external monitor. The processor is labeled 6400T but in mac os and windows it shows is in fact as 6500T. working hdmi.plist.zip Link to comment Share on other sites More sharing options...
Baio77 Posted October 12, 2022 Share Posted October 12, 2022 Test this https://drive.google.com/file/d/1i2zhSfK6W6V8a5hWiqOvjsLkr6jsiblK/view?usp=sharing for OC 0.8.5. If you have problems, you can add this in botarg in your config. "igfxonln=1" boot argument (force-online device property) to force online status on all displays. Ioreg if start 1 Link to comment Share on other sites More sharing options...
svan71 Posted October 12, 2022 Author Share Posted October 12, 2022 Thank you I will when I get home this evening. Link to comment Share on other sites More sharing options...
Administrators Hervé Posted October 12, 2022 Administrators Share Posted October 12, 2022 @svan71 Nothing to worry about the model of CPU reported; it's without any impact of any kind; you can ignore this or inject the relevant description if you feel this is necessary but it'll be cosmetic only. Several things to address in your posted config: your config indicates you use a patched DSDT table; please post it so that we try and establish what patches it contains; kinda essential here. you disable SIP with boot arg csr-active-config set to 0x0FFF; that's wrong for Big Sur and later as it prevents all macOS OTA updates; disable SIP with value 0x0FEF instead. your SKL framebuffer patching most likely needs to be revised; seems awfully complicated to me. Vanilla SKL framebuffer 0x19120000 defines the following video settings: ID: 19120000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000110F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [255] busId: 0x00, pipe: 0, type: 0x00000001, flags: 0x00000020 - ConnectorDummy [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP FF000000 01000000 20000000 01050900 00040000 87010000 02040A00 00040000 87010000 i.e. 2 DP output ports + a dummy one: Dummy port: FF000000 01000000 20000000 DP video port: 01050900 00040000 87010000 DP video port: 02040A00 00040000 87010000 Your set of injected graphics properties is incorrect because those properties are arguable : Intel i5-6400T and i5-6500T both integrate HD 530 iGPU with id 0x1912; as such, no need to inject/fake your iGPU's own native id (though it does no harm of course) you inject some properties/values that are identical to the selected framebuffer's own default settings; harmless of course but utterly useless you inject properties for 4th connector con3 on a 3port framebuffer layout without changing portcount value; I don't believe this can work and I'm failing to see the purpose anyway macOS SKL framebuffer kext defines a raft of mobile layouts (most of them with 3 output ports, only 1 with 4 output ports) and 4 connectionless desktop layouts (i.e. no output ports). Cf. Whatevergreeen user manual. Let's look at 4port layout 0x193B0005: ID: 193B0005, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0023130A TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 137 MB, MAX OVERALL: 138 MB (145244160 bytes) Model name: Intel Iris Pro Graphics 580 Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 4 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 03060A00 00040000 C7010000 You'll see that it defines the following 4 ports (with PortCount set to 4): 1 x LVDS (i.e. built-in LCD) video output + 3 x DP video outputs It's highly likely that the built-in screen of your AIO computer is LVDS type. As such, you may experiment with layout 0x191B0005 or inject the con0 properties of that layout to your existing config. You would normally expect your built-in screen to be on connector con0 and your HDMI output on con1 0105xxxx. Posting an IOReg extract (i.e. saved output from IOREgistryExplorer app) would greatly help to confirm your situation. Please note that patching a DP connector type to HDMI is only necessary to obtain HDMI audio, it's not necessary for video output. I'm highly sceptical about your connectors patching which effectively applies the following arrangements: con0: 02040A00 00080000 87010000 -> type HDMI and connector's id usually used for con2 con1: 03050A00 00080000 [87010000] -> type HDMI and unusual connector's id; unmodified flags con2: 01050900 00080000 [87010000] -> type HDMI and unusual connector's id; unmodified flags con3: FF?????? 01000000 20000000 -> dummy port? Why? Invalid anyway when PortCount remains set to 3 I would suggest that: you open up your AOI computer and identify your built-in screen type: LVDS or mDP for instance 1st test using SKL frambuffer layout 0x191B0003 with default (i.e. unpatched) connector's settings if unsuccessful, you may then return to layout 0x19120000 but inject the following connectors settings only (i.e. remove all the others): framebuffer-con0-enable 1 NUMBER framebuffer-con0-alldata 000008000200000098000000 DATA -> sets con0 to LVDS output port framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA -> sets con1 to HDMI type If your built-in screen were actually mDP (miniDP), you could try: framebuffer-con0-enable 1 NUMBER framebuffer-con0-alldata 000008000004000098000000 DATA -> sets con0 to DP output port framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA -> sets con1 to HDMI type Of course, if your AIO's default settings sets DVMT to 32MB and you've not patched this, keep your existing fbmem and stolenmem patching as it is, i.e. framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA Whatevergreen boot arg igfxonln=1 may not be useful at all but does no harm of course; it's usually useful when, say, you plug HDMI and built-in screen goes black and never recovers after unplugging HDMI; this sort of things. I'm not convinced it'll do anything in the case of your built-in screen going dark at graphics initialisation, something very common on AOI Hackintosh computers. 1 Link to comment Share on other sites More sharing options...
svan71 Posted October 12, 2022 Author Share Posted October 12, 2022 Hervé thank you, I'm very new to this, and I'm just learning what does what. I was using hackintool and trying to understand whatevergreens directions. I can provide an i/o reg and DSDT. Steve’s iMac.ioreg ACPI.zip Link to comment Share on other sites More sharing options...
svan71 Posted October 12, 2022 Author Share Posted October 12, 2022 This is my latest attempt doing my best to apply what you said. I now see my main screen as an option for extending or mirroring and I didn't before but it is still is off. Working HDMI 2.plist.zip Steve’s iMac.ioreg Link to comment Share on other sites More sharing options...
Administrators Hervé Posted October 13, 2022 Administrators Share Posted October 13, 2022 2nd IOReg is indicative of progress and improvement because it now shows 2 x displays (i.e. screens): 1 off con0 (i.e. built-in display) and 1 off con1 (i.e. HDMI external screen): Things to work on now are: getting your buit-in display recognised as such ("AppleDisplay" usually mean external screen when a buit-in LCD screen normally registers as "AppleBacklightDisplay"). black screen issue; this may require you to inject your screen's EDID. You would 1st need to extract it from say Windows. There are existing and readily available tools to do that. Link to comment Share on other sites More sharing options...
svan71 Posted October 13, 2022 Author Share Posted October 13, 2022 ok i will need to wait until I have time to load windows unless I can boot to a Linux USB and get it from there ? Link to comment Share on other sites More sharing options...
Administrators Hervé Posted October 13, 2022 Administrators Share Posted October 13, 2022 Most probably; you'd have to look that up. Link to comment Share on other sites More sharing options...
svan71 Posted October 13, 2022 Author Share Posted October 13, 2022 Hopefully this is it. edid.txt.zip Link to comment Share on other sites More sharing options...
Recommended Posts