Previous month:
June 2020
Next month:
August 2020

Hackintosh USB mapping - attempt to fix broken Bluetooth

UPDATE 2: My attempts at “fixing” USB mapping broke all the USB 3.x ports. None of the USB 3.x ports work. I did set them to “Type 3” which is “USB 3 Standard-A connector”. Undoing all the USB mapping stuff fixed my non-functioning USB ports. Everything works OK, including Bluetooth. No idea why: everything about OpenCore is still kind of a mystery to me.

UPDATE: Bluetooth fixed itself. What I did: booted into Windows (installed on a separate SSD), used Windows to connect to the speaker, quit Windows to boot into Hackintosh, and Bluetooth works again. Quick way to see that Bluetooth is OK is that System Information on the Bluetooth device should show a non-trivial address. If it were broken, the address would be 00-00-00-00-00-00.

Screen_Shot_2020-07-12_at_10_38_26_PM edited

tl;dr This did NOT fix my Bluetooth issue. I had also cleared the CMOS and re-set all the BIOS settings before I went through all of this. So, this may be of some use as a summary of USB port mapping in OpenCore, but of no use at all for fixing Bluetooth issues.

Bluetooth stopped working for unknown reasons. Discovered that Bluetooth is actually an internal USB device.

Suspicion: the breakage is due to the macOS 15 USB port limit. (Additional USB hubs get their own 15-port limit.)

Follow instructions:

  • https://dortania.github.io/USB-Map-Guide/
  • https://github.com/corpnewt/USBMap

Using the USBMap script, can see that there are 26 ports listed: HS01 - HS14, USR1 - USR2, SS01 - SS10. (This is the same as the list that corpnewt has on their system.)

The script allows you to disable all SSxx ports and all HSxx ports. Then, manually enable a specific set of HSxx ports. From this post at tonymacx86, someone has listed the USB ports for this motherboard: back panel, and internal headers. I have verified this is correct, for the ports that I can use. I have no USB Type-C devices, so I cannot check the two USB Type-C ports on the rear panel.

Designare Rear IO Layer v3_resize
Designare Rear IO Layer v3_resize

The case I am using has no front-panel USB Type-C ports, so I can leave HS01 disabled. I do not currently have any USB 3.1 Gen 2 Type C devices, but I am planning to get at least one: I will enable both HS08 and HS13. I will leave the internal Bluetooth (HS14) enabled. There is no HS02 shown in either diagram, and none of the ports I could test were HS02: so, disable that. There was no USR1, either, but the USBMap documentation does not say anything about enabling or disabling USR* ports, so leave that enabled.

Summary: 

  • Two disabled HS ports: HS01 and HS02

That leaves me with 12 HS ports, and 2 USR ports, bringing me up to 14 ports.

The boot-args option is:

debug=0x100 keepsyms=1 alcid=1 agdpmod=pikera -uia_exclude_ss -uia_exclude_hs uia_include=HS03,HS04,HS05,HS06,HS07,HS08,HS09,HS10,HS11,HS12,HS13,HS14,USR1,USR2

Back at the main menu of USBMap, pick “S. Build SSDT-UIAC”, which will generate two .aml files:

  • SSDT-UIAC.aml
  • SSDT-USBX.aml

Copy those to your EFI/OC/ACPI folder, edit your config.plist to add them to the ACPI section, and reboot.

Steps:

  1. Disable all ports named “SS* - using USBMap script, select “S. Exclude SSxx Ports. This appends the boot option -uia_exclude_ss to NVRAM which will persist across reboots. NB this does not modify config.plist. In OpenCore 0.5.9, this step did not work for me. So, manually modify config.plist to add the boot option (NVRAM->Add->...long string of chars->boot-args). Manually trying to set boot-args using the nvram command gives an error: “nvram: Error setting variable - 'boot-args': (iokit/common) not permitted”. So, set it in config.plist, instead.
  2. Download SSDT-USBX.aml from USB-Map-Guide/extra-files
  3. Use SSDTTime to generate SSDT-EC.aml. (Had SSDT-PLUG.aml from initial install.)
  4. Copy the .aml files into EFI/OC/ACPI/
  5. Add entries for both SSDT-USBX.aml and SSDT-EC.aml into config.plist

Hackintosh update - WiFi card added

I wanted to have Handoff on my Hackintosh. That requires WiFi.

The built-in WiFi on the Gigabyte Z390 Designare motherboard does not work with macOS. But Dortania, the people who work on OpenCore, have a list of recommended WiFi devices. I got an ASUS PCE-AC68 AC1900 Dual-Band Wireless PCI-E Adapter. And it just worked. I did not have to add more kexts or munge my config.plist.

Another point for OpenCore.

However, Handoff does not work. It seems like I need a Bluetooth adapter with a particular chipset. The ones that are pretty certain to work are ripped out of actual Macs: they use the Broadcom BCM94360CS2 or BCM94360CS (one person had better luck with this) chipset, and combine WiFi with Bluetooth. There are also generic adapters: search eBay for that product string. These are M.2 form factor. Since I wanted the second M.2 slot on my motherboard for a Windows installation, I could not go this route.


Migrating from Aperture to Lightroom Classic

I built a new Hackintosh, and am now running macOS Catalina (10.15). Since Catalina only runs 64-bit applications, I am finally forced to migrate all my photos from Aperture to Lightroom Classic. 

tl;dr Make Aperture store its masters as “referenced”. Split the library into smaller ones, no more than about 10,000 masters per library. (A 27,000-master library took > 24 hours to import.) Import into Lightroom, keeping Aperture masters in place, and copying Aperture-edited previews into the masters’ location to allow automatic stacking. 

The Aperture import plug-in that comes with Lightroom Classic is not great. If you have a very large library, it can get very slow. No one who has very large libraries seems to have waited. My library is about 700 GB, with about 560 projects and 81,500 images. I kept the library “managed” i.e. Aperture copied everything into its library package. I tried to import the full Aperture library into Lightroom Classic. After 5 full days (24 hours per day) of running, the import into Lightroom seemed to stall at 50%. From the start of the process, every additional percentage point seem to take longer and longer. (Felt like an N² algorithm or worse.) Others have had the same experience (Adobe support community forum post).

Without resorting to a manual import (aka “the Old Method”), as the person who posted that issue in the Adobe forum did, I figured I would try the latest suggestion posted there, i.e. to break up the single original library into multiple smaller libraries. That seems to be working pretty well. 

To export in Aperture: File ▶ Export ▶ Items as New Library… Then, in the options: 

For this to work, your Aperture masters folder must have the same absolute path on the old computer and the new computer. My old computer’s Aperture masters (originals) folder was at: /Volumes/Homes/Users/myname/Pictures/Masters
 
On my new computer, I needed to make sure that my home folder was on a separate volume, such that it ended up with the same absolute path /Volumes/Homes/Users/myname/Pictures/Masters. I had tried one iteration, where my new home folder was in a slightly different location /Volumes/Homes/myname and that did not work because Lightroom Classic complained that the folder /Volumes/Homes/Users/myname/Pictures/Masters was missing. It is not the fault of Lightroom Classic, since the absolute paths are encoded in the exported Aperture libraries.
 
You also want to make sure the previews are copied into the exported library. Otherwise, Lightroom Classic would not have access to those (edited) previews.
 
To import into Lightroom Classic: File ▶ Plug-in Extras ▶ Import from Aperture Library…. There is an Aperture Import Info… menu selection which gives some info about the import process. A window will pop up, showing four sections.
 
The first section is “Previews from Aperture”. There is only one option, “For images which have been adjusted in Aperture, import full size previews from the Aperture library (if they are available and up-to-date)”: check that ON.
 
The last one, is “Files referenced in Aperture”. Here, check ON “Leave referenced files in your Aperture library in their current location”. If you have checked on “import previews”, a second option should be available: “For referenced images left in their original location, place version previews in the same folder as the master image to allow for automatic stacking”. Check this ON, too.
 
In short: import previews ON, leave referenced files in current location ON, place version previews in same folder as masters ON. Really, ALL options are checked ON.
 
Screen Shot 2020-07-04 at 5.29.38 PM
 
Click “OK”. As a check, you should see that the “Disk space required” value should be small, indicating no additional space for the masters will be used. It should just be the additional space to accomodate the previews.
 
It will return you to the first window, where you can click “Import” to start the import. How long it takes seems to depend on the number of images in the library. I didn’t time any of the imports, but a few thousand masters with maybe a thousand previews took maybe 2 or 3 hours. Certainly not the multiple days that a naïve import took.