IBM 5155 console keyboard

[Mellvik]

Not seen on other hardware, but on the IBM 5155, the "XT Portable", the keyboard doesn't work with TLVC.

Works fine with DOS, serial io is not affected. Also works fine with COMPAQ Portable Plus, also an XT class machine. Since the 5155 has a standard XT mainboard, this problem presumably hits all IBM PC and XT models.

[vkoskiv]

Confirmed on my 5150 (+5160 expansion unit), 83-key keyboard doesn't seem to work on the login prompt.

[Mellvik]

Thanks for testing, @vkoskiv .

The issue has been on the back burner for a while. I'll pull it to the front.

[Mellvik]

It turns out this problem appears only when the root volume is FD. Booting from HD, or even from FD with root= in bootopts, and we're good. So it seems the sequence of initialization is key. When starting from HD, using the FD doesn't affect the keyboard, it still works. In short it seems like if the FD is accessed (driver opened) before the console (keyboard really) is completely initialized, the kbd locks up. Maybe an interrupt mask.

@ghaerr, would you possibly have an idea about where to look for this one?

[EDIT:] whether using direct or BIOS console driver doesn't make any difference. Adding or removing the 'scancode keyboard driver' doesn't do anything. Also, there is no difference when using the BIOS FD driver instead of the directfd driver.]

[ghaerr]

In short it seems like if the FD is accessed (driver opened) before the console (keyboard really) is completely initialized, the kbd locks up.

If setting the root volume in /bootopts causes the problem to go away, then I would disagree with your conclusion above, as changing the root volume in /bootopts doesn't reorder any console initialization.

What does differ between actual BIOS boot to a drive number versus /bootopts etc options is that on BIOS boot, register DL contains the BIOS drive number to boot from. The boot loader then uses this information to boot from the specified device. But I don't think that sounds like the issue.

Other possible issues are that the A20 line is turned on/off/tested at boot when XMS is enabled - and A20 fiddling uses the keyboard controller. You can look at this code in elks/arch/i86/lib/unreal.S, functions enable_a20_gate, etc. That file has a couple of options to enable/disable A20, and by default uses an INT 15h function, which possibly isn't implemented on your system, or something strange? The top of the file documents the various options, if this is even the issue.

There may be something funky with the actual communications to the keyboard controller chip, but I don't remember offhand which bits are masked and rerouted, etc. It might be worth looking at the 8042 in the IBM XT documentation, so we can have a more technical discussion.

Of course, turn scan code keyboard off (which should be automatic with BIOS console, but not sure). With the scan code keyboard disabled, IIRC the kernel polls the keyboard using a BIOS INT16h interrupt to check whether there's a character received - this is entirely different than the IRQ 1 interrupt occurring with the scan code driver.

[Mellvik]

In short it seems like if the FD is accessed (driver opened) before the console (keyboard really) is completely initialized, the kbd locks up.

If setting the root volume in /bootopts causes the problem to go away, then I would disagree with your conclusion above, as changing the root volume in /bootopts doesn't reorder any console initialization.

No, it does not. It's using HD (as opposed to floppy) that cause the problem to go away. The /bootopts root= example was there to demonstrate that the boot device has nothing to do with it, only the root device.

There may be something funky with the actual communications to the keyboard controller chip, but I don't remember offhand which bits are masked and rerouted, etc. It might be worth looking at the 8042 in the IBM XT documentation, so we can have a more technical discussion.

Yes, it looks like that's the way we're heading. It's interesting though that the root device determines whether it works or not, so it does look like the sequence of things (initialization) is part of it.

Of course, turn scan code keyboard off (which should be automatic with BIOS console, but not sure). With the scan code keyboard disabled, IIRC the kernel polls the keyboard using a BIOS INT16h interrupt to check whether there's a character received - this is entirely different than the IRQ 1 interrupt occurring with the scan code driver.

I was looking onto this last night, only to find that kbd driver selection, with or without the scancode 'driver', don't change anything. Seems I need a deeper dive into this. My other XT - the compaq portable plus - called in sick (PS problem), but I seem to remember it did not show the problem. Neither does the V20 system.