OSDev.org

P.S. This machine's SMI (BIOS) is a little messed up. There are two EHCI's, the first having two companion controllers, the second having three. If I enumerate the first EHCI (before its companions), it quickly gives up control. Then if I enumerate the second EHCI, it will give up control, *only* if I haven't touched the other EHCI's companion controller(s). i.e.: I think the SMI for each EHCI is connected on this machine. The BIOS is watching both EHCI's as one.

Even if the first has released the BIOS, the second will not if I reset the first's companion controllers. I have to wait and not touch any of the companions until all EHCIs have been initialized.

This seems wrong to me. One EHCIs SMI (see note below) should not care about the other's companion controllers, correct?

Anyway, just thought I would mention this so others can keep this in mind when and if they run into this problem.

Thanks,
Ben

[Note: When I say SMI, which really stands for System Management Interrupt, I am meaning the process of the BIOS taking over the instant it sees something change and before it releases this control. I probably should use the term, SMM (System Management Mode) or just SM, (System Management)].

Well, back to it.

After a few more tests, I found that the BIOS (SMM) does not restore the companion controllers to their default state, nor does it the EHCI controller. Once I ask for control, the BIOS simply stops catching SMIs, leaving the controllers as they were when I requested control.

To remedy this, I had to set the EHCI's Config bit to 1, gaining control of all companions, *then* setting the Owner bit in each port so that the companions would take over each port. i.e.: restoring the state of the controller(s) to non-EHCI aware/separate independent companion controllers (UHCIs). I had to do it in that order too. If I skipped setting the Config bit, but set the Owner bit in each port, this didn't work, and visa-versa, only setting the Config bit didn't work either.

This was a must, or the BIOS would not release control of the next EHCI. At first, I thought that when I found an EHCI, I could reset it, initialize it to what I wanted, then as one of the last things, give ownership to all companion controllers. Besides, my USB stack will regain control if it finds a high-speed device attached anyway. However, since I have a multi-threading kernel, what happens if my USB stack finds a high-speed device *before* another thread finds the next EHCI? This happened a few times.

I could always make the "USB Stack" thread sleep for 20 seconds or so to make sure that the "PCI Enumerate" thread was done first, either having the "USB Stack" thread wake up after 20 seconds, or have the "PCI Enumerate" thread awaken the "USB Stack" thread.

I decided to go a little different route. Before I start the "PCI Enumerate" thread, another one scans all PCI devices for EHCI controllers, requesting ownership, restoring all companions to the default non-EHCI aware state. This way no matter what, all EHCIs and their companions are already mine when I begin to enumerate them.

This technique works on all machines I tested with, always releasing ownership.

I never did get back to the problem of having the BIOS report an 8042 that had a translation bit that would toggle, yet still only return set 1, i.e.: Translation On no matter the setting of the translation bit. Maybe another day.

Thanks for "listening". I hope that if someone else ever finds this problem, they will be able to find this thread and figure it out.

Ben
http://www.fysnet.net/osdesign_book_series.htm

Note that even per the Intel docs (of the ICH chipset), you must disable SMI generation for ALL UHCIs before you can use one of them (I do not recall what the specs say for EHCI). It is certainly not safe to do BIOS takeover and enumeration at the same time.

Korona wrote:Note that even per the Intel docs (of the ICH chipset), you must disable SMI generation for ALL UHCIs before you can use one of them (I do not recall what the specs say for EHCI). It is certainly not safe to do BIOS takeover and enumeration at the same time.

Indeed, however, I was not doing it at the same time.

I would enumerate the PCI devices, which only reads from the PCI config space (no SMI's triggered), and once an EHCI was found, I would instantly request control. Once received, then I should have control of the EHCI and all companion controllers under this EHCI, yes? No need to disable SMI generation for the UHCI's because I have control of the parent controller which has control of the companions. So you would think. Not so on this particular machine... :-)

Ben

Hi,

BenLunt wrote:

Korona wrote:Note that even per the Intel docs (of the ICH chipset), you must disable SMI generation for ALL UHCIs before you can use one of them (I do not recall what the specs say for EHCI). It is certainly not safe to do BIOS takeover and enumeration at the same time.

Indeed, however, I was not doing it at the same time.

I would enumerate the PCI devices, which only reads from the PCI config space (no SMI's triggered), and once an EHCI was found, I would instantly request control. Once received, then I should have control of the EHCI and all companion controllers under this EHCI, yes? No need to disable SMI generation for the UHCI's because I have control of the parent controller which has control of the companions. So you would think. Not so on this particular machine...

That doesn't sound right to me at all.

I imagine the companion controllers as being logically completely separate and independent from the EHCI controller in every possible way except for a little switch that controls if the device is electrically connected to the EHCI controller or a companion controller; and I'd expect to have to take control of all companion controllers and the EHCI controller separately.


Cheers,

Brendan

Brendan wrote:Hi,

BenLunt wrote:

Korona wrote:Note that even per the Intel docs (of the ICH chipset), you must disable SMI generation for ALL UHCIs before you can use one of them (I do not recall what the specs say for EHCI). It is certainly not safe to do BIOS takeover and enumeration at the same time.

Indeed, however, I was not doing it at the same time.

I would enumerate the PCI devices, which only reads from the PCI config space (no SMI's triggered), and once an EHCI was found, I would instantly request control. Once received, then I should have control of the EHCI and all companion controllers under this EHCI, yes? No need to disable SMI generation for the UHCI's because I have control of the parent controller which has control of the companions. So you would think. Not so on this particular machine...

That doesn't sound right to me at all.

I imagine the companion controllers as being logically completely separate and independent from the EHCI controller in every possible way except for a little switch that controls if the device is electrically connected to the EHCI controller or a companion controller; and I'd expect to have to take control of all companion controllers and the EHCI controller separately.

Cheers,

Brendan

You would think that, but as a BIOS, in my opinion, if the OS now has control of the EHCI, I must assume that the OS now has control of any companion controllers as well, since setting the EHCI's Config register to 1, all of a sudden, the EHCI has control of all sockets, leaving the UHCI's (companions) high and dry.

In my opinion, if the BIOS releases control of the EHCI, it must release the control of these companions as well, for the simple fact stated above.

If I release control of something, shouldn't I release control of all things that the first thing has control over?

Anyway, with a few minor modifications to account for faulty BIOS code, I now request for control of the EHCI, then each of its companion controllers before I do anything with the EHCI.

Ben

It is explicitly allowed to take control of the EHCI while letting the BIOS handle all companion controllers (e.g. if you run a OS with a EHCI but no UHCI or OHCI driver). The EHCI has no control over the companions, except that it can "steal" their ports.

Furthermore note that on ICH the SMI cannot even be disabled on a per-controller basis, the effective SMI enable bit is the logical OR over the bits of all controllers.

This is not a BIOS bug but a documented feature.

Korona wrote:It is explicitly allowed to take control of the EHCI while letting the BIOS handle all companion controllers (e.g. if you run a OS with a EHCI but no UHCI or OHCI driver). The EHCI has no control over the companions, except that it can "steal" their ports.

And I total agree with you. However, on this particular machine, it isn't that way. The SMM/BIOS is not EHCI separated. The SMM/BIOS has combined all companions, no matter what EHCI they belong to. Again, as previously noted, modifying a companion on one EHCI affects the operation of another EHCI and its companions. This is the buggy BIOS I am talking about. This particular machine's BIOS is buggy. I should be able to have full control of the EHCI (companions aside) and have the other EHCI either continue to work as expected under full BIOS control, or have it work as expected under my control. This is not the case on this machine.

Korona wrote:Furthermore note that on ICH the SMI cannot even be disabled on a per-controller basis, the effective SMI enable bit is the logical OR over the bits of all controllers.

This is not a BIOS bug but a documented feature.

All controllers or one (1) EHCI and its companion controllers only. I vote for the latter, not the former. However, it is up to interpretation of the BIOS manufacturer.

Ben

Hi,

BenLunt wrote:

Brendan wrote:

BenLunt wrote:I would enumerate the PCI devices, which only reads from the PCI config space (no SMI's triggered), and once an EHCI was found, I would instantly request control. Once received, then I should have control of the EHCI and all companion controllers under this EHCI, yes? No need to disable SMI generation for the UHCI's because I have control of the parent controller which has control of the companions. So you would think. Not so on this particular machine...

That doesn't sound right to me at all.

I imagine the companion controllers as being logically completely separate and independent from the EHCI controller in every possible way except for a little switch that controls if the device is electrically connected to the EHCI controller or a companion controller; and I'd expect to have to take control of all companion controllers and the EHCI controller separately.

You would think that, but as a BIOS, in my opinion, if the OS now has control of the EHCI, I must assume that the OS now has control of any companion controllers as well, since setting the EHCI's Config register to 1, all of a sudden, the EHCI has control of all sockets, leaving the UHCI's (companions) high and dry.

In my opinion, if the BIOS releases control of the EHCI, it must release the control of these companions as well, for the simple fact stated above.

That would be horribly racey (e.g. OS takes control of one controller and takes some time to setup/initialise that controller's driver and during this time BIOS continues to handle the other controller/s to avoid problems; then OS takes control of the other controllers when it's ready).

It's also doesn't fit my "theory of how things are done". Typically, how things like this are done is that the hardware manufacturer copies and pastes their pre-existing "UHCI/OHCI circuit" into their new EHCI chip without changing anything, then the firmware developer adds new EHCI code to their firmware without changing any of the existing UHCI/OHCI code; where neither hardware manufacturer nor firmware developer bother to do any additional "if OS takes control of EHCI then assume it also takes control of companions" work.

BenLunt wrote:If I release control of something, shouldn't I release control of all things that the first thing has control over?

The EHCI controller doesn't have control over the companions, it only has control over a little switch/router.

Imagine if there's a "companion-less EHCI controller" from one manufacturer in PCI slot #1, and a UHCI controller from a different manufacturer in PCI slot #3. Now imagine that someone adds a little switch/router so that the same physical USB port can be connected to either of the completely separate and independent USB controllers. In this case it would be incredibly silly for an OS to make assumptions about hypothetical "behavioural cross contamination" between these completely separate USB controllers.

Excluding the enumeration/identification requirements and the port routing control; there is no reason to assume that "EHCI plus companion controller in the same PCI device and in the same chip" is any different to "companion-less EHCI with completely separate UHCI" .

BenLunt wrote:Anyway, with a few minor modifications to account for faulty BIOS code, I now request for control of the EHCI, then each of its companion controllers before I do anything with the EHCI.

Sometimes when hardware/firmware seems dodgy there's a magic sequence that happens to work because it happens to match the order that Windows does things (and matches what was tested). With this in mind (and without knowing the order Windows actually does things); I'd assume that (for dodgy hardware/firmware) the safest order would be to take control of the companions first, and then take control of the EHCI controller; partly because it's more natural to do PCI enumeration in ascending order, and partly because "old OS with UHCI driver but without EHCI driver" is far more likely than "new OS with EHCI driver but without UHCI driver" and therefore also more likely that the firmware handles "OS has taken control of companion controllers but hasn't taken control of the EHCI controller yet" properly for a tiny amount of time.


Cheers,

Brendan

Brendan wrote:

BenLunt wrote:If I release control of something, shouldn't I release control of all things that the first thing has control over?

The EHCI controller doesn't have control over the companions, it only has control over a little switch/router.

Without sounding like I am trying to fight with you, and I am not, I do see what your point is and I (mostly) agree. However, I just have one little thing about that switch/router.

An example; there is a night class at school, with five students (companions), and I (EHCI) am given control of the light switch. I don't have any control of the students, the teacher (BIOS) still does, but I have control of the light switch. If I flip the switch, the students can't do a darn thing in the dark and the teacher has no idea what they are doing. As far as the teacher is concerned, they are still sitting in their assigned seats. However, since I have thrown the light switch, two of the students get a little friendly. The teacher still assumes they are apart and just sitting there, yet since I have control of the light switch, the teacher now has no control of the students, but really doesn't know that he/she doesn't still have control. Therefore, shouldn't the teacher, when giving control of the light switch to me, want to give control of all the students to me as well?

In my opinion, if I am given control of the light switch, I should also assume that the students need to be under my control because of this switch. I would not want to be the teacher, assuming that things are just fine and dandy, when they really aren't.

Brendan wrote:

BenLunt wrote:Anyway, with a few minor modifications to account for faulty BIOS code, I now request for control of the EHCI, then each of its companion controllers before I do anything with the EHCI.

Sometimes when hardware/firmware seems dodgy there's a magic sequence that happens to work because it happens to match the order that Windows does things (and matches what was tested).

Amen to that. I totally agree here. It is very sad that most products pass inspection as long as they work on Windows...

Thanks,
Ben

Hi,

BenLunt wrote:

Brendan wrote:

BenLunt wrote:If I release control of something, shouldn't I release control of all things that the first thing has control over?

The EHCI controller doesn't have control over the companions, it only has control over a little switch/router.

Without sounding like I am trying to fight with you, and I am not, I do see what your point is and I (mostly) agree. However, I just have one little thing about that switch/router.

An example; there is a night class at school, with five students (companions), and I (EHCI) am given control of the light switch. I don't have any control of the students, the teacher (BIOS) still does, but I have control of the light switch. If I flip the switch, the students can't do a darn thing in the dark and the teacher has no idea what they are doing. As far as the teacher is concerned, they are still sitting in their assigned seats. However, since I have thrown the light switch, two of the students get a little friendly. The teacher still assumes they are apart and just sitting there, yet since I have control of the light switch, the teacher now has no control of the students, but really doesn't know that he/she doesn't still have control. Therefore, shouldn't the teacher, when giving control of the light switch to me, want to give control of all the students to me as well?

A better example: Several students (see note) are each sitting alone in their own separate room with their own separate light switch. One of the students is able to control if emails are routed to other students or to themselves, but "email routing" has nothing to do with light switches at all.

Note: For almost everything (IRQs, BARs, PCI configuration space, ...) an EHCI controller and its companion controllers are equal peers and there is no "master and slaves" relationship. The only minor exception to this is control over port routing, but that is purely for convenience (to avoid the hassle of having a separate "port router device" with its own separate PCI configuration space, etc).


Cheers,

Brendan