PS/2 initialisation sequence

[glauxosdever]

Hi,


I'm trying to make a correctly working PS/2 driver. I followed the initialisation sequence on the wiki, but on my computer testing the first channel seems to read back 0x50. Success would be 0x00, and documented are errors 0x01, 0x02, 0x03, 0x04. Testing the second channel returns 0x00.

Has anyone encountered reading 0x50 when testing a PS/2 channel? I couldn't find it listed anywhere.


Regards,
glauxosdever

[Brendan]

Hi,

I'm trying to make a correctly working PS/2 driver. I followed the initialisation sequence on the wiki, but on my computer testing the first channel seems to read back 0x50. Success would be 0x00, and documented are errors 0x01, 0x02, 0x03, 0x04. Testing the second channel returns 0x00.

Has anyone encountered reading 0x50 when testing a PS/2 channel? I couldn't find it listed anywhere.

I can't find it anywhere either. There's only 3 possibilities I can think of:

• It's old data from a previous command that wasn't read. In this case repeating the same interface test should give a different result.
• It's non-standard and undocumented, but does come from the PS/2 controller. In this case it might help to know which chipset the computer uses.
• It's non-standard and undocumented, but comes from "PS/2 emulation for USB devices" firmware code that's almost always buggy/unreliable. In this case unusual behaviour of any kind should be expected.

Cheers,

Brendan

[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 what other conditions should I test again?

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.

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


Regards,
glauxosdever

[onlyonemac]

Does your code work in an emulator such as QEMU? If so then I'm going to suspect that your hardware is buggy and the best option would be to disable any PS/2 channel which doesn't return a "success" byte on initialisation.

[Brendan]

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).

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.

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".

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

You shouldn't need to check at all.


Cheers,

Brendan

[mallard]

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".

Firstly, a PS/2 driver has absolutely no business knowing anything about USB. That completely violates the principle of Separation of Concerns. Once you have a USB driver, sure, load it before PS/2 so that it can disable emulation, but if you don't, it's entirely wrong to put USB code in a PS/2 driver.

Secondly, "the firmware's PS/2 emulation will completely screw everything up" is a massive exaggeration. You can be pretty confident that the firmware's PS/2 emulation has been tested with common OSs (e.g. Windows), so unless you're trying to do something pretty unusual (e.g. using scan set 3, non-keyboard/mouse PS/2 devices, etc) it'll work "well enough". The worst thing that's likely to happen is that you may not be able to use real PS/2 devices if you boot with a USB keyboard/mouse connected.

Note that even a "real" 8042-compatible PS/2 controller is just as much a software implementation as any "emulation" and may well contain bugs; the 8042 was a general-purpose microcontroller. Modern systems don't even contain an actual 8042; they implement the interface on an entirely different, much more advanced, microcontroller. On very recent systems with SoC-style features and highly-integrated "southbridge" chips the very same software routines are likely shared between USB-PS/2 "emulation" and "real" PS/2 device support (assuming that such a system even has "real" PS/2 device support; these days the ports are rare, but laptops commonly have their internal input devices connected to a PS/2 bus).

[FallenAvatar]

Secondly, "the firmware's PS/2 emulation will completely screw everything up" is a massive exaggeration. You can be pretty confident that the firmware's PS/2 emulation has been tested with common OSs (e.g. Windows),

You mean OSes that load USB Drivers and disable PS/2 emulation ASAP? (Just like Brendan suggested?)

- Monk

[mallard]

You mean OSes that load USB Drivers and disable PS/2 emulation ASAP? (Just like Brendan suggested?)

Brendan suggested that "step 1" of the PS/2 initialisation sequence is to initialise USB (note that he wrote the wiki article that promotes this). That implies that either; the PS/2 driver should have knowledge of USB (incredibly bad software design) or that in order to implement PS/2 you must first implement USB support, which vastly increases the work needed.

Windows has not always had USB support. Windows NT 4.0 was the last version with no official USB support at all and was supported by Microsoft until 2004 (and was still pretty common for a few years after that), so firmware developers would likely have tested at least minimum functionality for it until around then. Even long after that, the ability to boot DOS (although most DOS software uses the BIOS for the keyboard, accessing the controller directly isn't exactly rare and is required for the mouse) for things like diagnostic utilities, firmware updates, etc. was still important. Even today, things like the UBCD (which contains a decent number of DOS-based diagnostic/setup utilities) are pretty common. I've yet to see a system with PS/2 emulation that isn't at least basically functional.

Not to mention that pretty much every full-system emulator/virtualizor (e.g. Bochs, QEMU, VMWare, VirtualBox) has it's own bugs and quirks in the 8042 interface. Working around buggy/quirky hardware/firmware is an important part of OSDev, especially when you're writing for a platform that had no real "controlling authority" for what was probably the most important and innovative period of its development (the post-IBM, pre-Microsoft/Intel period ~1987-1997).

[FallenAvatar]

You mean OSes that load USB Drivers and disable PS/2 emulation ASAP? (Just like Brendan suggested?)

Brendan suggested that "step 1" of the PS/2 initialisation sequence is to initialise USB (note that he wrote the wiki article that promotes this). That implies that either; the PS/2 driver should have knowledge of USB (incredibly bad software design) or that in order to implement PS/2 you must first implement USB support, which vastly increases the work needed.

Umm, not sure how you get that the PS/2 drivers needs to know about USB from that. Seems simple enough that you just discover devices in an order that guarantees that USB (if it exists) is initialized before starting PS/2 drivers...

- Monk

[mallard]

Umm, not sure how you get that the PS/2 drivers needs to know about USB from that. Seems simple enough that you just discover devices in an order that guarantees that USB (if it exists) is initialized before starting PS/2 drivers...

Yes, once you have USB support, that's exactly what you'd do. However, it usually makes sense to implement PS/2 support before USB support (because USB support is so much more complex being able to issue commands to your OS to help in debugging it is pretty useful), so to begin with at least, you're relying on the hardware/firmware's PS/2 support being usable, which is almost always is, despite quirks/bugs.

[onlyonemac]

Firstly, a PS/2 driver has absolutely no business knowing anything about USB. That completely violates the principle of Separation of Concerns. Once you have a USB driver, sure, load it before PS/2 so that it can disable emulation, but if you don't, it's entirely wrong to put USB code in a PS/2 driver.

I propose an alternative approach: make the PS/2 driver disable PS/2 emulation for USB devices as soon as it loads, then the PS/2 driver can handle just the real PS/2 devices. If there aren't any real PS/2 devices, the PS/2 driver has nothing to do an can terminate/unload itself or whatever is applicable to your driver architecture. Any USB keyboard/mice can then be handled by the USB driver once it has loaded, no matter whether or not there are any PS/2 devices. (Technically if this approach is taken, it doesn't matter which driver loads first, and your PS/2 driver isn't doing anything USB-related beyond disabling PS/2 emulation.)

[FallenAvatar]

Firstly, a PS/2 driver has absolutely no business knowing anything about USB. That completely violates the principle of Separation of Concerns. Once you have a USB driver, sure, load it before PS/2 so that it can disable emulation, but if you don't, it's entirely wrong to put USB code in a PS/2 driver.

I propose an alternative approach: make the PS/2 driver disable PS/2 emulation for USB devices as soon as it loads, then the PS/2 driver can handle just the real PS/2 devices. If there aren't any real PS/2 devices, the PS/2 driver has nothing to do an can terminate/unload itself or whatever is applicable to your driver architecture. Any USB keyboard/mice can then be handled by the USB driver once it has loaded, no matter whether or not there are any PS/2 devices. (Technically if this approach is taken, it doesn't matter which driver loads first, and your PS/2 driver isn't doing anything USB-related beyond disabling PS/2 emulation.)

Except that disabling PS/2 Emulation is a function of USB, not of the PS/2 directly. Trying to make the PS/2 driver disable emulation would require exactly what mallard is complaining about.

- Monk

[mallard]

I propose an alternative approach: make the PS/2 driver disable PS/2 emulation for USB devices as soon as it loads, then the PS/2 driver can handle just the real PS/2 devices. If there aren't any real PS/2 devices, the PS/2 driver has nothing to do an can terminate/unload itself or whatever is applicable to your driver architecture. Any USB keyboard/mice can then be handled by the USB driver once it has loaded, no matter whether or not there are any PS/2 devices. (Technically if this approach is taken, it doesn't matter which driver loads first, and your PS/2 driver isn't doing anything USB-related beyond disabling PS/2 emulation.)

What happens if you load this driver on a PC with no USB support? What happens if someone comes up with a new type USB controller that your PS/2 driver doesn't know about? What if someone invents an entirely new peripheral bus that's used to emulate PS/2 instead of USB? What about a new kind of system bus that USB controllers are connected to?

If your PS/2 and USB drivers are entirely separate the answers are; don't load the USB driver(s), update only the USB driver(s)/produce a new driver for the new controller, either implement a driver for the new peripheral bus or rely on its emulation being usable and pretty much the same for a new system bus.

If your PS/2 driver also has knowledge of USB, you've got to update the PS/2 driver in all cases except the first (for which you've got to implement complex USB detection logic in your PS/2 driver). This will quickly make your PS/2 driver orders of magnitude larger and more complex than it needs to be.

[Combuster]

Another list of problems to feed everyone's paranoia:

- Some (old) bioses actually disable USB-to-PS/2 emulation when you try to do certain things with the PS/2 controller typical of modern OS initialisation.
- PS/2 emulation of itself is known to be shabby and your chances are that only DOS-grade tricks are likely to be supported and the rest essentially depends on the phase of the moon.
- Even actual PS/2 controllers aren't fully compatible with the old IBM's PS/2 implementation
- As mentioned before, Initializing USB disables emulation so the devices you once found might vanish if you do things in the wrong order.

Have fun writing defensively against that

But it looks that, for now, the problem is an incomplete PS/2 implementation you'll have to deal with. At which point it doesn't quite matter if it's an instance of issue #2 or #3.

[mallard]

- Some (old) bioses actually disable USB-to-PS/2 emulation when you try to do certain things with the PS/2 controller typical of modern OS initialisation.

Fine by me. (Although I'm curious as to what a "modern" OS does with the PS/2 controller that NT 4.0 didn't do. Those old BIOSes must have worked with it...) Since the relying-on-emulation thing is a temporary state while the OS has PS/2 support but not USB support, I offer no guarantees as to whether or not it'll work with USB-to-PS/2 emulation. All I'm saying is "don't put USB code in the PS/2 driver" and "it's fine to be in a state where you have PS/2 support but don't yet have USB support".

- PS/2 emulation of itself is known to be shabby and your chances are that only DOS-grade tricks are likely to be supported and the rest essentially depends on the phase of the moon.

I'm really not sure what people seem to want to do with their keyboards and mice that weren't common back in the days of DOS. It's not like those devices have changed radically. Plenty of DOS software did "advanced" things like changing scan set, changing typematic rate, disabling key repeat, etc. Maybe you won't be able to support the extra buttons and wheels on your expensive "gaming class" USB mouse if you're using emulation, but again, see above; that's fine by me.

- Even actual PS/2 controllers aren't fully compatible with the old IBM's PS/2 implementation

Even IBM's PS/2 controllers had differences... But yes, since the "8042" PS/2 interface was always a software interface, there have always been buggy/quirky implementations.

- As mentioned before, Initializing USB disables emulation so the devices you once found might vanish if you do things in the wrong order.

Yep. So make sure you're using real PS/2 input devices while you're debugging USB support...