[GUIDE] Gigabyte Brix BKi3HA-7100 - Install Mojave

[RehabMan]

@RehabMan I didn't change anything regarding port addresses. The ports that are problematic are not on XHC14 they appear under PR01 and they appear to be problematic before a SSDT-UIAC is created or applied or indeed USBInjectAll.kext loaded - please see the attached IOReg output, this was before I installed USBInjectAll.kext and before I created a SSDT-UIAC. Indeed the SSDT-UIAC I modified later was only modified as attached.

SSDT-UIAC.aml has no effect without USBInjectAll.kext.
Refer to the guide:
https://www.tonymacx86.com/threads/guide-creating-a-custom-ssdt-for-usbinjectall-kext.211311/

 

[the_gael]

@RehabMan I think you have not understood what I am saying. I understand that SSDT-UIAC will not work without USBInjectAll.kext. What I am saying is that the issue is not with the ports listed under XHC14 in IOReg, the issue is with the ports listed under PR01 - they appear to be problematic. These are the USB 3.1 ports that are not affected by the SSDT-UIAC. The issue is not related to the SSDT.

The ports on XHC14 are all working correctly.

 

[RehabMan]

@RehabMan I think you have not understood what I am saying. I understand that SSDT-UIAC will not work without USBInjectAll.kext. What I am saying is that the issue is not with the ports listed under XHC14 in IOReg, the issue is with the ports listed under PR01 - they appear to be problematic. These are the USB 3.1 ports that are not affected by the SSDT-UIAC. The issue is not related to the SSDT.

The ports on XHC14 are all working correctly.

I see no USB related PR01 in the ioreg you attached.

 

[the_gael]

I see no USB related PR01 in the ioreg you attached.

Edited to add - apologies - just spotted that I had referred to PR01 and not RP01 - DUH!!!!
This is the section of the IOREG output I am referring to - in the screenshot attached you will see that there is a USB drive attached to RP01@1C > PXSX@0 > PXSX@00100000 > HS02@00200000

I think there is an issue - when you connect a USB3 device it will show up there on HS01 or HS02 depending on which port you connect to. If you connect a USB2 device it will appear on SS01 or SS02. I believe that these are the wrong way round (but of course my understanding might be limited). I would have expected the USB2 device to appear as HS01 or HS02 and the USB3 device to appear as SS01 or SS02.

The wifi part of the m.2 module shows up below that on RP06@1C,5 whilst the Bluetooth part of the m.2 module shows up under XHC@14 > HS07.

I don't know if that is normal or not - I sort of expected that both parts of a single module would show up under the same place.

While the wireless part continue to work after a long period of sleep the Bluetooth loses connection and will not establish a reliable connection.

I am about to try again with the new BT/Wifi module BCM94352Z but wanted clarification from you whether that USB under RP01@1C is an issue or not.

 

[the_gael]

@RehabMan An UPDATE
I have re-installed the BCM94352Z and applied the AirportBrcmFixup.kext and I have also modified (as previously discussed) the kext you wrote for the Front USB ports USB_XHC_RP01_PXSX.kext to reflect that the top port is USB-C.

Bluetooth and Wifi working well - and Wake from Sleep with Bluetooth (Apple Magic Keyboard 2) works well,
I have disabled hibernation as I suspected that was causing the issue with Bluetooth not working after an extended sleep which I had seen previously (I will test that later today).

Initially after installing the USB_XHC_RP01_PXSX.kext the top port at the front the USB-C was not working at all. However after a hard boot the top port started working - I suspect that maybe some cached info was what the issue was but I do not know for sure. I have also discovered that on the front two ports USB3 HDD's are recognised on HS ports under RP01@1C > PXSX@0 > PXSX@00100000 while USB2 Flash sticks are recognised on SS ports and USB3 Flash sticks on HS ports. As discussed previously in this thread USB devices are improperly unmounted at sleep.

these issues however are not so major for me, although the devices are seen in odd places in IOReg the HDD disk performance is the same RP01@1C > PXSX@0 > PXSX@00100000 > HS02@00200000 or under XHC@14 > SS03@14400000 (see attached Disk Speed screenshots). The un-mounting issue at sleep has at least two workarounds (as previously discussed).

 

[RehabMan]

Edited to add - apologies - just spotted that I had referred to PR01 and not RP01 - DUH!!!!
This is the section of the IOREG output I am referring to - in the screenshot attached you will see that there is a USB drive attached to RP01@1C > PXSX@0 > PXSX@00100000 > HS02@00200000

I think there is an issue - when you connect a USB3 device it will show up there on HS01 or HS02 depending on which port you connect to. If you connect a USB2 device it will appear on SS01 or SS02. I believe that these are the wrong way round (but of course my understanding might be limited). I would have expected the USB2 device to appear as HS01 or HS02 and the USB3 device to appear as SS01 or SS02.

The port addresses are likely wrong in ACPI (or wrong in a port injector you're already using?). You could correct them by injecting "ports" (USB port injector kext, or with USBInjectAll.kext injector kext).
But as long as they work, the names assigned to the ports don't really matter.

 

[the_gael]

The port addresses are likely wrong in ACPI (or wrong in a port injector you're already using?). You could correct them by injecting "ports" (USB port injector kext, or with USBInjectAll.kext injector kext).
But as long as they work, the names assigned to the ports don't really matter.

@RehabMan I suspect they are wrong in ACPI as when I checked before using USBInjectAll or the USB port injector you sent me they were wrong then as well. Do you think its possible that the issues I see with devices un-mounting improperly at sleep could be related to these settings being wrong in ACPI?

 

[RehabMan]

Do you think its possible that the issues I see with devices un-mounting improperly at sleep could be related to these settings being wrong in ACPI?

Could be.
Try setting correct UsbConnector values and get the port names/port addresses right.

 

[the_gael]

Could be.
Try setting correct UsbConnector values and get the port names/port addresses right.

I edited the Port Injector Kext you sent me previously, with the appropriate UsbConnector values, port names and port addresses and the USB HDD's and USB flash drives now show as expected in IOReg on the correct ports. Thank you! Unfortunately it has not resolved the un-mounting at sleep issue.

Currently the only outstanding issues with the BRIX are the un-mount after sleep on Front USB and when Display is attached via HDMI the screen and Audio will not come back to life after sleep until Inputs are cycled on the display i.e. selecting a different input and then reverting to the one the Brix is connected to. When connected via Displayport adapter there is no issue - I believe this is expected behaviour and I would need to change framebuffers to allow the HDMI to work correctly.

I have installed Jettison at present as I have a licence for it. I will however look at the other solution you suggested as I believe that did not require a licence and therefore more appropriate if it was to be distributed via your repository as part of an automated process for this generation of Brix.

I have found no more issues, however could you do a checkover of my config.plist and see if there are any issues or indeed further recommendations you would make.

 

[the_gael]

There is another work around involving SleepWatcher. You can probably find it by search.

@RehabMan I found Sleepwatcher and have downloaded and installed it - the next step is beyond my scripting knowledge, that is to write a shell script that Sleepwatcher will execute to unmount USB HDD's on sleep - in fact preferably only those USB HDD's that are on RP01@1C - are you aware of a script that does this or could be modified to do this?