What's All This Talk About 7-Series Mobos and DSDTs, and Why Should We Care?

[PH]

Attached is a condensation of a series of discussions between H Q-A's Founder and me on the subject.


>> Alas, the required knowledge is contained within a number of documents
>> AND
>> the collective experience of a number of DSDT-wise folks.

> Which documents??? Are you guys trying to keep it to yourselves?

Primarily this one:

http://www.acpi.info/spec50.htm

992 pages long.



>> Here, I am guessing that Mieze saw that having an EHC1 device, which
>> would
>> be "multiplexed" with an XHC device looked "clumsy", and she decided to
>> rename the XHC device to XHC1, so that the very tight relationship
>> between
>> the Super-speed USB device, XHC, which is otherwise only USB 3.0 (and
>> not
>> really that, under OS X, without other mods), and the high- and
>> standard-speed USB device, EHC1, is clearer to the experimenter. Hence,
>> the renaming of XHC to XHC1.

> Now we are getting somewhere, believe me, not everyone knows what these
> strange sounding device names actually are. I mean some device names
> within a DSDT are obvious, but most of the devices aren't. I think if
> people understood what the device names apply to it would be most helpful.
> So did she change the name b/c it looked "clumsy" or was it necessary for
> OS X to understand it better? How do these changes relate to the way the
> USB 3.0 port works? By making these changes does it allow the fallback to
> USB 2.0? I hope you can see what I'm getting at.

The use of DTGPs in the devices are necessary to get OS X to see the
devices, of whatever name, as its own.

You will note that each DTGP is different.

The goal is, in every case possible, for OS X to "see" a mobo's device as
if it was one of its own, and that allows the kernel to associate an Apple
device with the device defined by the DSDT.

And, once the kernel makes that association, it assigns the correct driver
to the device.

If you use IORegistryExplorer, you will see where certain DSDT devices
have a specific Apple device associated with it.

THAT is the goal, to have Apple make that association, before it transfers
control to the Finder.

For, after OS X is at the Finder, it is nearly impossible to make any
other association.

Now, why is Mieze's code so complicated?

It is because it is designed to change a device which is connected to a
blue USB port to the driver which is intended for a black USB port, when a
USB 2.0/1.1 device is plugged into a blue port.

And, conversely.

That is what she means by "multiplexing".

For, it is possible to rejigger (not a technical term, but still somewhat
suggestive of what is going on) a device on the fly, and without again
going through the initialization code again.

For example, the code to change a SATA III port to SATA II or SATA I is
already in Apple's drivers. Similarly, a SATA II port can be made to be a
SATA I port. However, a SATA I port can only be used for a SATA II or a
SATA III device if the device can auto-negotiate.

Auto-negotiating is only possible with USB 2.0 and USB 1.1 devices.

To simulate auto-negotiating with USB 3.0 devices and USB 3.0 ports (and
USB 2.0/1.1 ports as well) requires a LOT of code in the DSDT, as Apple's
drivers are not going to do it.



>> Once Intel FINALLY decided to build USB 3.0 devices into its
>> Southbridges
>> with the 7-Series, all knowledge of how to support USB 3.0 under OS X
>> became immediately obsolete.

> So no longer a separate chipset right? Incorporation of the function into
> the Southbridge is different b/c it's in a different location or for some
> other reason?

Correct.

You cannot use a 7-series USB 3.0 port as USB 3.0, or for any other use,
without the correct Apple driver being associated with that port.

The "magic" of Mieze's DSDT mods is to get Apple's USB 3.0 driver
associated with that port whenever a USB 3.0 device has been inserted in
the connector, but to "switch" that port to use Apple's USB 2.0/1.1 driver
whenever a USB 2.0/1.1 device has been inserted in that port.

Mieze, based upon Apple's MacBook Pro DSDT, forces a change from one of
the four ports which are supported by the XHC1 device to the driver which
is identified with one of the four ports which are supported by the EHC1
device.

And, she does this without having to go through the kernel initialization
process again.

And, I can tell you that it works perfectly, as you can, while at the
Desktop, unplug your USB 1.1 Apple Pro keyboard and mouse from a black
connector and plug it into a blue connector, and observe under the
IODeviceRegistry window that a switch takes place.

The fact that this actually works while at the Desktop is the real "black
art" of her mods, which, I believe, she copied from Apple's DSDT.

The fact that she found a way to do this on a generic mobo is a true
"miracle".

Although Apple has to play by the same rules as other users of ACPI, its
just that Apple has a lot of really smart programmers who are pushing the
ACPI specification to its maximum.



> Perhaps if you don't mind sharing some of these explanations with the
> group, at least those who have the ability to understand can learn
> something. It can be part of your continuing DSDT education program if you
> prefer. I, for one, certainly appreciate the explanations you provide. I
> feel I at least have a better understanding of these changes, certainly
> more than just seeing what was changed and trying to grasp why it was
> changed. I hope you can see why I asked, if nothing else, for my own peace
> of mind.
>
> Thanks Peter, as usual you are a great source of information for this
> group. I do appreciate the fact that you chose to associate with me on the
> whole group project. I could never have done it without you.

The real "heavy lifting" was done by Apple Inc.

Mieze correctly figured out how to translate that MacBook Pro DSDT code to
a generic mobo.

She provided a number of DSDTs for her MSI B75MA-P45 mobo, and with each
iteration she obtained more and more compatibility, so with the "1.4c"
revision every thing was (finally) working.

When she started out, all she could get was USB 3.0 devices working with
Apple's USB 3.0 ports.

And, without some DSDT mods, you can't even get OS X to see a USB 3.0
device on a 7-Series USB 3.0 port as USB anything ... the port is dead as
a DoDo Bird.

Meize left a lot of crumbs throughout the various sites, and I once
collected each of her crumbs and placed them into a file.

However, I have temporarily lost that file.

Essentially, she made a number of posts as she went along, and she
announced what new function she had achieved.

Then she was asked how to apply her new code to other cases.

Her answers were necessarily terse, as she expected, and required, the
reader to understand, implicitly, what she was doing.

In some cases, she had to replace the entire method. In others, she had to
make a simple modification to that method.

When I wrote my Guide (and that's pretty much what it is), I tried to
simplify the process by adopting her devices and/or methods in whole,
rather than in part, as by taking them in whole, you are assured of having
a working result.

As I pointed out, DSDTSE cannot handle ill-formed code, and the initial
stages of my Guide are there just to get DSDTSE to cleanly compile the
DSDT without providing any of the new functions.

Thereafter, I get into the "heavy lifting", where the radically new
functions are added.

Remember where I said to add a small fragment of code where "Darwin" is
detected. THAT starts the process. There are also tests for various
versions of Windows, and even Linux.

When a specific device or method needs to know which OS it is running
under, it consults the variable where the value which is associated with
an OS is kept.

Thereafter, it takes the correct path for THAT OS, and only that OS.



>> The EHC2 device receives a few changes, too, but the USB 3.0 devices are
>> multiplexed into the USB 2.0/USB 1.1 device which is represented by
>> EHC1,
>> not into the USB 2.0/USB 1.1 device which is represented by EHC2.

> When you use the term multiplexed, what exactly do you mean? I'm familiar
> with what heterodyne means, is it like that?

I would say that the simile is not exactly multiplexing or even
hetrodyning, but changing a specific USB port from AM to FM, AM being USB
2.0/1.1 (and using Apple's USB 2.0/1.1 driver) and FM being USB 3.0 (and
using Apple's USB 3.0 driver).

But, when a blue device connector is inserted into a black port, the DSDT
code changes that driver on-the-fly from FM to AM.

And, when a black device connector is inserted into a blue port, the DSDT
code changes that driver on-the-fly from AM to FM.

Perhaps this is getting a little too simplistic, but "it is what it is".



> Once Intel FINALLY decided to build USB 3.0 devices into its
> Southbridges with the 7-Series, all knowledge of how to support USB 3.0
> under OS X became immediately obsolete.

It has been reliably reported that Apple Inc's USB 3.0 driver WILL work
with the Fresco Logic USB 3.0 chip.

However, it has also been confirmed that Apple's USB 3.0 driver WILL NOT
work with the "industry standard" NEC/Renesas USB 3.0 chips, and is only
marginally usable with ASMedia and a few other USB 3.0 chips.

Therefore, the best available solution is a 7-Series mobo and Apple's
unmodified USB 3.0 driver, PLUS code in the DSDT to accomplish
"multiplexing".

The more one digs into this mess, the more complex it gets. Really.



> Wow, tremendous explanations and much more than I ever expected. They were
> clear and concise, bravo and thank you.

THANK YOU.

Would you have any objection to me paraphrasing your questions and
assertions, and compile them, and my responses, into a post to the general
group?

You properly called me on the carpet for my terseness, and, I believe, you
forced me to much more clearly explain what and why I was doing with my
mods.

I believe this compilation would be helpful to the group, as I sense some
of the members may be lost in the minutia.

With such an elegant solution at hand, there is no reason not to go with a
7-Series solution, now that Apple Inc is supporting it in their products.

Particularly not as an MSI B75A-G43 can be had for $72.99 to $79.99 from
NewEgg, and it supports "second generation" and "third generation"
i-Series procs of many kinds, and the DSDT "heavy lifting" has already
been accomplished by me, using Mieze's work as "inspiration".

[mosslack]

On Feb 16, 2013, at 8:54 AM, PH wrote:

Attached is a condensation of a series of discussions between H Q-A's Founder and me on the subject.

Peter and I had this private conversation yesterday and I really appreciate him taking the time to condense it down for everyone. While I always appreciate the comments he makes on his DSDT edits, sometimes they need some explanation as to why things were done the way they were done, 

After all he does, I really hated to ask, but I felt it would be most beneficial to the group and Peter is after all a good guy. So thanks Peter for taking the time to explain this in the terms I can understand. I hope everyone else understands it as well.

From the main system of mosslack...

______________________________

Alt-OS <+> GG <+> TBIE <+> Hack List

[faithie999]

doug and peter--thanks for having this discussion, and peter, thanks for taking the time to let us all in on what you learned and what you then figured out to make usb3 work smoothly.

i took the plunge on the msi mobo and it should arrive next week.

now, i noticed the mention in your message of "apple usb3 driver supporting the fresco logic usb3 chip".

i have an hp probook on ML with an expresscard slot.  early on, i bought a usb3 expresscard adapter, and while i know for sure the expresscard slot works, but the usb3 expresscard doesn't (altho i can "see" it in system profiler).  i determined that it has a fresco logic chip, but none of the usb3 kexts i tried worked.

what is the apple usb3 driver you referred to, and from where do you think i could obtain it?  it would be nice if my expresscard usb3 adapter would work.

thanks again

ken

[pete...@cruzio.com]

> what is the apple usb3 driver you referred to, and from where do you think
> i could obtain it? it would be nice if my expresscard usb3 adapter would
> work.

I have read that the Apple USB 3.0 driver in ML 10.8.2 supports the Fresco
Logic chip, but I have no proof that it does. I have no Fresco cards or
mobos, only NEC/Renesas and ASMedia, which are known to work with the
hacked PXHCD driver. But the PXHCD driver is for USB 3.0 chips which sit
on a PCI-e 1x bus, and the 7-series USB 3.0 devices are internal to the
Southbridge itself, much as the USB 2.0/1.1 devices always were internal
to the earlier and the current Southbridges.

I KNOW 10.8.2 supports the USB 3.0 ports in a 7-Series mobo, provided
there is support for that in the DSDT, for otherwise even those 7-Series
USB 3.0 ports aren't even supported.

There was a thread on tonymacx86's forum which discussed which USB 3.0
implementations worked, and which did not, with 10.8.2.

Getting blue ports to work seamlessly with blue or black devices, and
black ports to work seamlessly with black or blue devices is the "holy
grail" of USB support, and I have been focusing on that almost exclusively
for several weeks now.

I know from my early experiments that the IODeviceRegistry application
will "see" ports as they exist, whether they "work" or not, and that is a
start.

What is missing is the association, at startup, of a specific Apple Inc
device driver with a specific port, for otherwise the port will be there,
but there will be no assigned Apple Inc driver, hence no capability to use
that port.

The DTGPs are there to help make that association. No DTGP, no association.

Anyway, that's the way I am reading it (the 7-Series and 10.8.2 "tea
leaves").

What I thought was MOST SIGNIFICANT was my experiments where, in a fully
functioning 10.8.2 system, I pulled the plug on my KB and mouse in their
usual black ports (as these are USB 1.1) and plugged those into the
7-Series blue ports and that the KB and mouse continue to operate without
interruption (once the "switch" had been made, which took only a second or
so).

Heck, I even retained my KB and mouse in the black ports and plugged my
wireless mouse's Bluetooth adapter into a blue port and had both pointing
devices working at the same time.

Talk about true USB 3.0/2.0/1.1 compatibility!!!!!