Mapping USB Ports Discussions

[Guest 5T33Z0]

Ah, I see. So you renamed the methods so they play along with the entries present in the DSDT.

Edited July 30, 2022 by 5T33Z0

[rafale77]

In addition to my previous post, I am also seeing this in my DSDT:

 

 

Which makes me wonder why there is even a need to modify the GUPC method to take two arguments when one could just use the TUPC method for all ports to be enabled and just define their connectors and the original GUPC with a zero argument to disable them.

[Guest 5T33Z0]

@rafale77 Well you could just use a template which only uses the methods you need as well.

 

SSDT-PORTS-Start.aml

 

Adjust:

• Definition Block as required for your system
• Name of methods as required for your DSDT

 

 

[datafeedexpert]

2 hours ago, rafale77 said:

@deeveedee, You can look at how it is defined in your ACPI (DSDT or SSDT). I have the exact same situation on my Lenovo and my DSDT defines this physical port as three ports HS04, SS04 and SS08 and all three of them are defined as type 0x0A = 10.

 

@datafeedexpert, I agree with everything you said and believe it is already what I am doing. I must really be blind to something. I will take your generous offer. I have even increased the number of methods in XHC and RHUB to reproduce what I found in my DSDT. See attached.

 

SSDT-USB.aml 3.81 kB · 2 downloads

I think you just prepared well your SSDT-USB Looks perfect , is this original SSDT which is dumped from your hardware ?, also try DROP OEM Table with OC , which well describe in @5T33Z0 Guide  

Edited July 30, 2022 by datafeedexpert

[rafale77]

39 minutes ago, datafeedexpert said:

I think you just prepared well your SSDT-USB Looks perfect , is this original SSDT which is dumped from your hardware ?, also try DROP OEM Table with OC , which well describe in @5T33Z0 Guide  

Thanks, I unfortunately cannot drop the OEM table because it is not in a SSDT, it is in the DSDT.

I also had an epiphany... I wonder why I am even having to map my USB ports since my ACPI declares less than 15 ports... Well when I don't do mapping or reset RHUB, I see all my ports correctly but they are all defined as internal connectors in MacOS which I don't understand because it isn't what the ACPI says. And strangely all ports appear to work except for the internal one. This is really bizarre. Something must be happening in between.

 

Thanks @5T33Z0, I will take a look.

[Guest 5T33Z0]

@rafale77 Yeah, well remember the premises: GUPC must return 2 Packages (arg0 AND arg1) – but your DSDT doesn't have arg1 and that's why they are not declared correctly in terms of connection type. If everything is working, don't bother.

 

If it does bother you – it seems this way - you have to write a SSDT with a lot of scopes into this USB esction of the DSDT to inject arg 1 to all the ports with the correct return values for each USB port.

[rafale77]

45 minutes ago, 5T33Z0 said:

@rafale77 Yeah, well remember the premises: GUPC must return 2 Packages (arg0 AND arg1) – but your DSDT doesn't have arg1 and that's why they are not declared correctly in terms of connection type. If everything is working, don't bother.

 

If it does bother you – it seems this way - you have to write a SSDT with a lot of scopes into this USB esction of the DSDT to inject arg 1 to all the ports with the correct return values for each USB port.

 

That's not how I am reading the code. Actually GUPC only returns one package "PCKG" and Arg0 and Arg1 are modifying the 4 byte package.

                Method (GUPC, 1, Serialized)
                {
                    Name (PCKG, Package (0x04)
                    {
                        Zero, 
                        0xFF, 
                        Zero, 
                        Zero
                    })
                    PCKG [Zero] = Arg0
                    Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.GUPC.PCKG */
                }

 

In this code, Byte 0 is defaulted to zero (enable byte) and Byte 1 is defaulted to 0xFF (connector type)

The PCKG[Zero]=Arg0 modifies the PCKG to change its first byte allowing you to enable or disable the package.

 

                Method (TUPC, 1, Serialized)
                {
                    Name (PCKG, Package (0x04)
                    {
                        One, 
                        Zero, 
                        Zero, 
                        Zero
                    })
                    PCKG [One] = Arg0
                    Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.TUPC.PCKG */
                }

TUPC on the other hand only changes the second byte PCKG[One] which is the connector type and defaults the port using this method to "enabled".

We technically do not need to modify both bytes of the package at the same time since we are either disabling a port or enabling it with a connector type. There is no reason to change a connector type for a disabled port (keep it at the default 0xFF) and there is no reason to disable a port for which we want to customize the connector... So one either needs TUPC or GUPC. We don't need to modify GUPC to modify both bytes of the package.

 

This is exactly how my DSDT is written and behavior matches perfectly with the code. I am a newb to ACPI so maybe I am missing something...

 

 

[Guest 5T33Z0]

@rafale77 Well, you are reading it wrong. You only have 1 return PCKG in your metod, BUT you need 2.

 

THIS is the correct Code:

Method (GUPC, 2, Serialized)
{
	Name (PCKG, Package (0x04)
	{
        	0xFF,
        	0x03,
        	Zero, 
    		Zero
   	})
	PCKG [Zero] = Arg0
	PCKG [One] = Arg1 // <<<< YOU NEED THIS as WELL
	Return (PCKG) /* \GUPC.PCKG */
}

 

[rafale77]

10 hours ago, 5T33Z0 said:

@rafale77 Well, you are reading it wrong. You only have 1 return PCKG in your metod, BUT you need 2.

 

THIS is the correct Code:

Method (GUPC, 2, Serialized)
{
	Name (PCKG, Package (0x04)
	{
        	0xFF,
        	0x03,
        	Zero, 
    		Zero
   	})
	PCKG [Zero] = Arg0
	PCKG [One] = Arg1 // <<<< YOU NEED THIS as WELL
	Return (PCKG) /* \GUPC.PCKG */
}

 

 

As I explained to you in a PM, I posted the method in my DSDT which work. What you are posting is the modified method which I also used in my test SSDT. I didn't use the one I posted.

I think you are mistaken in your understanding/interpretation of the method.

 

What the method returns is always one PCKG

 

                    Name (PCKG, Package (0x04)
                    {
                        One,    <-- enables or disables the port
                        Zero,   <-- sets the connector type
                        Zero, 
                        Zero
                    })

Clearly the difference is in the number of arguments, not in the return. The modified method enables changing the first two bytes of the return.

 

Based on my DSDT it is unnecessary because there are only two use cases and there are already two methods to fill them:

 

1. Disable the port

2. Enable the port and set the connector.

 

There is no use case for the other 4 possibilities provided by the modified method:

3. Disable a port and set the connector

4. Enable the port and set the connector to disable.

 

Some info I found here https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/install/using-acpi-to-configure-usb-ports-on-a-computer.md

 

 

 

[deeveedee]

I am continue to follow this thread, but have not yet changed my USB patching approach from my current use of USBPorts.kext to an ACPI patch (SSDT).  The kext approach has been working very well for me with Catalina, Montery and Ventura.  Has anyone seen an improvement when changing from kext to ACPI patch and if so, what are the improvements that you have observed?  Thanks.

 

Also, since Catalina, I have not changed the switching types of the logical USB ports associated with my  single Type C physical port.  Based on my explanation here, I have assigned type 0x09 to HS10 and type 0x0A to SS03 and SS04 (different logical switching types on the same physical Type C port).  In my case, I have been unable to find that the use of type 0x09 vs type 0x0A has any affect on the behavior of Type C USB ports in macOS for both USB2 and USB3.  I am curious to know if anyone has observed a change in Type C USB port behavior when experimenting with switching type 0x09 and 0x0A.

[rafale77]

@deeveedee, from my perspective, ACPI patching is a more "vanilla" way to patch because it is patching at a lower level (ACPI/firmware) and does not rely and a kernel extension in the OS. The practical benefit is to make it more resilient and closer to how Apple does it without relying on a kext which could be prone to changes.

 

There has been several approaches which are kext based

1. UIAC kext with an port map SSDT. I am not a fan because it injects non native properties stored in the ACPI through a OS kernel injection. It's a bit complicated.

2. The USBMap.kext and USBPort.kext (from Hackintool) rely on an embedded function (com.apple.driver.AppleUSBMergeNub) of the Apple driver to inject properties and therefore are codeless kexts which only store the port map. Likely what you are currently using.

3. USBToolBox which does the same as the above (in which case it is no different) or with it's own kext to inject the Port properties.

 

There is no other benefit of patching the ACPI over doing it over kext that I know of besides for it to be cleaner/more "vanilla" to macOS.

 

As for the connectors, it appears that windows doesn't care about what the connector type is except if it is USB-C which then has the whole flipping connector thing going on. So on my Lenovo, I can see that the DSDT claims every port to be internal except for the USB-C ports. I don't know what macOS does with it. I am not seeing much either.

Because I only have a total of 14 ports, 13 of which are enabled in my DSDT, I technically should not need to patch since all of my USB3 ports, seen as "internal" by MacOS appear to work fine and so does my USB-C port. But unfortunately, my DSDT disables the internal port for BT and enables it somewhere later through another method which macOS doesn't see so my BT doesn't work without a kext patch. I wish I could find a way to override the _UPC method for that one single device to enable it with an SSDT.

Edited August 1, 2022 by rafale77

[deeveedee]

... so the "Vanilla" debate continues for PCs running macOS.  I am probably one of the most guilty for jumping back and forth across the "Vanilla" fence.

[rafale77]

I wasn't aware that there was a debate raging on. 😄

Of course there is always the nuclear option for the hack which is to go straight to DSDT patching... But that's a hobby by its own.

[deeveedee]

On 8/1/2022 at 12:52 PM, rafale77 said:

I wish I could find a way to override the _UPC method for that one single device to enable it with an SSDT.

 

I'm not sure if this is what you mean, but OC's ACPI patching is very powerful.  Using the Base and Count properties in the ACPI patch (in your config.plist), you can direct OC to rename a single method in your ACPI.  Below is a sample ACPI patch defined in an OC config.plist.  'Base' is fully qualified path of the device that includes the method you want to rename (inspect your DSDT for this) .  'BaseSkip' is the number of instances to skip (I imagine this is 0 for you).  'Count' is the number of instances to rename (1 in your case).  'Find' is the ASCII (Hex) representation of the method name (in your case, _UPC in Ascii Hex).  'Replace' is the new name in Ascii Hex (e.g., XUPC in Ascii Hex). 

 

Renaming the method will then allow you to define your own _UPC in an SSDT that you create and then inject (add the SSDT to the ACPI > Add section in your config.plist).  If you want to multi-boot your rig, make sure your new _UPC includes an _OSI("Darwin") condition that executes the original _UPC (now renamed to XUPC) if you're not running macOS.

 

EDIT: By the way - the example I posted below is very powerful.  I am renaming the _STA method within the device SB.SLPB so that I could create my own new _STA.  Very cool.

 

ACPI Patch Example

Spoiler

 

 

Here's an excerpt from the SSDT that I created to pair with my _STA rename.  Note that I call the original _STA (renamed to XSTA) when not running macOS.

    Scope (\_SB.SLPB)
    {
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            If (_OSI ("Darwin"))
            {
                Return (0x0B)
            }
            Else
            {
                Return (\_SB.SLPB.XSTA) /* External reference */
            }
        }
    }

 

Edited August 3, 2022 by deeveedee

[rafale77]

I was using that OC feature to indeed disable the _UPC function across the DSDT but you showed me how to specifically do it only for a single device. Thank you!

I was succesfully able to disable both the _UPC and the _PLD methods and attempted to replace them in the following SSDT.

 

 

For some reason the entire SSDT will not execute if I add lines 57 and below (The renaming method part). It compiles fine but there must be an error I can't figure out. I am able to see it because the USBX function above works using the same file as soon as I delete the HS14 scoped section.

SSDT-HS14.aml

[rafale77]

Call me crazy but I suddenly had the odd idea to just replace the method GUPC under _UPC with TUPC in HS14 with the OC find and replace method and bang!

 

 

Bluetooth works. TUPC enables the device and its argument instead of being enabled/disabled is the connector type as it enables the port by default. As a result the "internal" port now shows up as USB2.0 which really doesn't matter since the BT device actually connects at USB1 speed and as I discovered the connector type is purely cosmetic as it doesn't appear to make any difference in behavior either in Windows or MacOS... except for USB-C ports.

So I have successfully gotten rid of the port mapping kext but had to put SSDT-USBX back into my ACPI. Still curious as to what was wrong with my previous SSDT though.

 

 

Edited August 3, 2022 by rafale77

[Guest 5T33Z0]

@rafale77 You mean you used a binary rename rule? Nice. I'd try to implement the rename via SSDT for the so it only changes it for macOS so it doesn't affect Windows.

 

I was looking into renaming methods via SSDT. I thought it was as simple as renaming devices but it isn't. Renaming devices via SSDT is relatively easy: you set its status (_STA) to 0 and then just add a replacement device with a new name at the same location to replace it in macOS only and you're done. But you can't disable/rename methods this way, I think – at least I haven't come across a single example that does this. So therefore, using a binary rename with the ACPI path added to the "base" section of the find/replace rule seems to be the cleanest approach.

 

Note: during my tests I realize thath Clover's RenameDevices section can be used for renaming methods. It basically operates based on acpi path of a device/methods – just like the OCs "base" feature but with less options of course.

Edited August 6, 2022 by 5T33Z0

[rafale77]

@5T33Z0,

 

Yes all I did is change one letter to use one method (TUPC) instead of another (GUPC). As I posted above TUPC sets the device type with its one arg while enabling it while GUPC sets the enable bit as its arg while setting the port to internal. See code explanation below

 

                Method (GUPC, 1, Serialized)
                {
                    Name (PCKG, Package (0x04)
                    {
                        Zero,    <-- this will be modified to arg0 below and is the enable byte
                        0xFF,    <-- this is the connector type the method sets to
                        Zero, 
                        Zero
                    })
                    PCKG [Zero] = Arg0 <-- modifies the first index of PCKG using the method's lone argument
                    Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.GUPC.PCKG */
                }

                Method (TUPC, 1, Serialized)
                {
                    Name (PCKG, Package (0x04)
                    {
                        One,   <-- Enable/disable byte set to enabled
                        Zero,  <-- Connector byte which is modified by Arg0 below
                        Zero, 
                        Zero
                    })
                    PCKG [One] = Arg0 <--takes the argument sets it into the 2nd indes of PCKG
                    Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.TUPC.PCKG */
                }

So this is the OC ACPI rename patch I added to config.plist. 

 

		<key>Patch</key>
		<array>
			<dict>
				<key>Base</key>
				<string>\_SB.PCI0.XHC.RHUB.HS14</string>
				<key>BaseSkip</key>
				<integer>0</integer>
				<key>Comment</key>
				<string>BT USB</string>
				<key>Count</key>
				<integer>1</integer>
				<key>Enabled</key>
				<true/>
				<key>Find</key>
				<data>R1VQQw==</data>
				<key>Limit</key>
				<integer>0</integer>
				<key>Mask</key>
				<data></data>
				<key>OemTableId</key>
				<data></data>
				<key>Replace</key>
				<data>VFVQQw==</data>
				<key>ReplaceMask</key>
				<data></data>
				<key>Skip</key>
				<integer>0</integer>
				<key>TableLength</key>
				<integer>0</integer>
				<key>TableSignature</key>
				<data>RFNEVA==</data>
			</dict>
		</array>

I am not able to do this through SSDT.

 

 

@deeveedee

I tinkered a bit further to try to change my connector types by renaming the GUPC method to XUPC and then inject GUPC from an SSDT but this doesn't work for me. The renaming works but the injected method is not found.

 

See below, this is what happens if I rename the GUPC method only in XHC which is where it is defined like your example. The undefined method ends up getting redeclared as an integer object. I can see that my SSDT is injected. I really don't know why my SSDT either has some error or is processed too late to affect the DSDT?

 

Also attached the SSDT I attempted to inject below. Similarly to a few posts above, it seems like every time I try to insert a method in XHC, the entire SSDT fails to execute. In any case, I now have a very simple and clean USB patch with no kext or mapping so I am happy. 😇

 

SSDT-HS14.aml

[deeveedee]

8 hours ago, rafale77 said:

For some reason the entire SSDT will not execute if I add lines 57 and below (The renaming method part). It compiles fine but there must be an error I can't figure out. I am able to see it because the USBX function above works using the same file as soon as I delete the HS14 scoped section.

 

Af first glance, I'd guess that your SSDT doesn't load, because your ACPI patch (in your config.plist) isn't properly renaming _UPC and/or _PLD, so you get an ACPI "Already Exists" error when attempting to inject your new _UPC and/or _PLD definitions.  I'd have to see your ACPI patch which renames PCI0.XHC.RHUB.HS14._PLD and PCI0.XHC.RHUB.HS14._UPC.

[rafale77]

8 minutes ago, deeveedee said:

 

Af first glance, I'd guess that your SSDT doesn't load, because your ACPI patch (in your config.plist) isn't properly renaming _UPC and/or _PLD, so you get an ACPI "Already Exists" error when attempting to inject your new _UPC and/or _PLD definitions.  I'd have to see your ACPI patch which renames PCI0.XHC.RHUB.HS14._PLD and PCI0.XHC.RHUB.HS14._UPC.

 

I have verified that the renaming works as I was able to boot and look into the DSDT. Take a look at the last post before yours. The renaming patch is not the issue. I am guessing that it is either a timing/order issue in my ACPI or an error I can't find in my SSDT. Funny that everything else works but the entire table fails once I enter the XHC scope.

[FirstTimeCustomac]

.

Edited August 12, 2023 by FirstTimeCustomac

[rafale77]

@FirstTimeCustomac Well done!

[rafale77]

After thinking about it more, I modified the previous patch and added a second ACPI replacement patch to my hack and managed to also fix the port types:

 

To do so, I patched the package of the GUPC method to USB3 ports and then patched one more byte of the HS14 port to change its argument.

 

[Max.1974]

On 8/1/2022 at 1:31 PM, deeveedee said:

Continuo seguindo este tópico, mas ainda não mudei minha abordagem de patching USB do meu uso atual de USBPorts.kext para um patch ACPI (SSDT). A abordagem kext tem funcionado muito bem para mim com Catalina, Montery e Ventura. Alguém viu uma melhoria ao mudar do patch kext para o ACPI e, em caso sim, quais são as melhorias que você observou? Obrigado(a).

 

Além disso, desde o Catalina, não mudei os tipos de comutação das portas USB lógicas associadas à minha única porta física Tipo C. Com base na minha explicação aqui, atribuí o tipo 0x09 ao HS10 e o tipo 0x0A ao SS03 e SS04 (diferentes tipos de comutação lógica na mesma porta física Tipo C). No meu caso, não consegui descobrir que o uso do tipo 0x09 vs tipo 0x0A tenha algum efeito no comportamento das portas USB Tipo C no macOS para USB2 e USB3. Estou curioso para saber se alguém observou uma mudança no comportamento da porta USB Tipo C ao experimentar a troca do tipo 0x09 e 0x0A.

 

Hi @deeveedee, just to replay your question, and show my benefits to edit SSDT drop from Opencore Sysreport Debug Tables, im have 100% fix issues from my desktop GA Z170 Xp Sli, 100 series. Better and fast connective, transfer, establish and safe management files and folders with total security. Before, tryin using all tools like you Know, and im still using, just for registering, im using too SSDT USB UIAC, USBX and SSDT fix that im called SSDT-USBPORTS. All the time listed trying use only Hackintool or USBtool or USBmap not compare with using all fix together.   

SSDT-USBPORTS.aml.zip

Edited November 20, 2022 by Max.1974