Mapping USB Ports Discussions

[MaLd0n]

27 minutes ago, gengik84 said:

@MaLd0nhackintosh is a passion but it is not life.

😅 Your friends don't think so. They spread so many lies. "Use this, don't use that. Have virus. Not vanilla." Nowadays the value of a real vanilla is in createinstallmedia instead of a good fine tune.  

 

I think u forgot comments about connectors. All is there. This credit is not for u and me or other. We just duplicated one OEM method and renamed.

https://pikeralpha.wordpress.com/2016/11/10/two-port-usb-3-1-gen-ii-pci-express-card/

 

if i think like ur comment above...PMCR is my credit? Im using it since 2018 u can check HERE and in 2020 one guy(i don't remember name) post here "My discovery". The credits is for apple i just discovery. Other case is EC device mandatory for boot, i post it in some beta release(idk if fantomas delete it). This is my credit? 

The line for these "my credits" cases is short. Understand my point? 

[gengik84]

8 minutes ago, MaLd0n said:

Your friends don't think so. They spread so many lies. "Use this, don't use that. Have virus. Not vanilla." Nowadays the value of a real vanilla is in createinstallmedia instead of a good fine tune.  

...... and what do I do in this? I am not responsible for what the next one does! Are you referring to your macos ISO? I only know that it is forbidden to talk about them and distribute them here

You are free to do whatever you want out of here.

9 minutes ago, MaLd0n said:

if i think like ur comment above...PMCR is my credit? Im using it since 2018 u can check HERE and in 2020 one guy(i don't remember name) post here "My discovery". The credits is for apple i just discovery. Other case is EC device mandatory for boot, i post it in some beta release(idk if fantomas delete it). This is my credit? 

The line for these "my credits" cases is short. Understand my point? 

Yes, the first PMCR is out with Skylake and it's changed later (HID instead ADR)

As far as I remember the first to use EC (fake device) and not the classic rename used for many years, it was made by RM

I probably missed something.... I repeat feel free to write to me in PM

15 minutes ago, MaLd0n said:

i post it in some beta release(idk if fantomas delete it). This is my credit? 

I don't know whats happened and why..

[MaLd0n]

51 minutes ago, gengik84 said:

 

You are free to do whatever you want out of here.

i don't talking about it. read my last post

 

51 minutes ago, gengik84 said:

Yes, the first PMCR is out with Skylake and it's changed later (HID instead ADR)

First is x99. EVMR device.

52 minutes ago, gengik84 said:

I don't know whats happened and why..

👌

 

Enjoy and stay safe.

[gengik84]

3 minutes ago, MaLd0n said:

First is x99. EVMR device.

 

Sorry sir, before we talked about pmcr and i meant Skylake and later for real mac series...(acpi,ioreg)

 

4 minutes ago, MaLd0n said:

Enjoy and stay safe.

Thx, same to you

[rafale77]

Back on the initial topic: I read through the method of moving the USB port mapping to ACPI but on my machine, the USB ports are defined in the DSDT, which means I cannot block the USB table only.

In the meantime, my hack also doesn't have more than 15 ports so it doesn't need any port disabling. I tried booting without my USBMap.kext and everything seems fine except for my native BT card.

Oddly it is also the only port which is configured correctly by default since the DSDT makes every USB A port an internal port and only the USB-C ports correctly.

 

I then tried the trick described by the author of this post: https://github.com/dortania/OpenCore-Post-Install/pull/54

to disable the _UPC method and then recreating it in the SSDT but this leads to disabling of every USB port... sigh. Could be that my SSDT did not take. Not sure...

 

If anyone has any better suggestions, I am all ears.

 

 

[Guest 5T33Z0]

@miliuco 255 is for internal CONNECTORS without the usual physical ports. But an integrated USB Hub is not an INTERNAL connector. It has physical ports attached to it which are located on the outside of the system so you can attach devices to it (or pull them). Seee "Port 3":

 

Internal connectors are not meant to be disconnected physically. That's the difference. And that's why I wouldn't suggest to define the USB port of an integrated Hub as internal. I don't know if it makes a difference in terms of the way the system works, but I wouldn't run a hub as 255.

Edited July 29, 2022 by 5T33Z0

[rafale77]

So I am now attempting to STA out the RHUB and rebuild the USB ports. I have attached my SSDT attempt. It is still not working. What am I doing wrong?

 

 

SSDT-USB.aml.zip

Edited July 29, 2022 by rafale77

[datafeedexpert]

2 hours ago, rafale77 said:

So I am now attempting to STA out the RHUB and rebuild the USB ports. I have attached my SSDT attempt. It is still not working. What am I doing wrong?

 

 

SSDT-USB.aml.zip 1.03 kB · 1 download

@rafale77 Here are My SSDT-XHC with RHUB ,First i Used a USBToolBox on windows to identify the ports then configure these ports using @5T33Z0Mapping Guide https://github.com/5T33Z0/OC-Little-Translated/tree/main/03_USB_Fixes/ACPI_Mapping_USB_Ports 

SSDT-XHC.aml

[miliuco]

12 hours ago, 5T33Z0 said:

... Internal connectors are not meant to be disconnected physically. That's the difference. And that's why I wouldn't suggest to define the USB port of an integrated Hub as internal. I don't know if it makes a difference in terms of the way the system works, but I wouldn't run a hub as 255.

Yes, you are right, I also think the internal hub distributing to 4 external ports doesn't have to be 255. 

I've put 3.

Apparently afaik the system works the same but your explanation is convincing.

[rafale77]

@datafeedexpert, Thank you for sharing! It's very interesting that you are actually STAing out not just RHUB but the entire XHC... I suppose that's how your SSDT was structured. Taking inspiration from it, I will try to adapt a version for my rig and go from there.

 

Edit: Well no luck. I must be doing something wrong again.

I can see that the XHC got renamed and I have most ports open and working but I am missing 3 ports and the names do not match the input of the SSDT... Weird. My DSDT has a ton of methods under XHC and RHUB which I did not copy over. They are mostly around power state and sleep states. Sigh... my unit doesn't appear to be too friendly to this method.

Edited July 29, 2022 by rafale77

[datafeedexpert]

12 hours ago, rafale77 said:

@datafeedexpert, Thank you for sharing! It's very interesting that you are actually STAing out not just RHUB but the entire XHC... I suppose that's how your SSDT was structured. Taking inspiration from it, I will try to adapt a version for my rig and go from there.

 

Edit: Well no luck. I must be doing something wrong again.

I can see that the XHC got renamed and I have most ports open and working but I am missing 3 ports and the names do not match the input of the SSDT... Weird. My DSDT has a ton of methods under XHC and RHUB which I did not copy over. They are mostly around power state and sleep states. Sigh... my unit doesn't appear to be too friendly to this method.

You can Verify my USBToolBox Mapped Image With My SSDT , There is a Ports info mentioned in Every ports, after that you can use USBToolBox on Windows and get Same Image for the All ports and after that describe that ports on your new SSDT 

[rafale77]

Thanks, unfortunately, I don't think it's a port mapping issue. I already have it mapped and working using a kext. I am just trying to migrate the mapping from kext to SSDT method. I am quite puzzled by the outcome though.

[datafeedexpert]

27 minutes ago, rafale77 said:

Thanks, unfortunately, I don't think it's a port mapping issue. I already have it mapped and working using a kext. I am just trying to migrate the mapping from kext to SSDT method. I am quite puzzled by the outcome though.

Kext Mapped Ports have a serial numbers Like HS01,HS02 to -> Whatever number of ports you have & SSDT have actual Ports which is like example you have HS01 to HS07 after that 3 ports are in not use like HS08,HS09,HS10 after that HS11,HS12 are in use so you have to declare that ports with types in your SSDT, still you have problem configuring the same than you can post your USBToolBox Image from Windows & actual SSDT-USB Tables from your machine i can defiantly make ssdt for you   

 

Notice : While Using SSDT-XHC you have to drop usage of USBPorts.kext 

Edited July 30, 2022 by datafeedexpert

[deeveedee]

Great discussion!  Thank you!

 

I have a single physical Type C port that has different switching/orientation behavior for USB2 and USB3 connected devices as follows:

• With a USB2 device, if I flip the orientation, the logical port remains unchanged as HS10.
• With a USB3 device, if I flip the orientation, the logical port switches between SS03 and SS04.

Does this mean that HS10 is Type 0x09 (Flipping the device does not change the ACPI port) and SS03/SS04 are Type 0x0A (Flipping the device does change the ACPI port).

 

I'm asking because I wasn't sure if a single physical USB port could be associated with two different switching types depending on whether a USB2 or USB3 device was inserted in the port. 

 

Thank you.

Edited July 30, 2022 by deeveedee

[rafale77]

@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

[deeveedee]

@rafale77 My OEM SSDT also defines ports SS03, SS04 and HS10 as Type 0x0a.  Thanks.  I guess that settles our original debate.

Edited July 30, 2022 by deeveedee

[rafale77]

1 minute ago, deeveedee said:

@rafale77 My OEM SSDT defines ports SS03, SS04 and HS10 as Type 0x03, so they offer no help for me.  Is Type 0x0A the OEM definition, or did you assign that type?

It is the OEM definition. I am not patching my DSDT. See below. It's interesting that HP defined it that way...

[deeveedee]

@rafale77 I corrected my original post here.  I was reading the wrong items.

[Guest 5T33Z0]

1 minute ago, rafale77 said:

It is the OEM definition. I am not patching my DSDT. See below. It's interesting that HP defined it that way...

 

Did you do this?  https://github.com/5T33Z0/OC-Little-Translated/tree/main/03_USB_Fixes/ACPI_Mapping_USB_Ports#preparing-the-replacement-ssdt

 

Because if I look at the return values used in your code is nothing that resembles what I am doing.

[deeveedee]

@5T33Z0 I had followed your guide (well done!) and changed all instances of  Method _UPC (except USR1 and USR2) to 

 

Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
	{
		Return (GUPC (0xFF, 0x03))
	}

I then reviewed each port to identify its type and where applicable proceeded to change "Return (GUPC (0xFF, 0x03))" to "Return (GUPC (0xFF, 0xXX))" where 0xXX is the type from the table you provided.  This is why I asked my question here.  As rafale77 said, my OEM SSDT defines the HS10, SS03 and SS04 types as 0x0A.  Since my HS10 port does not change  when flipping orientation, I wasn't sure if I should change my HS10 type to 0x09 or leave it as 0x0A.

Edited July 30, 2022 by deeveedee

[rafale77]

@5T33Z0, Yes I have read your guide but as I said in a previous post, my USB is defined in the DSDT, not in one of the SSDTs. As a result, I am having to STA out the original RHUB from the DSDT and rename it as @datafeedexpert has done. This forces me to redefined both the XHC and RHUB device from scratch in an SSDT. My file is (attempting) to copy the relevant content of my DSDT into an SSDT.

 

See the result: XHC are the kext version which Hackintool kept in memory. XHC1 is when I boot with the SSDT. I am finding strange that some of the enabled port do not show up and one disabled port, HS03 is showing up. The port connector type are also not as I have defined them in the SSDT. If I only boot with the SSDT-RHUB, all the connectors would get defined as internal but the port names and number would be correct so I am finding it very bizarre.

 

 

As an example of differences, enabling a port on my machine uses a value of "One" instead of "0xff" for the first value of GUPC in your guide and it seems to be also what @datafeedexpert has.

 

Edited July 30, 2022 by rafale77

[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