PS/2 initialisation sequence

[glauxosdever]

Hi,

It seems that repeating the same command returned 0x00 the second time. Strange, since the previous command was just disabling the second port.

In that case, it sounds like you're not following the sequence in the wiki; where there's 4 steps between "step 3, disable devices" and "step 8, interface tests", and where one of the steps in between is "step 4, flush the output buffer". Note that while many different sequences are possible, the specific sequence described on the wiki was carefully designed to avoid race conditions (like user pressing a key at exactly the wrong time).

Well, I was refering to the disabling of the second channel after confirming the controller is dual channel (step 7).

In what other conditions should I test again?

For your case, I'd assume it might make sense to have a "retry interface test 3 times before assuming test failed" loop.

Ok, I have a 2 times loop, though after some more research it turned out that OpenBSD for example didn't even do interface tests. I need to clear this up still.

I now got a new problem, the first port translation bit in the configuration byte gets set again, although I disable it. At the end, the POST passed bit gets cleared too.

Now I'm wondering if you correctly did "step 1, initialise USB controllers because otherwise the firmware's PS/2 emulation will completely screw everything up".

Well, I didn't do step 1 and step 2, as I don't have any drivers for them yet (though I had a USB driver in my older kernel).

Should I always read the configuration byte after writing it in order to check integrity?

You shouldn't need to check at all.

This would be ideal, but PS/2 translation isn't disabled on my hardware.

As to others who have answered in this thread, I'm fine with emulation for now. I even think, since I have a laptop, that the keyboard is connected through PS/2, and not USB. I will see what will be best for later.


Regards,
glauxosdever

[Brendan]

Hi,

Well, I was refering to the disabling of the second channel after confirming the controller is dual channel (step 7).

Ah - that makes more sense.

Ok, I have a 2 times loop, though after some more research it turned out that OpenBSD for example didn't even do interface tests. I need to clear this up still.

Sadly, a lot of OSs assume hardware always works. Hardware never works forever; and when it fails it's nice to know that it has failed (and it's not a problem with software) and which part failed (e.g. whether it's "keyboard not quite plugged in properly" or "motherboard needs to be replaced").

Now I'm wondering if you correctly did "step 1, initialise USB controllers because otherwise the firmware's PS/2 emulation will completely screw everything up".

Well, I didn't do step 1 and step 2, as I don't have any drivers for them yet (though I had a USB driver in my older kernel).

In that case, it's very likely that firmware's "PS/2 emulation for USB devices" is the cause of all the problems (even if you happen to be using real PS/2 devices).

Essentially; when this is enabled any read or write to the PS/2 controller's IO ports causes an SMI, and the firmware's system management code has to try to figure out what to do about it (which can involve talking to USB and talking to the real PS/2 controller). The firmware's system management code is rarely able to do more than handle the simple/common things (like key presses and mouse packets) and everything else (e.g. proper PS/2 controller initialisation) is a mine field of unsupported and/or buggy cases.

Note that you don't need a full USB driver - you'd only need enough to disable emulation. This is different for different types of USB controller, but mostly involves something like (e.g.) setting a bit in PCI configuration space or a memory mapped USB controller register and waiting (polling with time-out) until another bit is cleared.

Also note that very old (10 years ago?) versions of Bochs didn't allow translation to be disabled. Fortunately, if translation can't be disabled for some reason, when you get to detecting the type of device plugged into each PS/2 port a keyboard's identification gets mangled by the translation and becomes something else (e.g. "0xAB, 0x41" and not "0xAB, 0x83"), which means that it's easy to support this case with a different keyboard driver (e.g. your PS/2 controller driver does "identify" and then ends up loading/starting "/sys/drivers/PS2_AB41.drv" instead of "/sys/drivers/PS2_AB83.drv").

Of course this also means that if a user plugs a mouse into the first PS/2 port it's impossible to support it (the translation isn't reversible and there's no way to reconstruct the original mouse data after the data has been mangled).


Cheers,

Brendan