[Guide] Creating a Custom SSDT for USBInjectAll.kext

[Dajjal]

If you look carefully you'll find it in OEM.Will make the change then.

 

[RehabMan]

If you look carefully you'll find it in OEM.Will make the change then.

I will not go hunting in OEM folders.
Must place files in a simple matter in ACPI/patched.

 

[Dajjal]

Do so don't like so my friend .See how it feels to get a half reply from you?In my previous post I simply asked based on the info I provided how does the SSDT-UAIC look, did you reply?No, did you need problem files of that, No, yet don't want to go Hunting, again with this hunting, it's literally in a different path within the same folder!
This by itself shows your attitude which is so sad.Why did the Dev's behind clover give us that option?Your guide is not complete you know that right?You write a guide assuming everyone gets it, then when a user asks a question most times the reply is problem reporting files, like really?If you're still lost and it seems so, just a quick browse through a few pages of this thread highlights what I said above and why it's so many pages but you continue on your path.Provided below are the files the way you like it .Bless

 

[RehabMan]

Do so don't like so my friend .See how it feels to get a half reply from you?In my previous post I simply asked based on the info I provided how does the SSDT-UAIC look, did you reply?No, did you need problem files of that,

I almost always start by looking at ioreg.

No, yet don't want to go Hunting, again with this hunting, it's literally in a different path within the same folder!
This by itself shows your attitude which is so sad.

Keep things simple when you're asking other people for help.
You can work on your "multi-computer" Clover setup on your own time.

Your guide is not complete you know that right?You write a guide assuming everyone gets it, then when a user asks a question most times the reply is problem reporting files, like really?

It is complete, but you must have a certain level of background/skills and must read it carefully.
I cannot answer questions if you refuse to provide the requested files.
Post #1 is very clear regarding the required files, yet people ignore it (or don't read it).
Quite frankly, I should just NOT reply to those that don't provide the requested data.

You are more than welcome to make constructive suggestions regarding the content of the guide, or areas which you think need clarification.

If you're still lost and it seems so, just a quick browse through a few pages of this thread highlights what I said above and why it's so many pages but you continue on your path.

I'm certainly not lost. Remember who wrote the kext, wrote the guide, etc.

The reason this thread is long is because it has been here for almost two years and has almost a quarter million views.

Provided below are the files the way you like it .Bless

Previously you mentioned:
4 USB3 Ports (Blue)

But you only have 2x SSPx ports enabled on XHC. But I see they are actually connected to a hub (SSP7 and SSP8 are showing hubs connected) which means they must be internal, which means we are not concerned about the physical ports attached to the hub here at all, as we are only configuring the hubs attached to PR11 and PR21. I see you have SSP7 and SSP8 configured internal UsbConnector=255, so that looks fine. That takes care of all the SSPx part of the USB3 ports.

On EH01/EH02, we have just PR11/PR21 as internal hubs. Typical, so no surprise there.

Now on HUB1 (attached to PR11), you have enabled HP14, HP15, HP16, so these must represent USB2-only ports somewhere.
And on HUB2 (atttached to PR21), you have enabled HP21, HP22, HP23, HP24, so again, these must represent USB2-only ports.

And then there is HP25... it must be the hub associated with one of SSP7 or SSP8. It should be marked portType=2 (since it is internal). And shouldn't there be a second one??? Because you would expect a USB2 hub for each USB3 hub (eg. we expect one for each of SSP7 and SSP8). What happened to it? Maybe it was on HP26 and you should not have eliminated it?

An ioreg captured after testing *every* port (with all ports enabled) with both USB2 and USB3 devices would certainly be useful, as that is one of the first steps in the guide.

 

[Dajjal]

Keep things simple when you're asking other people for help.
You can work on your "multi-computer" Clover setup on your own time.

I made it simple and removed the SSDT hot patches so that logic would have pointed you towards the only other place it could be that clover supports files being loaded from.Also the pre-boot log clearly shows where it's loading from.

It is complete, but you must have a certain level of background/skills and must read it carefully.
I cannot answer questions if you refuse to provide the requested files.
Post #1 is very clear regarding the required files, yet people ignore it (or don't read it).
Quite frankly, I should just NOT reply to those that don't provide the requested data.

You are more than welcome to make constructive suggestions regarding the content of the guide, or areas which you think need clarification.

If you already believe that it's complete you'll just ignore any input or tell users to read.Strolling thru a few pages this is seen.A good example is the issue where users with 13,2 smbios will face or did you not consider this?Basic guidelines are to use that which matches your actual hardware.If you write a guide at least you should be willing to answer questions, if not preface your guide by stating that users without ''certain level of background/skills'' should not attempt nor ask questions.A user would typically ask questions to try to get a better understanding before submitting problem files since he has no idea what the problem is to begin with.

I'm certainly not lost. Remember who wrote the kext, wrote the guide, etc.
The reason this thread is long is because it has been here for almost two years and has almost a quarter million views.

If you think because you wrote the Kext,Guide etc you can't be lost as to what a user is trying to explain to you then keep on that track.Yet majority of hack users just use the Port limit patch, while we know because that's just way easier there is another element, which is quite obvious.

Now on HUB1 (attached to PR11), you have enabled HP14, HP15, HP16, so these must represent USB2-only ports somewhere.
And on HUB2 (atttached to PR21), you have enabled HP21, HP22, HP23, HP24, so again, these must represent USB2-only ports.

I explained all this before so what must I do now since that would require you hunting.

And then there is HP25... it must be the hub associated with one of SSP7 or SSP8. It should be marked portType=2 (since it is internal). And shouldn't there be a second one??? Because you would expect a USB2 hub for each USB3 hub (eg. we expect one for each of SSP7 and SSP8). What happened to it? Maybe it was on HP26 and you should not have eliminated it?

Again all this was explained in my post.The second one supposedly is HP 26 but nothing ever came up on that with either USB3/USB2 stick so I left it out.

An ioreg captured after testing *every* port (with all ports enabled) with both USB2 and USB3 devices would certainly be useful, as that is one of the first steps in the guide.

I did it even better, I provided dumps at every step to have a clearer picture.Attached again is all that one should need to get a very clear picture together with Debug whilst UAIC in place.The name reflects what the Dump represents.

 

[RehabMan]

A good example is the issue where users with 13,2 smbios will face or did you not consider this?

Known problem. And is a different problem. Not addressed by this guide (but relatively simple to edit the Info.plist).
Best to use a different SMBIOS than those that have existing injectors.

Basic guidelines are to use that which matches your actual hardware.If you write a guide at least you should be willing to answer questions, if not preface your guide by stating that users without ''certain level of background/skills'' should not attempt nor ask questions.A user would typically ask questions to try to get a better understanding before submitting problem files since he has no idea what the problem is to begin with.

I answer plenty of questions...
But for those who seem to think I owe them something...

If you think because you wrote the Kext,Guide etc you can't be lost as to what a user is trying to explain to you then keep on that track.Yet majority of hack users just use the Port limit patch, while we know because that's just way easier there is another element, which is quite obvious.

Port limit not recommended for long term use. Use only for port discovery.
Keep in mind that 7-series does not require the port limit patch at all. Only 8 ports possible on 7-series XHC.

Again all this was explained in my post.The second one supposedly is HP 26 but nothing ever came up on that with either USB3/USB2 stick so I left it out.

It probably means you did not plug a USB2 device into that hub.
As written in post #1, you must test every port with *both* a USB2 and USB3 device.

I did it even better, I provided dumps at every step to have a clearer picture.Attached again is all that one should need to get a very clear picture together with Debug whilst UAIC in place.The name reflects what the Dump represents.

For the "nothing plugged in", you can write down some things right away:
HP25, HP26, SSP7, SSP8 are all connected to internal hubs.
At this point you can write down portType=2 for HP25 and HP26.
And UsbConnector=255 for SSP7/SSP8.

And assuming that "USB2 (2Rear_2Front) Plugged in" means that these ports are USB2-only, you can write down: HP15, HP16, HP21, HP22 as portType=0

Now with "USB3 (4Rear_2Front) Plugged in", did you also plug USB2 devices into those same ports? It is required (as written in post #1), otherwise you don't know which HS ports are used for the pins associated with those USB3 ports. The ioreg implies you only plugged USB3 devices into these ports. But... all of those ports ended up being ports on the internal hubs (connected to SSP7/SSP8), which have already been identified, so this particular ioreg contributes nothing to SSDT-UIAC (we already have the data for the hubs). And if you had plugged USB2 devices here, you would discover they are also connected to the hubs already identified on HP25/HP26. So nothing to do for those ports as related to USB2 devices either (you could do it just to confirm your understanding of the topology).

Now for "USB2 Stick into(4Rear_2Front) USB3 Ports", this one shows HP14 and PRT3 used. PRT3 is the due to the built-in injector, and once you eliminate those injects (by patching/editing the Info.plist), you will find PRT3 is the same as HP13 (the port address is the same). It also shows HP23 and HP24 used (so those become portType=0). The data on HP25 doesn't matter as we have already taken care of that hub.

For "USB3 Stick into(2Rear_2Front) USB2 Ports", it shows HP15,HP16,HP21,HP22. Of course, you already tested these ports before with USB2 devices. Since they are USB2-only ports, USB3 devices act like a USB2 device (there are no USB3 pins in the port, so they attach only to the USB2 pins inside the device). So, we have nothing to do as a result of this ioreg as we have already determined those ports are portType=0.

Note: It is much easier if you test all ports with both USB2 and USB3 in a single ioreg, as it is then just a matter of looking at the final picture and making the required SSDT edits.

But I think what you have here (just skimming the above for ports/types):
HP25/HP26 portType=2
SSP7/SSP8 UsbConnector=255
HP15/HP16/HP21/HP22 portType=0
HP14/HP13 portType=0
HP23/HP24 portType=0

That is the data for your SSDT.

And then you need to edit the Info.plist to get rid of the iMac13 entries. Wish there as was a better way, but as of now, there isn't. Other than choosing a different SMBIOS, or living with PRT1 still being there (you could adopt PRTx as your hub port names, essentially merging in with PRT3 if you wanted... there is nothing sacred about the HPxx names I have chosen).

 

[Dajjal]

Now with "USB3 (4Rear_2Front) Plugged in", did you also plug USB2 devices into those same ports? It is required (as written in post #1), otherwise you don't know which HS ports are used for the pins associated with those USB3 ports. The ioreg implies you only plugged USB3 devices into these ports. But... all of those ports ended up being ports on the internal hubs (connected to SSP7/SSP8), which have already been identified, so this particular ioreg contributes nothing to SSDT-UIAC (we already have the data for the hubs). And if you had plugged USB2 devices here, you would discover they are also connected to the hubs already identified on HP25/HP26. So nothing to do for those ports as related to USB2 devices either (you could do it just to confirm your understanding of the topology).

I did test all ports with both USB2/3 Sticks, So I applied the -uia_ignore_rmcf and redid it twice, same thing, nothing comes up on HP26 so maybe that is due to the particular header on the MB or just the way it is on this board?Since nothing comes up on HP26 and your suggestion is that something suppose to, does that mean there is a error on my end?
USB2 sticks that is inserted into the 4 Back USB3 MB Ports come up on HP22/23 (Top 2) & HP13(PRT3)/HP14.(Bottom 2)
USB2 sticks that is inserted into the 2 Front USB3 Case Ports come up on HP25.All other Port locations are outlined in ''USB LayOut & Port Identification Z77X-UD5H rev.1.txt''
Attached is IOreg with all ports tested just to confirm that nothing comes up on HP26.Not to sure if to send a Debug again since I don't know if to Add HP26 or leave it without.Please advise.Bless

 

[RehabMan]

I did test all ports with both USB2/3 Sticks, So I applied the -uia_ignore_rmcf and redid it twice, same thing, nothing comes up on HP26 so maybe that is due to the particular header on the MB or just the way it is on this board?Since nothing comes up on HP26 and your suggestion is that something suppose to, does that mean there is a error on my end?

Well, I'm not sitting in your chair, so can't really help directly.
Clearly, there is a hub there as it shows in the first ioreg. It could be that the hub is connected to some internal motherboard headers which you're not testing/not using.

Your decision on what to do with it (you could keep it or exclude it).

 

[Dajjal]

I know you're not sitting here obviously, but since you implied that I did NOT try a USB2 stick I though that you were actually here I described in detail rather than being vague to try and give a virtual representation thinking that I would get the same.I know there is a Hub at HP26 as ioreg shows but since the ''Guide'' says eliminate what you don't use that's exactly what I did and since nothing came up on HP26 I left it out.
For your Guide you use a Laptop & a NUC which is a minority of hack users and neither of which you'll be going into to switch around headers if even possible so I figure I was correct to assume switching around the connection to the different MB Headers is a waste unless the guide implies doing exactly that well I was mistaken.
My take from the Guide is if I leave HP26 I'll not be following the Guide but still be under the port limit unless I'm checking the ports I have in use wrong and since nothing seems to be using it, it should be removed for proper USB implementation yet your response is, its my decision but that's opposite to what the guide suggests and since you're the one who wrote the Kext, Guide etc I'm still unsure cause I certainly dont want to go to another Guide (e.g..Bluetooth,Power Property injection ) only to be told that I don't have a Proper SSDT-UAIC so go fix my issue before I ask question in those threads.See the irony...

 

[RehabMan]

I know you're not sitting here obviously, but since you implied that I did NOT try a USB2 stick I though that you were actually here I described in detail rather than being vague to try and give a virtual representation thinking that I would get the same.I know there is a Hub at HP26 as ioreg shows but since the ''Guide'' says eliminate what you don't use that's exactly what I did and since nothing came up on HP26 I left it out.
For your Guide you use a Laptop & a NUC which is a minority of hack users and neither of which you'll be going into to switch around headers if even possible so I figure I was correct to assume switching around the connection to the different MB Headers is a waste unless the guide implies doing exactly that well I was mistaken.
My take from the Guide is if I leave HP26 I'll not be following the Guide but still be under the port limit unless I'm checking the ports I have in use wrong and since nothing seems to be using it, it should be removed for proper USB implementation yet your response is, its my decision but that's opposite to what the guide suggests and since you're the one who wrote the Kext, Guide etc I'm still unsure cause I certainly dont want to go to another Guide (e.g..Bluetooth,Power Property injection ) only to be told that I don't have a Proper SSDT-UAIC so go fix my issue before I ask question in those threads.See the irony...

No need to test headers you're not going to use (even the NUC has an internal header). And no need to include ports, even if connected to internal devices, that you're not going to use. For example, on my u430, I exclude the port attached to the internal touchscreen because I don't want the touchscreen to work.

But if you ask me "am I doing this right", it is difficult to answer as I'm not sitting in your chair, not actually doing all the tests, not doing all the observations. So, that comes down to you and your own usage.

Strictly following the guide, you would include HP26 as it has an internal device always connected to it (a hub). From the guide perspective, it does not matter that there were no ports tested that actually used that hub (the guide is concerned with controller port injection only). At that point, you have a device that is present, and a port which you can disable if you don't want to use that internal device. That is,... your decision.

Your hardware has no possibility of bumping into any port limit. The port limit is per controller. Your hardware has no controllers capable of exceeding the 15 port limit.