<< Solved >> Can't get bluetooth to function

[james090500]

Hi,

I am having some trouble get Bluetooth to work in my hack. I am using a Dell DW1550 and WiFi is working fine however Bluetooth has issues. I have attached as lot of information but if I missed anything please let me know.

Turning Bluetooth ON doesn't do anything.

My only thought is a problem with USB Mapping. The PC is a Dell OptiPlex 9020 AIO, it's possible it has 2 USB controllers? I have tried USB mapping but 2 USB ports on the back never work. Maybe bluetooth over USB isn't working?

Hackintool

System Report

Kexts

 

[Edhawk]

Hackintool > System > Peripherals:
Can you explain why you have the 2 x Intel USB XHCI devices shown in the System > peripherals > Network section of Hackintool? This is not normal, not that I have ever seen with a Haswell system.

This section usually only shows the Ethernet and WiFi adapters, not a USB controller.

Maybe the reason your USB ports are not working correctly is because you have them crossed with a Network device. Possibly the DeviceProperties > Add entry for the USB controller in your config.plist is miss applied.



I have never had to use this type of DeviceProperty with an Intel USB controller. Usually something along these lines are only required when you have an older controller that is a bit funky, and it needs help to be correctly discovered or a wake-up call. I have never found that to be the case with a Haswell 8-series system.

USBPorts.kext:
Your USBPorts.kext/Contents/Info.plist looks wrong.

1. You are activating 6 x HSxx ports with the USB2 connector type '0' and 3 x SPxx ports with the USB3 connector type '3'.
2. Any USB2 ports served from a physical USB3 port needs to be set with the Connector type USB3 '3' not as a USB2 port.
3. Only USB2 physical ports, usually with a black tang - never blue, should be set with the connector type '0' USB2.
4. You have no ports set as 'Internal' (255), which your Webcam (if you have one) and the Broadcom Bluetooth module would use.

The SSDT-EHCx-Off.aml table will not cause your USB ports to not work, if that was what you were thinking. On all my Haswell systems this simply passes the EHC1 and EHC2 ports to the XHC controller.

Kexts:
Looking at the list of kexts you provided above I can see you are using a kext that is specifically meant for a DELL system. Not a HP AIO system - SMCDellSensors.kext. You should remove this kext and the corresponding config.plist entry.

OC Files:
Looking at your OC folder in general it is clear that the files are from different versions/Releases of OpenCore. This is not good. You should always use the drivers (OpenRuntime.efi especially), BOOTx64.efi, Tools and OpenCore.efi from a single release. They should not have mixed dates like in your setup.



Config.plist

ACPI Rename patching:
You are missing the XHCI to XHC ACPI rename patch, which is essential if you are using the SSDT-EHCx-Off.aml table. The XHCI to XHC rename patch is shown below, as viewed in ProperTree Plist editor.



IGPU Framebuffer Patching:
You seem to have gone to a lot of trouble with your IGPU framebuffer patching.



Are both display connectors in your system DisplayPort? As that is what the framebuffer-con0-alldata and framebuffer-con1-alldata entries are saying/enabling.

With your explicit/custom framebuffer patching WhateverGreen.kext will not provide the normal Audio patching it undertakes since macOS Yosemite 10.10.5. See this extract from the WEG Intel HD FAQ manual:



The IGPU port patching being as it is, i.e. DisplayPort, why are out using the 'enable-hdmi20' entry?

The framebuffer-fbmem and framebuffer-stolenmem entries are not what I would expect to see. Those two entries are usually as follows:

• framebuffer-fbmem > Data > <00009000>
• framebuffer-stolenmem > Data > <00003001>

As shown below.


PlatformInfo:
You have erroneously included your Serial Number and other SMBIOS data in the config.plist you posted above.

As I am not the first to download your EFI, I would recommend you sign out of any Apple Services. Create a new Serial Number, MLB, ROM and SystemUUID for your system. As your current data can only be assumed to have been compromised.

 

[james090500]

Hackintool > System > Peripherals:
Can you explain why you have the 2 x Intel USB XHCI devices shown in the System > peripherals > Network section of Hackintool? This is not normal, not that I have ever seen with a Haswell system.

This section usually only shows the Ethernet and WiFi adapters, not a USB controller.

Maybe the reason your USB ports are not working correctly is because you have them crossed with a Network device. Possibly the DeviceProperties > Add entry for the USB controller in your config.plist is miss applied.

View attachment 549763

I have never had to use this type of DeviceProperty with an Intel USB controller. Usually something along these lines are only required when you have an older controller that is a bit funky, and it needs help to be correctly discovered or a wake-up call. I have never found that to be the case with a Haswell 8-series system.

USBPorts.kext:
Your USBPorts.kext/Contents/Info.plist looks wrong.

1. You are activating 6 x HSxx ports with the USB2 connector type '0' and 3 x SPxx ports with the USB3 connector type '3'.
2. Any USB2 ports served from a physical USB3 port needs to be set with the Connector type USB3 '3' not as a USB2 port.
3. Only USB2 physical ports, usually with a black tang - never blue, should be set with the connector type '0' USB2.
4. You have no ports set as 'Internal' (255), which your Webcam (if you have one) and the Broadcom Bluetooth module would use.

View attachment 549758

The SSDT-EHCx-Off.aml table will not cause your USB ports to not work, if that was what you were thinking. On all my Haswell systems this simply passes the EHC1 and EHC2 ports to the XHC controller.

Kexts:
Looking at the list of kexts you provided above I can see you are using a kext that is specifically meant for a DELL system. Not a HP AIO system - SMCDellSensors.kext. You should remove this kext and the corresponding config.plist entry.

OC Files:
Looking at your OC folder in general it is clear that the files are from different versions/Releases of OpenCore. This is not good. You should always use the drivers (OpenRuntime.efi especially), BOOTx64.efi, Tools and OpenCore.efi from a single release. They should not have mixed dates like in your setup.

View attachment 549757

Config.plist

ACPI Rename patching:
You are missing the XHCI to XHC ACPI rename patch, which is essential if you are using the SSDT-EHCx-Off.aml table. The XHCI to XHC rename patch is shown below, as viewed in ProperTree Plist editor.

View attachment 549759

IGPU Framebuffer Patching:
You seem to have gone to a lot of trouble with your IGPU framebuffer patching.

View attachment 549760

Are both display connectors in your system DisplayPort? As that is what the framebuffer-con0-alldata and framebuffer-con1-alldata entries are saying/enabling.

With your explicit/custom framebuffer patching WhateverGreen.kext will not provide the normal Audio patching it undertakes since macOS Yosemite 10.10.5. See this extract from the WEG Intel HD FAQ manual:

View attachment 549762

The IGPU port patching being as it is, i.e. DisplayPort, why are out using the 'enable-hdmi20' entry?

The framebuffer-fbmem and framebuffer-stolenmem entries are not what I would expect to see. Those two entries are usually as follows:

• framebuffer-fbmem > Data > <00009000>
• framebuffer-stolenmem > Data > <00003001>

As shown below.
View attachment 549761

PlatformInfo:
You have erroneously included your Serial Number and other SMBIOS data in the config.plist you posted above.

As I am not the first to download your EFI, I would recommend you sign out of any Apple Services. Create a new Serial Number, MLB, ROM and SystemUUID for your system. As your current data can only be assumed to have been compromised.

Firstly, thank you so much for your reply. I'll try explains things the best I can.

Hackintool > System > Peripherals:
I can't explain the reason these devices appear in the Network Section. To be totally honest, I didn't even realised it was the network section.. All I can say is when I plug in USB devices they appear in that section.

I think tomorrow I will remove the DeviceProperties section and try with out it. It's very possible I added it when debugging and forgot to remove it.

USBPorts.kext:
I have gone through a few USB Port Map software. In my latest attempt to get USB Ports working I installed Windows to an external HDD to check everything over. Much to my surprise, I discovered my webcam, bluetooth and 2 of the 6 back USB port fail to work. I am concerned, if these are on the same USB.. lane? Then it could all be related. I am not sure how to even attempt to remap my USB ports if on Windows they don't even work.

I will try get everything to work on Windows first, then attempt a map and apply to changes you suggest.

Kexts:
I am using a Dell OptiPlex 9020 AiO not HP, so I need SMCDellSensors.kext

OC Files:
That is poorly done of me. I missed the second bullet point from Dortania here (https://dortania.github.io/OpenCore...ncore-files-with-the-ones-you-just-downloaded). I will fix this also tomorrow.

Config.plist

ACPI Rename patching:
I assume I don't need SSDT-EHCx-Off so can remove it from the EFI and disregard this section?

IGPU Framebuffer Patching:
My entire framebuffer patching is a mess. I am using an iGPU with no external monitors. I would personally like to redo all of this but can't find a suitable guide, is it even something that needs to be done?

PlatformInfo:
Oops. Will do.

 

[Edhawk]

Kexts:
I am using a Dell OptiPlex 9020 AiO not HP, so I need SMCDellSensors.kext

My bad, apologies for not re-reading the first post!

ACPI Rename patching:
I assume I don't need SSDT-EHCx-Off so can remove it from the EFI and disregard this section?

Remove the SSDT-EHCx-Off.aml table. Your system USB ports may work differently with the SSDT removed. Maybe the ones that don't work will be enabled?

IGPU Framebuffer Patching:
My entire framebuffer patching is a mess. I am using an iGPU with no external monitors. I would personally like to redo all of this but can't find a suitable guide, is it even something that needs to be done?

Yes it needs to be done, but not to the extent that you have gone.

You should keep it simple. Just use these standard Haswell HD4600 IGPU settings in your DeviceProperties section:

For HD4600 driving a display

For HD4600 when not driving a display

You should only use the second option above if your system has a compatible discrete graphics card, which drives the display.

If you only have the IGPU HD4600 then the top option should be used.

Your i5-4590 CPU uses the HD4600 IGPU, which is natively supported in macOS. So your setup doesn't require a fake device-id entry.

 

[james090500]

ACPI Rename patching:
All done, sadly no difference.

IGPU Framebuffer Patching:
Fantastic, thank you!

The USB Problem:
So, testing in Windows I fail to get the back 2 USBs, Camera or Bluetooth working. I think I have a much bigger issue than just it being a Hackintosh. I will be doing more research.

 

[Edhawk]

Have you tried using a Linux Live USB drive on your laptop, to see if the USB devices show and work in Ubuntu?
You don't need to install the Live USB, just run it from the USB drive and in system memory, as a test.

Try Ubuntu before you install it | Ubuntu

Ubuntu is an open source software operating system that runs from the desktop, to the cloud, to all your internet connected things.

ubuntu.com

I assume you have seen and read through @trs96 guide for the Dell Optiplex 9020 system.

The Dell OptiMac Big Sur/OpenCore Thread - For 7020/9020 Optiplex Desktops

Dell Optiplex 7020/9020 Desktops macOS 11 Big Sur This is a separate "cousin" thread to the main Golden Build thread for the Dell Optiplex 7020/9020 desktops. That focuses primarily on macOS Mojave/Catalina. There is a massive amount of useful info in the Golden Build thread that applies to...

www.tonymacx86.com

 

[trs96]

I assume you have seen and read through @trs96 guide for the Dell Optiplex 9020 system.

This guide by minihack works better for a 9020 AIO Dell. Even though it says 9030 it still works for a 9020 AIO.

Guide Dell Optiplex 9030 All in One

Overview The Optiplex 9030 is a 23" All in One system based on Haswell processors. It comes in two main different types: Integrated graphics type and a variation with AMD R7 A265. This guide is just for the integrated graphics HD4600 and HD4400 version. I cannot recommend this enough as a...

www.tonymacx86.com

 

[james090500]

Update! I have made significant progress since previously.

Bit of a backstory. About a year and a half ago, this system was running Big Sur almost flawlessly. It was booting, had WiFi but still no USB or Camera. I followed a guide which was for the OptiPlex 9020 Desktop Tower series, I thought as it was close enough to an AIO the guide would work fine. It pretty much did.

So, fast forward to a few weeks ago I thought I'd use the guide again. The guide explained some important BIOS settings such as CFG Lock and EHCI hand off are missing from the BIOS GUI. It explained we needed to use "setup_var" to set CFG Lock, DVMT Alloc and EHCI hand off settings. I followed the instructions, built my EFI and boom, Monterey was running in no time!

Sadly, Monterey dropped support for the Aethros WiFi chips I was using with Big Sur and I still had the USB Problem... I felt pretty clued up nowadays so decided to get a Dell DW 1550 and setup a proper USB map to try and fix my USBs.

Once the DW1550 was installed, I still had no Bluetooth! Not to worry, my USB Map will fix it... After a few days tinkering I posted here for the help of you guys!

Lets fast forward to this afternoon once again! I decided, lets completely reset the BIOS to factory defaults.. I decided not to use the GUI but instead took apart my AIO and used one of the on board jumper pins. As quick as a flash the BIOS was back to its COMPLETE defaults.

Quickly boot it up to Windows and BOOM! Bluetooth, USBs and Webcam are all working flawlessly! Wow! What a result, lets get into Mac!

It crashed..

No worries, lets fix my BIOS settings as the guide suggested...

It crashed again...

I spent about 2 hours, checking, double checking, trying a different EFI, trying the EFI on my USB... It showed the Apple logo then rebooted.

Until, on the OpenCore "BIOS Settings" section under the Haswell setup I saw this.

CFG Lock (MSR 0xE2 write protection)(This must be off, if you can't find the option then enable AppleXcpmCfgLock under Kernel -> Quirks. Your hack will not boot with CFG-Lock enabled)

I thought, lets try it, I'm not getting any sort of kernel panic, just OpenCore logs then reboot.

Much to my surprise it booted instantly! What?! CFG Lock was disabled I ran the setup_var? And this worked previously so why's it not working now? I was determined to get to the bottom of it. I remembered a couple of days ago, I accidentally tried to install the OptiPlex 9020 BIOS on my OptiPlex 9020 AiO and it told me the two were not compatible, I thought huh, I wonder if these "setup_var" values are different on my AiO.

I followed OpenCore's "Fixing CFG Lock" guide, exported the BIOS and hunted for the value. I found it.. "0xDAF". much different than the "0xDA2" the guide I was following suggested. Set the value, and Mac booted instantly, but the USBs, Webcam and Bluetooth were still not working.

This got me thinking, what if the "EHCI Handoff" and "DVMT" values were also wrong? This could have been messing with all my USB settings.

So I reset the BIOS once more and only set the CFG Lock to false. I have left DVMT and EHCI Handoff at their defaults and booted Mac.

The Result?

All USBs are working, the Webcam works so I can now Facetime people and to top it all off we have functional Bluetooth!

So you may be wondering, why did this work previously if I've been using the incorrect setup_var values all this time. Well, I believe I did this exact same thing about a year and a half ago. Exported the BIOS and got the values myself. I am just assuming that the "Load Defaults" button in the BIOS screen doesn't actually reset these hidden values, just the visible ones. I then probably tried to follow a guide, and assume a "Load Defaults" reset my values, then completely messed up the EHCI handoff data...hence it was not working in Windows or Linux.

Tomorrow, I plan to adjust my DVMT values and enable EHCI hand off, just this time with the correct values I've pulled from the BIOS myself. I will then leave them here.

 

[james090500]

Some more testing with BIOS Settings.

# Disable CFG Lock (default 0x1)
# True or false, this makes it true
setup_var 0xDAF 0x0

# Set DVMT pre-alloc to 64MB (default 0x1)
# 32MB up to 1024MB. This sets it to 64MB
setup_var 0x263 0x2

These work flawlessly. However, as soon as I enable EHCI Hand Off Bluetooth, Webcam and back USBs stop working.
I even added the follow values to make sure EHCI handoff is working intended

#Enable EHCI Hand-off (default 0x0)
# True or False, this makes it True
setup_var 0x2 0x1

# XHCI Mode (default 0x3)
# Smart, Auto, Enabled, Disabled or Manual. This make sure it's just "Enabled"
setup_var 0x144 0x1

# Route all EHCI to XHCI (default 0x1)
# Per Pin, All Pins to EHCI, All Pins to XHCI. This make it's it "All Pins to XHCI"
setup_var 0x15A 0x2

With all USBs, Camera and Bluetooth working. I did a USB Port Map and you can see the Bluetooth and Camera are on EHCI Hubs. Also the back 2 USB ports which didn't used to work are as well...

 

[Edhawk]

OK, so when you create the USBMap.kext for your system based on the 14 ports enabled above. Do your ports and devices work as expected?

Do you need to change/edit any of the port connector types?

As I have never used this script in Windows I am assuming you didn't add the (guessed) entry to each port, that this was something the script added automatically. Were the guesses correct regarding the port type?