OSDev.org

Hi guys. I got one for you.

I jump at the chance to test my code on any machine that someone dares to let me. (Suckers!!). Anyway, I have a chance to use a later model (10 year old) laptop and my keyboard code wasn't working. After some digging, I found out I was receiving Scan Set 1 while expecting Scan Set 2. I went digging some more and I actually think that this keyboard controller (8042?) may be bad and not disabling translation.

To get right down to the bare controller, I ran a test.
Resulting in:
I sent the reset and disable twice, just to be sure. Got ACK back each time.

I sent the Self Test and received 0x55 as expected.

I read the Command Byte to see if translation is enabled--read back 0x65--meaning that it is enabled.
I wrote the byte back, now with bit 6 clear.

Then I read it back to see if the bit actually cleared, and it did--read back 0x25.

Then I write the scan code set I wish to use (2) to the keyboard--Got ACK for both written bytes.

I then read the Command Byte again, just to check--Still 0x25. Translation off.

I then read the current Scan Code Set to see what it reports--Again, got both ACKs and the expected '2'.

I then enabled the keyboard.

Sounds correct, yes? However, I typed "ben" and got the following:

0x30, 0xB0
0x12, 0x92
0x31, 0xB1

Clearly still using Scan Set 1.

I don't know if the keyboard is sending Scan Set 1 and the controller is not converting, or visa-versa, the keyboard is sending Set 2 and the controller *is* translating. Either way, it is in error.

This machine boots to Win Vista just fine, keyboard works. The BIOS uses the correct (either set) settings, since I can type within my loader code, receiving the expected BIOS scan code.

Therefore, the BIOS and Win Vista either assume Set 1, have a way to test for the current set, or my code is just flat out wrong.

Anyway, if anyone has an idea, please let me know.

Edit 0:
Another comment: I set the keyboard to scan set 3, the keyboard ACK okay (0xFA) yet, I still received scan set 1. I set the scan set to 4 and got the expected error code (0xFC). Keyboard is probably working just fine. It is probably the controller translating all code to scan set 1. period. I will do some more digging.

Thanks,
Ben
-- http://www.fysnet.net/blog

The BIOS assumes set 1 by default, since that's required for compatibility with DOS software (though not necessarily DOS itself). Whether the keyboard controller is translating from set 2/set 3 or providing untranslated set 1 directly from the keyboard is irrelevant to the BIOS.

Windows typically operates with translation enabled and the keyboard configured for set 2, which is effectively the same as set 1. Unfortunately, that's the default power-on state for most PCs, so I have no idea what Windows would do if the PC didn't boot in that configuration.

Linux probes the keyboard controller to determine if translation is enabled, but doesn't attempt to disable translation for compatibility with power management firmware (SMM) that expects scan codes in set 1. Linux operates most keyboards in set 2 (which the keyboard controller may or may not translate to set 1), but it detects the ID of the keyboard and depending on the ID it may instead switch the keyboard to set 3 (which may still be translated).

Have you disabled USB legacy emulation? I'm sure you're much more familiar with USB than I am, but I figured I should ask just in case.

Do you continue to receive scan codes from set 1 even with translation enabled and the keyboard programmed for set 1? (On fully IBM-compatible hardware, this combination should result in nonsense scan codes.)

Does the laptop have a PS/2 port, or support for a dock that may include a PS/2 port? Multiplexing between PS/2 ports can be... challenging.

What kind of laptop is it, anyway?

This, I figured, since this was the whole reason for the translation to begin with.


This is why this issue came up for me. I do not assume anything and check to see what set is being sent and if it is being translated.


The problem is that I might need, and sometimes do need keyboard interaction before the USB is detected. For example, when booting from USB, of course you know that the USB is being emulated, but when booting from USB, then trying to detect which device/partition/etc I booted from, the emulated USB media is no longer available. Therefore, I ask the user to select from a displayed list, which needs keyboard interaction.


No difference. In fact, some of the key presses, no matter the keyboard's scan code setting, return additional break codes. For example, the right arrow returns the expected make code and the first two bytes are the expected break code, but appends another two-byte break code. This happens no matter what setting I am using. Both translated and untranslated, scan set 1, 2, or 3.


The laptop does not include an external PS/2 port. After more digging, and telling my OS to assume (uurrrggg) scan set 1, I was able to continue booting. I then was able to find out that the keyboard and pointer device pad (the little mouse moving device pad in front of the keyboard) are both either actual USB devices, a compound USB device, or emulated as USB devices. I'm leaning more as a compound device as a hub, with three ports (three?), one for keyboard, one for the pointing device, and an empty one, though no physical port is available.


Dell Inspiron 1720 with an Intel ICH8 motherboard (H2801HB).

The specs for this MB state that:
"When a USB keyboard is plugged into the system, and a standard keyboard is not, the system may not boot, and MS-DOS legacy software will not run, because the keyboard will not be identified. The ICH8 implements a series of trapping operations which will snoop accesses that go to the keyboard controller, and put the expected data from the USB keyboard into the keyboard controller."

This tells me that there is an actual 8042 type keyboard controller, or at least the system "emulates" one. However, I don't like the "trapping operating".

The specs go on to say:
"The scheme described below assumes that the keyboard controller (8042 or equivalent) is on the LPC bus."

And finally:
"This legacy operation is performed through SMM space."

This tells me that I need to look into what the SMM is doing each time I press a key.

Anyway, thanks for the comments, I am still continuing to look for answers.

Ben

P.S. I forgot to mention, the Specs also state:
"The logic also needs to block the accesses to the 8042. If there is an external 8042, then this is simply accomplished by not activating the 8042 CS."

If all access to the 8042 is actually being blocked, this would explain what is happening, since my code to clear bit 6 of the Command Register never makes it to the physical controller, hence translation is always being done.

Here is my conclusion, and I am not going to spend a whole lot more time on it.

I believe that the USB Legacy capabilities on this particular Machine/BIOS/hardware is broken.

After "hard-coding" all EHCI controllers (2) to give up BIOS control, only one would give it up. (See why below)
I "hard-coded" all UHCI controllers (companions) to use the default of 0x2000 in the Legacy register.

The ICH8 has a legacy register at PMBASE (Power Management Base), offset 0x30, called the "SMI Control and Enable Register". It has two bits to enable/disable the SMI so that a write or read from I/O 60h and 64h will (or will not) cause a SMI interrupt. I set both of these bits to zero, meaning disabled.

Therefore, I believe I have disabled all Legacy USB support, which should now not call any SMI interrupts and should be able to write directly to the 8042 controller (see note 1 below).

However, the keyboard scan code returned is still scan set 1, no matter the settings.

My guess is that DELL/Intel/BIOS manufacturer (or all three) decided to eliminate the 8042 completely and have the SMI handle all Legacy access without the ability to disable it, since disabling it will allow control to go to a non-existent 8042.

My conclusion, maybe we should all make our default scan set to set 1....Another must because someone cut a corner...

Just my opinion, conclusion, observation. I could be completely wet here and missing something, but I don't think so. I'm very seldomly wrong and even correct less often than that.

I hope that this thread will be beneficial to future readers if this ever happens to them. If someone does find out what is going on, I would love to know what I missed.

Thanks,
Ben

note 1: I don't believe there is a 8042 controller on this machine. I believe since both the internal/installed keyboard and pointing devices are both USB, there is no need for a 8042 and the SMI handles all 8042 access.

Hi,



I like to have a well defined "point of no return" where the OS takes control of all hardware from firmware (e.g. the point where you'd call the "exit boot services" function in UEFI). Before this point is reached boot code should only use firmware's functions (for things like disk IO, keyboard, video, etc) and should do everything possible not to upset the firmware; and after that point the boot code (and OS) should not use firmware's functions for anything.

In other words, before the "point of no return" you'd use BIOS or UEFI functions if you need keyboard interaction; then after the "point of no return" you'd disable USB legacy emulation (possibly as part of starting USB controller drivers) before you start a PS/2 controller driver.



That's not emulation - real USB drivers in the firmware are used to make the real USB storage device available via. "int 0x13"; regardless of whether "USB emulation of PS/2 devices" is enabled or disabled.



For example, you'd use the firmware's disk IO to load everything needed to get your drivers working from the boot device into RAM; then hit the "point of no return" and disable all the legacy stuff and start your drivers; then you'd use your keyboard driver to ask the user what the boot device was.

Of course for this case it'd be much better to either avoid the need to know which device you booted from or improve the boot device detection; so that it's very unlikely that the user (who may not exist) needs to use device/s (that also may not exist) to tell the OS how to do its job.

For example; after using whatever you can (including firmware - e.g. the Get Drive Parameters function) to limit the possibilities as much as possible and finding that there's still multiple possibilities; you could calculate a checksum of the first sectors of the disk and use that to help figure out which device it was later, and if the device is writable you could (using firmware's disk IO) store a some kind of magic value (e.g. a 128-bit "data+time+random") on the disk so that the OS can check for that magic value later.



This is exactly how the standard old "USB emulation for legacy PS/2 devices" works: any read or write to the PS/2 controller's IO ports trigger an SMI so that the firmware's SMM code (and firmware's USB driver/s) can emulate PS/2 devices attached to a PS/2 controller. Of course the emulation done by SMM is typically very minimal (and likely to be very dodgy); which is why almost everyone almost always says to disable it before touching PS/2 controller's IO ports.


Cheers,

Brendan

You need USB support to access USB media anyway, so why not postpone the prompt until after you're able to use a USB keyboard?

For that matter, why not use a "unique" signature on the disk to reduce the number of situations where the prompt would need to appear? Why not use INT 0x13 AH=0x48 to further reduce the number of situations where the prompt would be needed?


This means you're using USB legacy support, which is well known for being horrible and broken. In this case, the firmware is only capable of producing scan codes in set 1, no matter how you configure it.


The SMM code injects a fake IRQ1, and then when you read port 0x60 to acknowledge the IRQ and receive the scan code, the SMM code intercepts that access and returns to you a scan code translated from USB to set 1. If there is a PS/2 controller, it's not involved at all in this process.


If you're still receiving scan codes, SMM is still in charge of the USB keyboard, and your OS won't be able to access the keyboard without things breaking. You might have missed a required step to prevent SMM from accessing the keyboard. (The Linux source mentions that not all firmware is well-behaved when it comes to USB legacy handoff.)


It seems awfully early to be making a conclusion like that, especially since all you need to do is disable emulation and access the USB keyboard directly.


The FADT contains a flag that will tell you if a real PS/2 controller is present. (Pay attention to the version of the FADT: the lowest versions don't contain the flag, and may appear to indicate the lack of a PS/2 controller even though one is actually present.)

Hi guys,

Yes, I know how Legacy Support works via SMI. My point is, I disabled--so I think--all Legacy Keyboard Support both via the USB controller as well as the SMI Command Register, yet as you pointed out (Octocontrabass) I am still receiving scan codes. If I disabled the SMI, then why am I still receiving scan codes from a USB keyboard? (possibly answered below.) As you mentioned, it is probably dodgy at best.

As for "a point of no return", I also have a point of no return. However, this happens to be before I might need keyboard access. The "please select a bootable device" was just an example. I can easily move that to after USB keyboard detection.

As for "which drive/device did we boot from?", your suggestion (Brendan) is exactly what I do. However, my point was, as soon as protected mode is enabled, you no longer have access to INT 13h to read or write to the USB media you booted from. As far as your OS is concerned, there is no media there until *after* you enable USB and enumerate the device, and if you did this correctly, the newly enumerated device is nothing close to the emulated USB device the BIOS had. Oh, and this *is* called emulation. The BIOS is emulating the USB media as a floppy or hard disk. The application calling the INT 13h services has no idea that it isn't a floppy or hard drive.

Anyway, I appreciate your comments. I am just concerned with this particular machine that even though SMI was turned off, as far as I know--the SMI is still in control of the USB keyboard. Rather than saying "in control", I would note that even after your OS takes over the USB keyboard, the SMI can still send data to the (emulated) 8042 and your OS/USB driver won't know the difference or even care, unless you are monitoring the 8042 as well. My USB HID takes over the keyboard but the SMI still sends data to the (emulated, maybe non-existent) 8042. Reading from the 8042 returns a scan code because I read from it. However, if it returns a valid scan code, then the SMI is still monitoring the USB and (possibly) still has control of it.

Again, thanks for your comments. A simple change from using Scan Set 2 as my default to Scan Set 1 as my default fixes the boot issue I mentioned. My OS supports all three scan code sets, translated or not, so it really doesn't matter.

Thanks,
Ben

This machine does say it has one, per the FADT, however, the ACPI specs say:

"If set, indicates that the motherboard contains support for a port 60 and 64 based keyboard controller, usually implemented as an 8042 or equivalent micro-controller."

IMHO, this doesn't mean it will actually have a physical 8042. This just means that it contains *support* for it, which could be in the means of the SMI.

Brendan, I think you might have misunderstood what I meant with USB emulation of a disk drive. I didn't mean USB emulation, I meant the BIOS was emulating a disk drive via USB. Sorry about that.

Thanks,
Ben

Hi,



Unfortunately; assuming standard hardware auto-detection methods, I suspect it's not that simple and you're going to end up with "two" keyboards (one PS/2 and one USB), where things may get out of sync (e.g. one keyboard driver tells the keyboard to reset while another driver is in the middle of configuring the keyboard), and where (depending on how the OS supports things like multiple keyboards) every key the user presses might end up doubled (ttyyppiinngg lliikkee tthhiiss!!).



For the EHCI controller that refuses to give up BIOS control; is there anything else using the controller (e.g. normal USB ports)?

I'm thinking that that the OS is expected to refuse to touch the USB controller (because BIOS has control of it) and would therefore have to use the emulated/dodgy PS/2 controller (for keyboard and touchpad?); and that this would solve the "two keyboards" problem without causing problems with other USB devices (because there can't be any other USB devices).


Cheers,

Brendan

This is what I was starting to think too. However, I have never seen a controller refuse to give up BIOS control until now, nor have I read anything anywhere stating that you should not continue to use that controller if this happens (at least I can't remember reading anything like that). The EHCI specification doesn't mention this scenario, nor does it give an amount of time you should allow the BIOS to give up the control. I have waited up to 20mS and have not gained control. I can't imagine the BIOS needing more than 2 or 3, tops.

Anyway, with this in mind, the manufacturer could have created it so that the physical hardware was all USB, but the software side of it was all 8042 for backwards compatibility.

There are two EHCI controllers on this machine, one of them with four sockets (physical external ports). There are only four sockets on the whole machine so I am guessing this is more true than I thought. The second EHCI is probably keyboard/touchpad only. However, since each are low-speed devices, why a high-speed controller? (no answer expected, just thinking out loud).

If this is the case, then it is the BIOS/SMI that is not allowing me to change to Scan Code Set 2, nor turn off translation. (I even updated the BIOS to be sure).

Again, I appreciate the comments. It seems that I can work out a problem more easily if I write it somewhere, like these posts. It seems that just as I post it, then re-read it, something clicks and I figure it out.

Thanks guys,
Ben

Hi,



Is there any case where it makes sense for 2 separate and independent things to both assume they have control of something at the same time? Either the OS has control and the firmware doesn't, or the BIOS has control and the OS doesn't, or you have a hideous "split brain" disaster that's guaranteed to end badly.

If a USB controller refuses to let my OS take control from the BIOS, then I'd declare the device faulty (and probably also attempt to nuke it completely - e.g. by writing a zero to the "command register" field at offset 0x004 in the device's PCI configuration space in an attempt to "logically disconnect the device from the bus" - and then put the entire computer on a blacklist of unsupported computers if/when nuking the device causes other problems).


Cheers,

Brendan

Once your USB driver takes control from the firmware, you should stop receiving scan codes through the (emulated) PS/2 controller. It's possible your USB driver is missing a step the laptop's firmware expects. It might be helpful to boot Linux and see what its USB and PS/2 drivers have to say.

I suspect you can't disable the port 0x60/0x64 SMI since there's no physical PS/2 controller, so the firmware is still emulating non-keyboard-related functions (A20 control and reset).

I haven't spent much time on it since a few days ago, but I think the one EHCI is exclusively for the keyboard and touchpad, there is no physical 8042, and the SMI won't release it due to the fact that it is written and hardwired to be 8042 compatible. Just my opinion from what I have seen from my tests. It will take further testing and research to find out for sure, but I am not interested in doing so at the moment. Maybe at a later time.

Thank you for your comments. It helps to get another's perspective on these kinds of things.

Ben

Yikes, reading this thread and it looks pretty bad. I guess the firmware is trying to really pretend that there are PS/2 ports even when it's not true... and doing a pretty bad job at it. I would guess there's no obvious way to detect it even.

I suppose the only reasonable way to handle this is to try to disable legacy emulation (by enabling USB) and if PS/2 keeps working after that then assume it's PS/2 regardless of whether it's emulated or not. And to stick to whatever is the current set the keyboard is configured, if detectable.

Even then, you'd need to figure out which USB controller is being hogged by the firmware so you don't try to touch it... I'm going to guess this is why motherboard drivers exist -_-;

This kept bothering me. Why oh why is this happening???

So, I dug further and did a lot more tests. Come to find out, if you write to the PCI BAR register of a companion controller before you ask the BIOS to release control, the BIOS has a problem. At least this BIOS on this machine doesn't know what to do. The "Changed BAR" flag is set, but the EHCI's BAR is the same, so it gets confused.

If the BIOS releases the EHCI before I touch the companion controller's PCI config space, the EHCI's BIOS releases the control and works as expected. (Except for the Keyboard translation stuff that started this thread).

Anyway, just for your information.

And, yes, I shouldn't be touching a companion controller before the BIOS releases the EHCI :-) This is now fixed in my code...

Thanks,
Ben