Hervé

Released August 30th, 2023.

Build 23A5337a.

 

 

Smooth and straightforward update using the same usual principles applied before.

 

Oh but it does! Just not through the Realtek Codec but the Intel one: Intel Sunrise Point-LP HD audio 8086:9D70. So you need AppleALC to have a patch for that controller. Failing that, it's jack output to an analog audio input of your TV, meaning 2 cables between your NUC and your screen. Far from great but better than nothing I suppose...

 

I think you have a better chance to obtain HDMI audio through VoodooHDA. Russian developper @Slice continues to support VoodooHDA development. You can always try and contact him, probably at InsanelyMac because he does not visit OSXL much.

https://www.insanelymac.com/forum/topic/314406-voodoohda-302

Ok, IOReg shows that:

1. your HDMI display hooks to connector con1 
2. connector con1 is suitably set to type HDMI

On paper and in theory, all looks Ok on that front but I believe you're missing an essential piece of information about your platform...

 

The other thing to look at is the Codec.

 

You're using AppleALC as expected so one could suggest you played with the various layouts available for Realtek ALC283 and you may have already done that, albeit without any success. Well, given what Intel's NUC6i3SYB Technical Product Specification detail for audio, I'm not surprised:

-> It appears that HDMI and DP audio outputs are not processed through the Realtek codec but through the Intel codec. That would explain why you never see any HDMI audio output option.

 

Given that I've not seen any support for Intel NUC6 in the AppleALC wiki, I don't believe you're likely to obtain any HDMI audio until the necessary support is added. I've never had to do this so no experience on the matter but you'll find several threads on the forum about dumping Codec info and tuning AppleHDA/AppleALC for the target hardware. In turn, this could be your valuable own contribution to AppleALC as a new controller patch for Intel's NUC6.

• https://github.com/acidanthera/AppleALC/wiki
• https://github.com/acidanthera/AppleALC/wiki/Adding-codec-support
• https://github.com/acidanthera/AppleALC/wiki/Dumping-processing-coefficients

Of course, you may check the details of the patches for the listed Intel controllers in case one matches your NUC's hardware. They are listed at the bottom of the wiki page. Maybe you could get lucky with NUC8, who knows?

 

I don't believe deprecated FakePCIID will be of any help here but maybe VoodooHDA will do the trick; it's a very long time since I last used it, so...`

 

With regards to SMBIOS, do experiment but wouldn't Macmini8,1 be the most appropriate? I presume your NUC6i3SYB is fitted with i3-6300U CPU so, if you have to use a laptop SMBIOS, you may find dual-core MBP13,1 to be better suited than quad-core MBP13,3. iMac17,1 is fitted with desktop quad-core Skylake CPU + AMD dGPU, so not the best target SMBIOS for your platform I reckon.

Normally, all you'd need is to ensure that the connector type of the port used for HDMI output is set to HDMI (00080000). In the config file of the pack you linked to, I see:

AAPL,ig-platform-id        00001219        DATA
framebuffer-patch-enable   01000000        DATA
framebuffer-con1-enable    01000000        DATA
framebuffer-con1-alldata   01050900 00080000 87010000 02040A00 00080000 87010000 DATA

 

SKL framebuffer 0x19120000 is defined as follows:

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

 

So, if your HDMI output registers against con1 or con2, you should be Ok. What does it show in IOReg?

 

I also noticed that SMBIOS was set to laptop model (MBP13,3). So you may want switch to SKL framebuffer 0x19160000 instead and see how that goes.

ID: 19160000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000090F
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
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00040000 87010000

 

I've no issue getting HDMI audio out of my Skylake/HD520 Dell Latitude E7270 laptop (ALC293 codec, layout-id 11) under Monterey with the following iGPU properties (and only those), SMBIOS MBP13,1 and igfxonln=1 boot arg:

AAPL,ig-platform-id        00001619        DATA
framebuffer-patch-enable   1               NUMBER
framebuffer-con1-enable    1               NUMBER
framebuffer-con1-type      00080000        DATA
hda-gfx                    onboard-1       STRING

 

Maybe you should remove those extra properties dealing with HDMI.

Well, it sure is seen in IOReg:

 

And, from what I see, you appear to inject suitable properties. Maybe be you ought to rename your ACPI device from WL00 to ARPT. See if that makes any difference. You could also try a different SMBIOS profile to see if it makes any difference though I should not think so. MBP13,x/14,x/15,x sure support the card normally.

You need to follow the required process for Broadcom BCM4350 cards as detailed here.

But if the wifi card is not even detected, that probably won't do much good. Maybe hardware is faulty. Post a zipped IOreg extract taken from IORegistryExplorer.

Congrats on learning by yourself, sort of...

As stated before, download one of my most recent E6230 packs, open up the Clover config with CC and you'll see for yourself; it's really not difficult if you make a little effort to learn by yourself.

If you download a Clover bootpack from one of my existing E6230 guides and open the config file with CloverConfigurator, you'll see what to do and how it's done. Look up the Device tab on the left, the the Properties area at bottom right:

 

Released August 22nd, 2023.

Build 23A5328b.

 

 

Smooth and straightforward update using the same principles applied before.

 

 

New wallpapers and screen savers with this 6th beta.

Exact same process; you may use CloverConfigurator. Property injection is done in the exact same way in the config file.

All you really have to do is grab an existing config and look it up with apps such as OpenCoreConfigurator (or otherwise) and do the same. Just make sure to target the correct IO locatoin/device path by verifying things in IOReg 1st. You may use apps such as IORegistryExplorer to that effect.

Plenty of existing threads on the matter. See here for instance.

1. in your bootloader's config, inject device property declaring your card compatible with Broadcom BCM4360 (14e4:43a0).
2. inject AirPortBrcmFixup kext.
3. make sure you use a suitable SMBIOS profile (eg: MPB12,1) or -no_compat_check boot arg if you're using MBP9,x/MBP10,x profile.

It's based on Broadcom BCM4352, so, apply the necessary patch. It's never been natively supported.

https://osxlatitude.com/forums/topic/11138-inventory-of-supportedunsupported-wireless-cards-2-sierra-ventura

https://github.com/khronokernel/IO80211-Patches

 

Ok. So you use CFL mobile framebuffer 0x3EA50009 which is natively defined as follows:

ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel HD Graphics CFL CRB
Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[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
00000800 02000000 98000000
01050900 00040000 C7010000
02040A00 00040000 C7010000

 

You patch it using the following properties:

 

in particular, you patch your connectors like this:

con0: 00000800 00080000 98010000
con1: 01050900 00080000 C7010000
con2: 02040A00 00080000 C7010000 

Considering your computer is a mini desktop with no built-in LCD, there is absolutely no value in patching connector con0 the way you do.

For connectors con1 and con2, you simply set their type to HDMI (00080000) and that's Ok, it's a must for HDMI audio to work.

 

You also patch the framebuffer's flags:

FB flags: 4A0B8300

To what purpose do you do that? What does this new value bring? Is it something you obtain through Hackintool??

Ever considered not patching this and simply use the default value?

You certainly could install OS X and early macOS versions on Dell laptops with Legacy BIOS. Chameleon, Enoch and Clover certainly supported this and Clover still does. Opencore natively requires UEFI mode though it could be tuned to run and boot on older systems with legacy BIOS mode only. No idea if recent versions still support this.

 

Why would you want to run in legacy BIOS mode? Win7 fully supports UEFI mode. From memory, BIOS just had to provide some specific functionality but it eludes me now.

Intel i5-10210U is not a 7th gen. Kaby Lake CPU but a 10th gen. Comet Lake one. It's fitted with UHD 720 graphics carrying id 0x9b41 (which is not natively supported). Why you would want to apply KBL settings (as shown in your "BRIX" IOReg) to the iGPU is a bit of a mystery and don't expect this to work.

 

IOReg "BRIX w: sound" correctly shows CFL/CML framebuffer layout 0x3ea50009 being used. If you only use 1 video output and that's your HDMI, then this is what registers against connector con1 (FB@1). And you also injects the correct connector type (HDMI 00080000) in your config by the look of things.

 

Whatevergreen User Manual states that the following iGPU ids are supported, as shown in the CFL framebuffer kexts:

            <key>IOPCIPrimaryMatch</key>
            <string>0x3E9B8086 0x3EA58086 0x3EA68086 0x3E928086 0x3E918086 0x3E988086 0x9BC88086 0x9BC58086 0x9BC48086</string>

 

Your IOReg shows you fake/inject CFL iPU id 0x3e9b, maybe you should try and fake one of the following CML ids instead: 0x9bc4, 0x9bc5 or 0x9bc8. Though I doubt it'll make any improvement... If you don't use it, try and add boot arg igfxonln=1.

 

Ideally, post a zipped copy of your bootloader's EFI folder (config file + ACPI & texts folders).

-> moved to Latitude 3000 series section.

 

Check existing Latitude 3400 threads. I understand the EFI posted by @davidfrei7as here provided a fully working laptop.

'can't remember if screen mirroring is enabled by default in VESA mode but it really does not matter. It's not the proper way to run macOS, so... no point wasting any time on that.

Maybe you ned to inject your screen's EDID value. See our FAQ topic on the matter.

KBL HD620 with id 0x5916 is natively supported, even in Sonoma. FYI, if you checked the KBL driver in macOS 14.0 beta, you'd see the following iGPU ids:

<key>IOPCIPrimaryMatch</key>
            <string>0x59128086 0x59168086 0x591B8086 0x591C8086 0x591E8086 0x59268086 0x59278086 0x59238086 0x87C08086 0x3E9B8086 0x3EA58086 0x3EA68086 0x3E918086 0x3E928086 0x3E988086 0x9B418086 0x9BCA8086 0x9BCC8086 0x9BC88086 0x9BC58086 0x9BC48086</string>

 

This is a complete (bad) joke, right?

 

Booted OS was Big Sur (kernel 20.6.0, build 20G1426) and your OC config + IOReg show you're injecting Skylake settings! SKL framebuffer 0x10160000 and SKL iGPU id 0x1916... So, not only are you incorrectly using 6th gen. Skylake settings on a 7th gen. Kaby Lake laptop, must we also remind you that Skylake graphics are unsupported since Ventura?

 

 

And it was also stated before that you should be using MBP15,2 SMBIOS, not MBP15,3.

If you follow what was previously suggested, I'm sure you'll get somewhere...

Use the correct settings in your config file, save it and make sure to reset NVRAM at OC Picker when you reboot.

What happens if you disable hibernation as described in our FAQ topic?

Released August 8th, 2023.

Build 23A5312d.

 

 

As usual, no OTA update offered when running with MBP15,2 SMBIOS and had to reboot temporarily with iMac19,1 SMBIOS. Otherwise, completely smooth update.

 

What's not working for iGPU? No HDMI output or freeze/KP on plugging/unplugging the HDMI cable? You sure got the correct patch in place.

 

I'm a little confused when you say you get a black screen on putting the computer to sleep? What else did you expect? Does it not go to sleep? Or do you mean you get black screen on wake? In which case, what if you wait something like several (long) minutes (but under 5mins)?