HP EliteDesk 800 G4 / G5 Mini with RX560x dGPU (hackintosh)

[ird]

2 hours ago, deeveedee said:

@ird Thanks for testing.  Overriding the default device-id should be unnecessary and seems rather arbitrary - what is your reasoning for changing device-id?

 

You can inspect IOReg with and without DAGPM.kext to see if it is needed (make sure AGPM is properly loaded for both iGPU and dGPU).  iMac19,2 offers a RX 560x option, so native iGPU and dGPU power mgmt may be fully supported for SMBIOS iMac19,2 without DAGPM.kext, but you can test if you want to.  After my initial testing where I was still refining my proposed EFI, I didn't see any behavioral differences with/without DAGPM.kext when I tested iMac19,2 SMBIOS.  Note that the DAGPM.kext that I provided for SMBIOS iMac19,2 is different from the DAGPM.kext that I provided for MacMini,8,1.  I know you know this, but just stating for others who may want to test.

 

For device-id force, the reason was that the iGPU was being detected as Intel KBL Unknown (I think it was GB6 and few other apps, though VideoProc correctly detected it as Intel UHD Graphics 630). But forcing device id fixed it in all apps. I do not yet know if there is any side effect of this. I will test further.

 

About SMBIOS being embedded in DAGPM.kext, yes - I read thru the kext plist and saw that and made sure I used the correct version. But thank you for the thoughtful reminder! I did confirm that for dGPU AGPM showed up in IOReg even without the kext to your point about OOB support for RX560. However, I don't remember if that was true for iGPU. I will check later today to confirm.

 

One interesting observation I made about Intel iGPU (irrespective of whether I used MacMini8,1 or iMac19,2 SMBIOS) is that I suspect something funky is going on with the GuC firmware esp. during video playback. My scenario is if I load Apple GuC firmware (igfxfw=2 boot-args and confirmed with Hackintool boot logs that Apple Firmware 2.18.xx is loaded), play a HW-accelerated video on Youtube (as described elsewhere in the thread), Intel Power Gadget shows iGPU AVG clocks dancing around (ranges from 0.11-0.45Ghz for most of the times, the 1.15Ghz I reported above seems to be a one-off anomaly) with iGPU REQ(uested clock) stuck at 1.15Ghz. But the key point is that the iGFX AVG is very dynamic.

 

On the other hand, if I don't load Apple GuC firmware (no igfxfw=2 in boot-args and confirmed with Hackintool boot logs that "Host preemptive firmware" is loaded), then while playing the same video on Youtube, the iGPU AVG clocks are a very steady 0.33Ghz with iGPU REQ maxing out at 0.35Ghz. iGPU never crosses 0.35Ghz in any case here. This behavior though consistent with dGPU steady peak clocks in Chrome/Edge make me doubt, if in the case above with Apple firmware, the iGPU is indeed being used. It could all turn out to be purely cosmetic because of sampling frequency differences between the 2 firmwares or even the 2 monitoring tools.

 

I also read somewhere that Inte's 22nm chipsets like Z370 do NOT support Apple GuC firmware. Q370, I thought, was essentially the same chipset with a few more enabled features. Looking at above behavior, I can't say that Apple GuC firmware doesn't work at all on this chipset but also cannot conclude that it's working as it should.

 

Anybody willing to test this out if behavior is same on your system?

[deeveedee]

See this thread for GuC firmware tests.  I think we concluded our discussions with as many opinions and conclusive results as there were participants.

[deeveedee]

For anyone who'd like to help test a revised EFI that does not alter DMAR - please see here.

 

EDIT: After disabling the DMAR table drop/add in my EFI, I am seeing consistently better (albeit slightly better) GeekBench 6 Metal Benchmarks (and the results are consistent in repeat tests).  I don't understand this and would like to see the results from others.

 

Spoiler

 

Edited July 18 by deeveedee

[ird]

9 hours ago, deeveedee said:

See this thread for GuC firmware tests.  I think we concluded our discussions with as many opinions and conclusive results as there were participants.

 

This thread seems to have a wealth of information! Let me try to digest all that information and try out a few things.

[ird]

Changing topics a bit. I think after fiddling with DRM, iGPU, dGPU for many days I'm ready to conclude this investigation. To enable DRM (Apple TV - fairplay 4.x I tihnk), the only way is to prevent anything running in iGPU. macOS really doesn't like non-Apple Intel iGPUs. 

 

Use the following command to force macOS to not use iGPU and enable DRM.

defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

and...

 

defaults write com.apple.coremedia hardwareVideoDecoder -string force

 

This unfortunately disables all video decoding on iGPU. This means I need to pick between DRM and low power intel quicksync. Choices... choice. This is a tough one.

 

For those use MacMini8,1 SMBIOS - give this a shot as well in case it work. In my case iGPU is configured as headless, so it wasn't "online" from macOS perspective to start with. With forcing RX560 video decode, I've practically neutered the iGPU, making it completely useless. I might as well disable it in BIOS if I don't use multi-display... 

 

[deeveedee]

After powering down  overnight, I powered-up and ran another GB6 metal benchmark with DMAR drop/add removed from my EFI.  The benchmark increased yet again (slightly).

 

Spoiler

 

I can say with a fair degree of certainty that removing the DMAR table modification has improved my GB6 Metal benchmark.  My SMBIOS continues to be SMBIOS MM8,1.

 

EDIT: @ird Your DRM testing conclusion is consistent with other hackintosh tests that I have seen.

 

EDIT2: @ird This thread by @rafale77 is one of the most comprehensive investigations of hack DRM that I know of.  There are others I'm sure.

Edited July 18 by deeveedee

[ird]

4 hours ago, deeveedee said:

After powering down  overnight, I powered-up and ran another GB6 metal benchmark with DMAR drop/add removed from my EFI.  The benchmark increased yet again (slightly).

 

  Reveal hidden contents

 

I can say with a fair degree of certainty that removing the DMAR table modification has improved my GB6 Metal benchmark.  My SMBIOS continues to be SMBIOS MM8,1.

 

EDIT: @ird Your DRM testing conclusion is consistent with other hackintosh tests that I have seen.

 

EDIT2: @ird This thread by @rafale77 is one of the most comprehensive investigations of hack DRM that I know of.  There are others I'm sure.

 

Thank you! I shall read through the thread to see if there is something I might have missed as an option.

 

Re: GB6 scores - not sure if this is an interesting data point but your first post indicates that with RX560X GB6 Metal scores were around 23K in 14.5 and without the DMAR patch it boosted to 23.7K with MacMini8,1 SMBIOS. Things were a bit different for me. To start with, GB6 GPU Metal scores have always been 23.5K +/- 100 for me. I wonder if that has to do something with macOS natively handling power management for RX560 in an optimal way. Of course, I have no explanation for why scores dropped without the DMAR patch (needs more investigation).

 

EDIT1: @deeveedee I'm curious which memory regions does your DMAR patch modify. Could it have to do something directly or indirectly with dGPU? It would make sense for iGPU to be impacted if that was purely related to VT-d due to shared memory but dGPU isn't so obvious. Anything with PCIe BAR/DMA?

Edited July 18 by ird

[deeveedee]

@ird See this.

[ird]

8 hours ago, deeveedee said:

@ird See this.

 

Thanks, deeveedee. I stand corrected. Late last night I probably mixed up the USB keys that were booting different versions of config.plist. I can indeed reproduce your results. Sorry for the confusion and misleading results. The ~23.5K GB6 metal score turned out to be without any DMAR patching (using motherboard's OG one). I need to compare the one with 18K score what changed there. Probably not worth debugging as it's moot but I may just out of curiosity.

 

One difference though, I observed when I dump the system DMAR is that your unpatched DMAR from the thread you linked above does not seem to contain memory region for PCIE 14,0 (which I believe is USB that you still need to patch?). The unmodified one that opencore loads for me has a reserved region for USB, iGFX and PCIe 16,7 and my machine so far seems to work ok. The size also is correspondingly larger (0xC8 for me vs. 0xA8 for you in the attached OG DMAR in that thread. I admit that I probably haven't tested long enough added to the fact that my iGFX is headless and hence may not be seeing any issues. My USB seems to work ok for now.

 

Anyway, I'm attaching my dumped OG DMAR (unpatched) that opencore loads for perusal if that's useful. Wifi etc. all seem to work fine for me without patching. I don't have LAN to test though.

 

EDIT1: I'll try to respond to this thread only and not the other one you linked to avoid clutter and confusion there and will allow you to continue. Meanwhile, out of curiosity, what is the PCIe device ID 16,7 that you have deleted from your patch?

 

DMAR_HP_800G4DM_Q370_iMac19p2.aml

Edited July 19 by ird

[deeveedee]

@ird Thank you.  I'll review my original ACPI again.  The original should contain the XHCI Region (PCIE 14,0) which is the whole point of the modified DMAR.  I'll look at the other thread again.  Maybe I accidentally copied the wrong file.  Glad you were able to duplicate the test results.  I'm currently running without any DMAR patching on my G4 Mini and it works great.  I haven't yet tested on my G5 Mini.

 

Also, I'll need to review my DMAR patches again when I have time.  I'll update this post with the info.  I do remember reviewing the extracted ACPI from a real MacMini8,1 to help with my patching decision.  If you review the other thread, you'll see the original MM8,1 DMAR table.

 

EDIT: @ird Thank you for reviewing my posted files.  I did indeed accidentally attach the wrong file.  I have corrected this post so that It now attaches the correct original-DMAR table.  Thank you again.

 

EDIT2: @ird Here is Dortania's currently recommended DMAR patching.  The docs suggest that all Reserved Regions should be dropped from the DMAR table.  As I posted here, the original MM8,1 DMAR table still has a Reserved Region (so dropping all ReservedRegions is probably incorrect).  According to Mieze in the other thread, revising DMAR may have unintended consequences.  It does appear that our EliteDesk 800 G4 Mini does not need any DMAR table mods to allow enabled VT-d with macOS.  For those who do need to modify DMAR, maybe only XHCI @14,00 needs to be dropped from the DMAR table (leaving the other Reserved Regions).  I'll continue to follow the other conversation out of curiosity, but at this time, it does appear that DMAR patching is not relevant to our hacks.

Edited July 19 by deeveedee

[ird]

3 hours ago, deeveedee said:

@ird Thank you.  I'll review my original ACPI again.  The original should contain the XHCI Region (PCIE 14,0) which is the whole point of the modified DMAR.  I'll look at the other thread again.  Maybe I accidentally copied the wrong file.  Glad you were able to duplicate the test results.  I'm currently running without any DMAR patching on my G4 Mini and it works great.  I haven't yet tested on my G5 Mini.

 

Also, I'll need to review my DMAR patches again when I have time.  I'll update this post with the info.  I do remember reviewing the extracted ACPI from a real MacMini8,1 to help with my patching decision.  If you review the other thread, you'll see the original MM8,1 DMAR table.

 

EDIT: @ird Thank you for reviewing my posted files.  I did indeed accidentally attach the wrong file.  I have corrected this post so that It now attaches the correct original-DMAR table.  Thank you again.

 

Thanks! I'll keep an eye on your post if you learn something new.

 

Digressing a bit. Is it possible to provide the USB port mapping as SSDT instead of manual mapping+KEXT? I ask this that it would make switching SMBIOS for testing a bit less painful, esp. when you are debugging and you have to switch multiple times a day (and you find out you missed it and USB doesn't work anymore). I thought I read somewhere you could do that in AML but can't remember.

[deeveedee]

@ird Read about how to use Hackintool to create a USB port map that uses USBInjectAll.kext with an SSDT.

 

EDIT: @ird What you may also want to look at is how to create a USBPorts.kext that includes entries for multiple SMBIOS models.  I haven't done it for USBPorts.kext when I was testing MM8,1, iM19,1 and iM19,2, but I did it for DAGPM.kext and it was fairly easy.

Edited July 19 by deeveedee

[deeveedee]

Here's an exercise for anyone who wants to test their ACPI patching skills.  In my posted EFI for this hack, my config.plist includes the following ACPI patch:

Spoiler

 

When I created this patch (to change TPM._STA to TPM.XSTA so that I could define a new TPM._STA that drops TPM in macOS), I didn't include an OemTableId, so my Find and Replace bit patterns needed to be exclusive to TPM._STA (so that other Device _STAs remained untouched).  This required me to expand the Find and Replace bit patterns until they were specific to only the one instance of _STA that I wanted to replace.  A more efficient way to implement this patch is to define the OemTableId in the ACPI > Patch rule, so that OpenCore searches only the one correct ACPI Table to apply the patch (with my current patch, Open Core searches all ACPI tables, looking for the Find bit pattern).  With the OemTableId specified, the Find and Replace bit patterns could be significantly shorter and Open Core would only need to search in the one applicable ACPI Table.  The tools you will need for this exercise are your preferred method for extracting original ACPI (I use CLOVER boot loader), a hex editor (I use hexfiend), an ASCII->Hex converter (I use Hackintool's Calc utility) and MaciASL.  Here's a hint: TPM._STA is defined in SSDT-8-Tpm2Tabl.aml.

 

If anyone implements the revised patch, the patching behavior (and thus your hack's behavior) should remain unchanged.

 

Have fun!

 

EDIT: Note that I could keep my original patch (with the full Find and Replace bit sequences) and simply change the Count (from 0 to 1) and the OemTableId.  This would be an easy way to implement the change, but not as much of a learning experience as also modifying the Find and Replace bit sequences.

 

EDIT2: My preferred reference for ACPI patching (the thread that I read over and over when I was learning) is by the hacking legend Rehabman here.

 

EDIT3: If you enjoyed your ACPI patching exercise and want more, add TableSignatures to the _PTS, _WAK and _OSI patches (hint: they're all defined in the same ACPI table).

Edited July 20 by deeveedee

[deeveedee]

While I was playing with the exercise I described in my previous post, I found an issue with my _PTS -> XPTS ACPI patch.  See here.  Note that I did not observe any behavior problems resulting from my original _PTS -> XPTS patch.  This new patch ensures that only the desired replacement is performed.

 

EDIT: I think it is awesome that there is still more to learn about hacking.  It's one of the reasons that I enjoy it so much.  Here is a new lesson learned for me that might help others.

Edited July 20 by deeveedee

[ird]

On 7/19/2024 at 9:04 AM, deeveedee said:

@ird Read about how to use Hackintool to create a USB port map that uses USBInjectAll.kext with an SSDT.

 

EDIT: @ird What you may also want to look at is how to create a USBPorts.kext that includes entries for multiple SMBIOS models.  I haven't done it for USBPorts.kext when I was testing MM8,1, iM19,1 and iM19,2, but I did it for DAGPM.kext and it was fairly easy.

 

Thank you for the pointers, @deeveedee!

 

I'm attaching a multi-SMBIOS USBPorts kext in case anybody is interested. It should work for MacMini8.1, iMac19.1 and iMac19.2. In my case, I've replaced the original USBPorts.kext with USBPorts_MultiSMBIOS.kext (attached) and modified config.plist for clarity but feel free to rename it to USBPorts.kext and drop in as an existing replacement.

 

EDIT1: This adheres to the 16-port macOS limit but 1 of the ports is reserved for Internal USB BT; so, 15 usable USB ports.

 

 

USBPorts_15p1_MultiSMBIOS.kext.zip

Edited July 20 by ird

[deeveedee]

@well done, @ird ! well done.  Do we still need to edit the Info.plist to comply with the 15-port USB port limit, or did you also find a way around that?  If it needs to be edited, maybe call it USBPorts-16-MultiSMBIOS.kext?  Your call.

Edited July 20 by deeveedee

[miliuco]

@ird

Interesting! Never thought of a multi SMBIOS ports map file. Useful.

[deeveedee]

With my last ACPI Patch fix here and the removal of the DMAR patch here, my Open Core ACPI patches are completely transparent to Windows (my SSDTs include the _OSI conditions) and both TPM and VT-d are now enabled in BIOS. This means that booting Windows with Open Core should work well on this hack (if I force Windows 11 to install without Secure Boot). Since this hack has only one m.2 NVMe SSD (space limitation because of the RX 560x), I plan to install Windows 11 and macOS on the same SSD.  In the past, I have always booted Windows and macOS from different physical SSDs (selecting the boot drive with F9), but this guide may offer a solution.  

 

Has anyone successfully created a dual-boot solution (Windows / macOS) on a single SSD and if so, do you have any other suggested references?

Edited July 20 by deeveedee

[ird]

29 minutes ago, deeveedee said:

@well done, @ird ! well done.  Do we still need to edit the Info.plist to comply with the 15-port USB port limit, or did you also find a way around that?  If it needs to be edited, maybe call it USBPorts-16-MultiSMBIOS.kext?  Your call.

 

Sorry, I forgot to mention that in the post. Thank you for noticing this! This adheres to the 16-port macOS limit but 1 of the ports is reserved for Internal/USB; so, 15 usable USB ports. Updated the original post and renamed the extension to indicate 15+1.

[ird]

7 minutes ago, deeveedee said:

With my last ACPI Patch fix here and the removal of the DAGPM patch here, my Open Core ACPI patches are completely transparent to Windows (my SSDTs include the _OSI conditions) and both TPM and VT-d are now enabled in BIOS. This means that booting Windows with Open Core should work well on this hack (if I force Windows 11 to install without Secure Boot). Since this hack has only one m.2 NVMe SSD (space limitation because of the RX 560x), I plan to install Windows 11 and macOS on the same SSD.  In the past, I have always booted Windows and macOS from different physical SSDs (selecting the boot drive with F9), but this guide may offer a solution.  

 

Has anyone successfully created a dual-boot solution (Windows / macOS) on a single SSD and if so, do you have any other suggested references?

 

Actually, I've used non-patched DMAR, _PTS previous patch versions of EFI to successfully boot into and use Windows 11 Pro. I've never used DAGPM.kext, so can't comment on that. But I've never had any issues in WIndows. It's a shame that the 2nd NVMe slot becomes unusable if you have M.2 Wifi as well with the dGPU attached. So, I use an external NVMe-to-USB adapter and have my Windows 11 installed there and I boot into it when I need it (which isn't as frequent as macOS is my daily driver).

 

I've had Windows mess up partition table before so I did not go the route of repartitioning the same SSD and have macOS and Windows on it. Not worth the hassle for me to spend time to repair if that happens again (not saying it will).

[deeveedee]

@miliuco According to your post here, XHCIPortLimit has been fixed in Open Core, so we can have more than 15 ports again.  I never knew this.  Is it true that we no longer have a 15-port USB port limit?  Is there any downside to enabling the XHCIPortLimit Quirk and having a USB Port map with more than 15 ports?

 

EDIT: I just read PMHeart's post following yours here.  I'll stick with my 15-port USB maps for production use.

Edited July 20 by deeveedee

[ird]

On 7/17/2024 at 8:34 PM, ird said:

Changing topics a bit. I think after fiddling with DRM, iGPU, dGPU for many days I'm ready to conclude this investigation. To enable DRM (Apple TV - fairplay 4.x I tihnk), the only way is to prevent anything running in iGPU. macOS really doesn't like non-Apple Intel iGPUs. 

 

Use the following command to force macOS to not use iGPU and enable DRM.

defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

and...

 

defaults write com.apple.coremedia hardwareVideoDecoder -string force

 

This unfortunately disables all video decoding on iGPU. This means I need to pick between DRM and low power intel quicksync. Choices... choice. This is a tough one.

 

For those use MacMini8,1 SMBIOS - give this a shot as well in case it work. In my case iGPU is configured as headless, so it wasn't "online" from macOS perspective to start with. With forcing RX560 video decode, I've practically neutered the iGPU, making it completely useless. I might as well disable it in BIOS if I don't use multi-display... 

 

 

An update on this topic - iGPU video decode and DRM. The solution I settled with is a bit hacky but it's ok. I have 2 shell scripts that force enable/disable dGPU video decode when I need DRM (yeah, I'll live with this). I just force enable HW video decoder in case something else might have disabled this. This is not necessary and only precautionary.

 

Turn-on:

#!/bin/sh
# drm_on.sh
defaults write com.apple.coremedia hardwareVideoDecoder -string force
defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

Turn-off:

#!/bin/sh
# drm_off.sh
defaults write com.apple.coremedia hardwareVideoDecoder -string force
defaults write com.apple.AppleGVA gvaForceAMDKE -boolean no

In addition, adding the following properties to iGFX-headless FB enables a new tab in Activity Monitor for GPUs:

 

                <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
                <dict>
                    <key>AAPL,ig-platform-id</key>
                    <data>AwCRPg==</data>
                    <key>AAPL,slot-name</key>
                    <string>Built-in</string>
                    <key>device-id</key>
                    <data>mz4AAA==</data>
                    <key>enable-metal</key>
                    <data>AQAAAA==</data>
                    <key>igfxfw</key>
                    <data>AgAAAA==</data>
                </dict>

Explanation:

• ig-platform-id: corresponds to headless FB for CFL
• slot-name: enables the Activity monitor tab
• enable-metal: because RX560X supports Metal2 only (there seems to be some confusion on this with respect to Polaris family in general on 2 vs 3), force enabling metal on iGPU makes the headless device available for compute tasks in addition to video in apps like GB6 etc.
• device-id: purely cosmetic as I understand but shows the correct gpu name in Activity monitor, GB6 and elsewhere
• igfxfw: loads Apple GuC firmware for power management. I prefer to put this in device properties, but you can use boot args. Alternatively, you can also use "rpc-control=0x01000000" (data type) in lieu of igfxfw device property to load non-apple firmware for power management

 

The result of all this is the new tab as shown in the attached picture that clearly indicates what task runs on what GPU to avoid any confusion. With a number of tools like HWMonitorSMC2, Intel Power Gadget, Activity Monitor in the arsenal now there is no more guessing on device utilization and telemetry.

 

Hopefully this will be useful to someone...

 

EDIT1: forgot to attach the GB6 picture that enables headless iGPU for Metal tasks.

 

EDIT2: Corrected typos and updated image.

 

EDIT3: I also just learned that the GPU tab can be force enabled with this command:

 

defaults write com.apple.ActivityMonitor ShowGPUTab -bool true

 

Edited July 21 by ird

[miliuco]

39 minutes ago, deeveedee said:

@miliuco According to your post here, XHCIPortLimit has been fixed in Open Core, so we can have more than 15 ports again.  I never knew this.  Is it true that we no longer have a 15-port USB port limit?  Is there any downside to enabling the XHCIPortLimit Quirk and having a USB Port map with more than 15 ports?

 

EDIT: I just read PMHeart's post following yours here.  I'll stick with my 15-port USB maps for production use.

Both statementes are correct (afaik).

XHCIPortLimit quirk is working again but it's not for daily use. From my post (got from OpenCore texts):

Quote

The instructions for its use have not changed: avoid having the quirk activated on a regular basis, activate it only if it is necessary for some task (for example, mapping USB ports). Even with the quirk activated, it is necessary to inject some kext that provides information about the USB ports (USBInjectAll.kext or USBToolBox.kext + UTBMap.kext or USBMap.kext or USBPorts.kext with all USB ports enabled).

 

Edited July 20 by miliuco
Fix typo

[deeveedee]

@ird Were you able to learn from any of the work that @rafale77 was doing here?

[joevt]

47 minutes ago, deeveedee said:

@miliuco According to your post here, XHCIPortLimit has been fixed in Open Core, so we can have more than 15 ports again.  I never knew this.  Is it true that we no longer have a 15-port USB port limit?  Is there any downside to enabling the XHCIPortLimit Quirk and having a USB Port map with more than 15 ports?

 

EDIT: I just read PMHeart's post following yours here.  I'll stick with my 15-port USB maps for production use.

One reason for the 15 port limit is because the location ID of USB devices uses a single hex digit for each level. I think the controller level uses two digits.

 

ioreg -i | perl -nE 'if (/\+-o \w+@(\w+).*AppleUSBHost(Controller|Port)/) { printf("%s: %s\n",$1,$2) }' | sort | uniq -c
   1 00000000: Controller
   1 00100000: Port
   1 00200000: Port
   1 00300000: Port
   1 00400000: Port
   1 14000000: Controller
   1 14100000: Port
   1 14110000: Port
   1 14111000: Port
   1 14112000: Port
   1 14113000: Port
   1 14120000: Port
   1 14130000: Port
   1 14140000: Port
   1 14141000: Port
   1 14141100: Port
   1 14141200: Port
   1 14141300: Port
   1 14141400: Port
   1 14142000: Port
   1 14143000: Port
   1 14200000: Port
   1 14300000: Port
   1 14400000: Port
   1 14500000: Port
   1 14600000: Port
   1 14700000: Port
   1 14800000: Port
   1 14900000: Port
   1 14a00000: Port
   1 14a10000: Port
   1 14a20000: Port
   1 14a30000: Port
   1 14a40000: Port
   1 14a41000: Port
   1 14a41100: Port
   1 14a41200: Port
   1 14a42000: Port
   1 14a43000: Port
   1 14b00000: Port
   1 14c00000: Port
   1 14d00000: Port
   1 14e00000: Port
   1 14f00000: Port
   1 40000000: Controller
   1 40100000: Port
   1 40200000: Port