OSDev.org

According to the EHCI specification, setting the CONFIGFLAG will let the EHCI controller get all connection requests, and then route low-speed requests to companion controllers. That seems ok, just it doesn't work on some chipsets. On my AMD machine, setting (or resetting) the CONFIGFLAG seems to take half a second (we are talking about one instruction). Supposedly, a SMI interrupt is called. Worse, when this is done the routing logic still direct-routes low-speed connection requests to the companion controller, and the EHCI controller never sees them, and the interrupt handling no longer works. If I don't set the CONFIGFLAG, everything works as expected, and low-speed devices automatically goes to the companion controller while the EHCI controller gets the high speed requests. Seems ok, except on another machine with no companion controller, the EHCI only gets the requests if the CONFIGFLAG is set.

How is the CONFIGFLAG supposed to be handled to work on all (or at least most) systems?

Seems like not setting the Config flag doesn't work on this machine after all. It apparently routes everything to the companion controller instead, so it seems like the problem with missing IRQs might be present regardless of this setting.

Yes, the SMI that fires when you set CONFIGFLAG will be where the host releases the ports properly (ensuring there are no conflicts).

Have you done a "Pre-OS to OS" handoff?

pcmattman wrote:Yes, the SMI that fires when you set CONFIGFLAG will be where the host releases the ports properly (ensuring there are no conflicts).

Have you done a "Pre-OS to OS" handoff?

For the EHCI controller, yes. However, the values in the fields did not match the specified protocol, so I don't know if it is properly implemented. Another issue is if I need to do the handoff for the OHCI companion controller as well? There is a documented method, but I haven't tried it.

Additionally, the main problem might be that both controllers tries to initialize the same device, how this would be possible I don't know. But I do know that the EHCI controller doesn't seem to always get the attach message first, which is strange. I've also seen two hub threads when only one hub is attached, which points to malfunctioning device sharing between EHCI and OHCI.

1) What is the EXACT hardware you are testing on? PCI Vendor ID/Device ID?

2) Have you looked at the Linux or FreeBSD code? (I said look, not copy.)

Another issue is if I need to do the handoff for the OHCI companion controller as well?

Yes. On OHCI, if I remember correctly, the firmware will often have configured routing for the interrupt to fire an SMI. This may explain your missing IRQs.

And yes, again if I remember correctly, the EHCI controller should get the attach - if during the port reset you determine the device should go to companion controllers, you toggle the relevant bit(s) in the port status register, passing it on to the companion controller.

I think you'll need to make sure your OHCI driver confirms interrupt routing is correct before debugging issues possibly related to malfunctioning device sharing.

pcmattman wrote:

Another issue is if I need to do the handoff for the OHCI companion controller as well?

Yes. On OHCI, if I remember correctly, the firmware will often have configured routing for the interrupt to fire an SMI. This may explain your missing IRQs.

Yes, that is possible. For OHCI, I don't use IRQs, rather a periodic timer that checks for completed requests. This is because I want to be able to run the OHCI driver without ACPI. It also seems like EHCI and OHCI might share IRQs.

tom9876543 wrote:1) What is the EXACT hardware you are testing on? PCI Vendor ID/Device ID?

Don't have them here, but can post them on Monday.

tom9876543 wrote:2) Have you looked at the Linux or FreeBSD code? (I said look, not copy.)

It's impossible to reuse the Linux USB-code in RDOS. The programming models differ too much.

rdos wrote:

tom9876543 wrote:2) Have you looked at the Linux or FreeBSD code? (I said look, not copy.)

It's impossible to reuse the Linux USB-code in RDOS. The programming models differ too much.

You asked about the "CONFIGFLAG". Does Linux/FreeBSD set this flag? What do they do with it?

tom9876543 wrote:

rdos wrote:

tom9876543 wrote:2) Have you looked at the Linux or FreeBSD code? (I said look, not copy.)

It's impossible to reuse the Linux USB-code in RDOS. The programming models differ too much.

You asked about the "CONFIGFLAG". Does Linux/FreeBSD set this flag? What do they do with it?

They set it, but due to really lousy coding (it's a parameter with unknown origin) it is more or less impossible to know what they set it to.

rdos wrote:

tom9876543 wrote:You asked about the "CONFIGFLAG". Does Linux/FreeBSD set this flag? What do they do with it?

They set it, but due to really lousy coding (it's a parameter with unknown origin) it is more or less impossible to know what they set it to.

Oh My God.
You are accusing the Linux kernel developers AND the FreeBSD kernel developers of "lousy" coding.
Maybe we should remind you what code DOES run correctly on your EHCI controller, unlike your code.
It is crazy to state there is a "parameter with unknown origin". The source code is logical and the compiler sure as hell understands it.
The fact is you are too incompetent to understand the source code the kernel developers have written.

tom9876543 wrote:

rdos wrote:

tom9876543 wrote:You asked about the "CONFIGFLAG". Does Linux/FreeBSD set this flag? What do they do with it?

They set it, but due to really lousy coding (it's a parameter with unknown origin) it is more or less impossible to know what they set it to.

Oh My God.
You are accusing the Linux kernel developers AND the FreeBSD kernel developers of "lousy" coding.
Maybe we should remind you what code DOES run correctly on your EHCI controller, unlike your code.
It is crazy to state there is a "parameter with unknown origin". The source code is logical and the compiler sure as hell understands it.
The fact is you are too incompetent to understand the source code the kernel developers have written.

Gosh, so now I am incompetent because I don't want to spend time figuring out how the lousy Linux source code for USB works? If I wanted to know how the Linux kernel or their USB stack works, I'd enroll as a Linux developer instead. However, I've decided that Linux is just a massive hack by incompetent coders who have no idea how to write a kernel. The fact that the source is open (unlike the Windows source) means nothing when most drivers are written by incompetent application coders.

rdos wrote:However, I've decided that Linux is just a massive hack by incompetent coders who have no idea how to write a kernel.

Please provide an independent citation to support your claim "Linux is just a massive hack by incompetent coders".

Here is some independent evidence which directly shows Linux developers are NOT incompetent coders:
http://gigaom.com/2013/07/29/linux-reig ... ing-realm/

rdos wrote:so now I am incompetent because I don't want to spend time figuring out how the lousy Linux source code for USB works

Rdos, if you fail to learn from other people who have already proven they are successful, then yes you are incompetent.

tom9876543 wrote:

rdos wrote:However, I've decided that Linux is just a massive hack by incompetent coders who have no idea how to write a kernel.

Please provide an independent citation to support your claim "Linux is just a massive hack by incompetent coders".

Here is some independent evidence which directly shows Linux developers are NOT incompetent coders:
http://gigaom.com/2013/07/29/linux-reig ... ing-realm/

Now how is that relevant to USB stacks or reverse-engineered drivers often done by application coders? When it comes to super-computers, it will be big companies with competent developers that will do drivers for hardware which they have specifications for. Not so for typical installations on your typical home-computer, were several of your drivers might be full of bugs.

In essence, the ability of super computer developers to launch support for their designs with Linux doesn't depend a lot of the usability of Linux in this particular segment where the most important feature is UNIX compatibility.

RDos,

I am confident the Linux / FreeBSD USB stack is CORRECTLY running on thousands of your USB EHCI controllers today.
I have provided a citation to show Linux developers aren't lousy. Maybe its not the best citation - at least it is something.
You have provide zero independent evidence to support your dubious claims.
You claim Linux is "buggy", so provide some web links to support your claim. I am guessing there was small number of bugs, but they have all been fixed.

Learn from other people who have been successful. Failure to do so is incompetence.