PS/2 controller acting weird

[gerryg400]

Antti, which part/parts don't work ?

[rdos]

It just does not work on this real machine. Even the echo fails. I cannot say for sure whether the keyboard is available or not. However, this is not a big problem.

At least my code works on all real machines I've tested on (at least 20 different), including some that has USB-emulations. It even works on the portable which has a bad touch-pad emulating a PS/2 mouse that doesn't follow the usual mouse protocol.

It should be fairly simply to determine if the keyboard is available. Look at some other OS (installed driver), or try it with some boot-loader to make sure it works.

As for detecting presence, can't you do that by toggling keyboard LEDs (caps lock, num lock or similar)? Those should always work, unlike the RESET logic which really doesn't need to work.

[Antti]

which part/parts don't work

Keyboard reply is always 0xFE (resend), for the test and echo. I cannot even set the LEDs but I have not tested that case very carefully. I tried to ignore the error response (the 0xFE, resend) for the test command and kept waiting the 0xAA. It did not show up.

Like I have said, this problem occurs only on one test machine. Virtualbox and other test machine work just fine. One interesting fact: when I start my "OS", keyboard leds are off. When I press any key, the NumLock led turns on. I think the USB keyboard somehow initialize itself when any key is pressed first time. I also tried to run the reset after that but the result is the same.

[gerryg400]

Antti, if this is a USB keyboard and the PS/2 is emulation then all bets are off.

As long as it works in some way, just be happy.

[Antti]

I know that this whole PS/2 is emulated nowadays and I am heading to "full" USB implementation in the future. Of course I want to support PS/2 interface also.

Exactly. However, this could be the first time I found "errors" in hardware/firmware. What I mean: almost always it is my code that contains the error.

[Brendan]

Hi,

I know that this whole PS/2 is emulated nowadays and I am heading to "full" USB implementation in the future. Of course I want to support PS/2 interface also.

Exactly. However, this could be the first time I found "errors" in hardware/firmware. What I mean: almost always it is my code that contains the error.

For "PS/2 emulation" I don't think I've seen a case where the emulation is anywhere near correct. Usually the emulation is just enough to handle getting scancodes and setting LEDs, and anything more than that is "high risk" (likely broken).

Of course the correct way to handle this is to write USB drivers (including USB controller drivers that disable any PS/2 emulation), and to make sure USB drivers are started before any PS/2 driver is started. The worse way to handle the problem is to cripple your PS/2 initialisation code so that it's bad enough to work for "PS/2 emulation".


Cheers,

Brendan

[rdos]

I have to disagree on the issue of not supporting PS/2 USB emulation. Since there really is no sense in using RESET or other non-essential PS/2 functions, and this probably breaks for USB PS/2 emulations, it is an easy decision to increase compability by either not validating RESET, or not doing it at all. You don't create any type of added user functionality by insisting on doing a RESET, and if your USB stack doesn't work for some reason, not having a PS/2 fallback means you cannot interact with the machine in question.

[Brendan]

Hi,

I have to disagree on the issue of not supporting PS/2 USB emulation. Since there really is no sense in using RESET or other non-essential PS/2 functions, and this probably breaks for USB PS/2 emulations, it is an easy decision to increase compability by either not validating RESET, or not doing it at all. You don't create any type of added user functionality by insisting on doing a RESET, and if your USB stack doesn't work for some reason, not having a PS/2 fallback means you cannot interact with the machine in question.

Plug a USB keyboard in and a PS/2 keyboard and see if you can get both to work at the same time.


Cheers,

Brendan

[rdos]

Plug a USB keyboard in and a PS/2 keyboard and see if you can get both to work at the same time.

I don't need to. I either load the PS/2 driver or the USB HID driver, not both at the same time.

First I'll try the USB HID driver (as that's likely to work best), and as a fallback I'll remove USB support and add the PS/2 driver.

Come to think of it, maybe you wondered if it is possible to use both an USB-keyboard and a real PS/2 keyboard, and I can assure you this is possible. In fact, it is possible to debug the USB HID keyboard using a real PS/2 keyboard. I can even use a numerical, vandal-safe keyboard to output digits to command line. That's because all keyboard devices send their keys to a common keyboard driver, and thus doesn't setup it's own interface for userlevel. You should copy this design.

[Brendan]

Hi,

I have to disagree on the issue of not supporting PS/2 USB emulation. Since there really is no sense in using RESET or other non-essential PS/2 functions, and this probably breaks for USB PS/2 emulations, it is an easy decision to increase compability by either not validating RESET, or not doing it at all. You don't create any type of added user functionality by insisting on doing a RESET, and if your USB stack doesn't work for some reason, not having a PS/2 fallback means you cannot interact with the machine in question.

Plug a USB keyboard in and a PS/2 keyboard and see if you can get both to work at the same time.

I don't need to. I either load the PS/2 driver or the USB HID driver, not both at the same time.

First I'll try the USB HID driver (as that's likely to work best), and as a fallback I'll remove USB support and add the PS/2 driver.

Come to think of it, maybe you wondered if it is possible to use both an USB-keyboard and a real PS/2 keyboard, and I can assure you this is possible.

Imagine a professional school bus driver that drives through a railway crossing at the same time every day, but never bothers to check for oncoming trains because there's never a train coming at that time of day. This "works" (as far as the bus driver knows), but that school bus driver would still be a reckless moron.

Failing to adequately initialise the PS/2 hardware "works" (as far as you know). Does this make it acceptable? In my opinion it indicates a severe lack of professionalism.

Imagine if there's a USB keyboard and PS/2 emulation is enabled, and there's also a real PS/2 keyboard; and your USB driver disables the PS/2 emulation (so that both USB keyboard and PS/2 keyboard can work). In this case, your PS/2 driver can't assume the firmware initialised the PS/2 hardware correctly as the firmware assumed you'd be using emulated PS/2 and not real PS/2.

Imagine if there's 2 PS/2 mouses plugged in (and the BIOS is set to "ignore keyboard errors").

Imagine if the hardware is faulty and the BIOS PS/2 initialisation code is crappy.

Imagine if your OS didn't boot from BIOS. For example, maybe your OS supports something like kexec and you can't be sure what state the PS/2 hardware was left in.

Imagine if someone wants to use your kernel in an embedded system, so they replace the BIOS with a custom bootloader that loads your kernel directly from ROM.


Cheers,

Brendan

[rdos]

Failing to adequately initialise the PS/2 hardware "works" (as far as you know). Does this make it acceptable? In my opinion it indicates a severe lack of professionalism.

For most other devices I agree with you, but the fact is that a BIOS must initialize the keyboard because otherwise you cannot enter the BIOS, and the typical BIOS keyboard functions will not work. Given that RESET doesn't even work on some keyboards, I don't think it is a good idea to reset the keyboard.

Imagine if there's a USB keyboard and PS/2 emulation is enabled, and there's also a real PS/2 keyboard; and your USB driver disables the PS/2 emulation (so that both USB keyboard and PS/2 keyboard can work). In this case, your PS/2 driver can't assume the firmware initialised the PS/2 hardware correctly as the firmware assumed you'd be using emulated PS/2 and not real PS/2.

AFAIK, there cannot be multiple PS/2 compatible keyboards, as there is only one IRQ and one set of IO ports. If there is a real PS/2 keyboard, an USB keyboard cannot be setup to PS/2 emulation.

Imagine if someone wants to use your kernel in an embedded system, so they replace the BIOS with a custom bootloader that loads your kernel directly from ROM.

In that case it would be the chipset specific setup driver that would also enable and setup PS/2 keyboard.

[Brendan]

Hi,

Failing to adequately initialise the PS/2 hardware "works" (as far as you know). Does this make it acceptable? In my opinion it indicates a severe lack of professionalism.

For most other devices I agree with you, but the fact is that a BIOS must initialize the keyboard because otherwise you cannot enter the BIOS, and the typical BIOS keyboard functions will not work. Given that RESET doesn't even work on some keyboards, I don't think it is a good idea to reset the keyboard.

Ironically, I've seen lots of computers that support both PS/2 and USB where you can't use a USB keyboard to enter the BIOS (even though "PS/2 emulation" is enabled and works in real mode/DOS).

I've never seen real PS/2 hardware where reset doesn't work. I think you mean "USB keyboard without a decent USB driver where the PS/2 emulation is broken and doesn't support reset", but you should use a USB driver and disable the emulation in that case anyway.

Imagine if there's a USB keyboard and PS/2 emulation is enabled, and there's also a real PS/2 keyboard; and your USB driver disables the PS/2 emulation (so that both USB keyboard and PS/2 keyboard can work). In this case, your PS/2 driver can't assume the firmware initialised the PS/2 hardware correctly as the firmware assumed you'd be using emulated PS/2 and not real PS/2.

AFAIK, there cannot be multiple PS/2 compatible keyboards, as there is only one IRQ and one set of IO ports. If there is a real PS/2 keyboard, an USB keyboard cannot be setup to PS/2 emulation.

This scenario should be no problem. Your USB driver should disable the PS/2 emulation and the USB keyboard (and USB driver) should work fine; and your PS/2 driver should reset/initialise the real PS/2 hardware (after emulation is disabled) and the PS/2 keyboard should work fine too. You can even have 2 PS/2 keyboards and 5 USB keyboards all working at the same time.

Of course if you don't do things right (e.g. if you don't disable the PS/2 emulation or don't reset/initialise the real PS/2 hardware) it probably won't work.

Imagine if someone wants to use your kernel in an embedded system, so they replace the BIOS with a custom bootloader that loads your kernel directly from ROM.

In that case it would be the chipset specific setup driver that would also enable and setup PS/2 keyboard.

So you'd make it harder for embedded system developers to write the custom boot loader needed to use your kernel/OS in their products?

The other problem is that it's slow - the firmware/boot loader has to wait until the hardware is initialised before starting the OS. Alternatively (if the OS did it instead) the OS can initialise the PS/2 hardware while initialising other drivers, doing DHCP, and starting GUI, etc; and reduce boot times by half a second or more. This can be important for some types of embedded systems ("instant on"), and even when it's not important it's still very nice.


Cheers,

Brendan

[rdos]

So you'd make it harder for embedded system developers to write the custom boot loader needed to use your kernel/OS in their products?

The other problem is that it's slow - the firmware/boot loader has to wait until the hardware is initialised before starting the OS. Alternatively (if the OS did it instead) the OS can initialise the PS/2 hardware while initialising other drivers, doing DHCP, and starting GUI, etc; and reduce boot times by half a second or more. This can be important for some types of embedded systems ("instant on"), and even when it's not important it's still very nice.

When RDOS is loaded from ROM, there is no bootloader. The complete OS image is contained in the ROM. There must be a module that is linked to the RESET vector which needs to initialize the chipset, RAM and processor. This code must run first. Then the code will look for the signature of the kernel in the ROM, and jump to it. This means there need be no disk in such a setup. Since ROM is typically slow, the initialization code would probably copy the entire ROM to RAM, and then execute from RAM. RDOS was designed for this from the start, which is why the bootloader will typically read the kernel image into memory, and then search for the correct signature for kernel in memory, and then jump to it.

I've not yet done such a system, but I once had plans. What I have done is to use two AM74F040B flashes on a diskless 386-based embedded board. This setup still had a BIOS, but booting was done from ROM.

[Brendan]

Hi,

So you'd make it harder for embedded system developers to write the custom boot loader needed to use your kernel/OS in their products?

The other problem is that it's slow - the firmware/boot loader has to wait until the hardware is initialised before starting the OS. Alternatively (if the OS did it instead) the OS can initialise the PS/2 hardware while initialising other drivers, doing DHCP, and starting GUI, etc; and reduce boot times by half a second or more. This can be important for some types of embedded systems ("instant on"), and even when it's not important it's still very nice.

When RDOS is loaded from ROM, there is no bootloader. The complete OS image is contained in the ROM. There must be a module that is linked to the RESET vector which needs to initialize the chipset, RAM and processor. This code must run first. Then the code will look for the signature of the kernel in the ROM, and jump to it. This means there need be no disk in such a setup. Since ROM is typically slow, the initialization code would probably copy the entire ROM to RAM, and then execute from RAM. RDOS was designed for this from the start, which is why the bootloader will typically read the kernel image into memory, and then search for the correct signature for kernel in memory, and then jump to it.

So, during boot there's code that prepares things for the kernel, "loads" (copies) the kernel into RAM, then passes control to the kernel; but in some way the code that loads the kernel during boot is not a boot loader?

I've not yet done such a system, but I once had plans. What I have done is to use two AM74F040B flashes on a diskless 386-based embedded board. This setup still had a BIOS, but booting was done from ROM.

I've done it with Bochs (e.g. where the normal "BIOS-bochs-latest" ROM image is replaced by my ROM image that contains my OS).

It was actually relatively easy; partly because for Bochs you don't need to initialise some things that you normally would (e.g. memory controller - unlike real hardware the RAM just works at power on), partly because I design my OS to be firmware independent (the only thing that cares what sort of firmware there was is the boot loader), and partly because my OS doesn't make silly assumptions about the state of hardware and initialises things like the PS/2 controller correctly (so the "boot from ROM" boot loader doesn't need to worry about it).

Also note that it was extremely fast. Normally Bochs BIOS takes half a second initialising irrelevant/unnecessary stuff and then my code takes another half a second or so to load data from disk. Getting rid of the BIOS and the disk IO means the OS booted in 1 second instead of 3 seconds.


Cheers,

Brendan

[rdos]

So, during boot there's code that prepares things for the kernel, "loads" (copies) the kernel into RAM, then passes control to the kernel; but in some way the code that loads the kernel during boot is not a boot loader?

There is nothing to prepare. Generally, the entire ROM image must be copied to RAM in order to execute at reasonable speed, so this is done already at memory controller initialization time. If you call a memory scan for the kernel image for a boot-loader, then, ok, there is a boot-loader

BTW, even that could be eliminated by putting the kernel at a fixed address. Then there would be no boot-loader.

I've done it with Bochs (e.g. where the normal "BIOS-bochs-latest" ROM image is replaced by my ROM image that contains my OS).

It was actually relatively easy; partly because for Bochs you don't need to initialise some things that you normally would (e.g. memory controller - unlike real hardware the RAM just works at power on), partly because I design my OS to be firmware independent (the only thing that cares what sort of firmware there was is the boot loader), and partly because my OS doesn't make silly assumptions about the state of hardware and initialises things like the PS/2 controller correctly (so the "boot from ROM" boot loader doesn't need to worry about it).

Doing this in Bochs is not a realistic scenario since you don't need to initialize the chipset in Bochs. Part of initializing the chipset is initializing the PS/2 controller, as most chipsets have registers related to that. Chipset initialization on modern machines is very complex, and chipset manuals are 1000s of pages if they are available at all. This was more interesting on 386 and 486 processors / chipsets. I don't think I'd do this on latter systems.

Another issue would be how to keep the system alive if you download something that malfunctions. At the very minimum, you would need some spare flash chips, a tool to remove the flash, and a programmer to even consider this. Although it might be interesting to see if the computer sellers technical support can solve such an issue.

Also note that it was extremely fast. Normally Bochs BIOS takes half a second initialising irrelevant/unnecessary stuff and then my code takes another half a second or so to load data from disk. Getting rid of the BIOS and the disk IO means the OS booted in 1 second instead of 3 seconds.

I think it would be possible to boot real machines in sub-seconds by replacing BIOS, but it seems like a lot of work.