OSDev.org

Hi all,
I hope youre all well. I feel slightly ashamed to be asking this as a first post but here goes.

Im writing a keyboard initialisation routine and driver for a Long mode OS that ive started developing that seems to be going nowhere and its driving me up the wall.
My biggest issue is that the code works on Bochs but when I try it on two fairly modern computers, it comes to no avail. I assumed that it is the USB emulation layer causing me grief, so I disabled SMIs in the LEGSUP registers for UHCI, EHCI and xHCI controllers (the routines detect, run through the OS handoff routine for the latter two, set the registers and soft reset the controllers; or so I think), and nothing. I still get nothing. The driver works in Bochs perfectly, even without this USB kerfuffle; every time a key is pressed, IRQ 1 is fired and the scan code is added to the buffer. Currently, im running an infinite loop of software interrupts (akin to just doing a loop of "xor ax, ax, int 16h, mov ah, 0Eh, int 10h"), which right now prints the scan codes to screen at the end of the init routine to check the hardware has been initialised properly. From the testing ive done, ive noticed is that IRQ1 is not being fired on neither of the real computers. More frustratingly, on one of the real computers, ive actually got a PS/2 keyboard connected but still nothing and im starting to lose my mind.
Does anyone have any idea what could be going on?

My general initialisation routine is as follows:
1) Interrupt disabling and PIC masking
2) Basic PCI enumeration and USB HC acquirement and deactivation (ish, im still not sure)
3) PIC remapping (I really dont want to use the APIC, just for simplicities sake, at least for now)
4) IDT writing and interrupt enabling with PIC line unmasking once a particular devices initialisation routine has been run through (ie, once I finish the keyboard init routine, I unmask line 1 of PIC1).

Ive done this sort of keyboard initialisation many times before on simpler hardware (pre-USB computers that are 15 years older than me, go figure ) so i cannot for the life of me figure out what is going on!
Also, im writing this all in assembly (I know, it makes life a lot harder but Im just an assembly geek), so sorry if things seem like a bit of a mess. It was all neat and nice to read until this starting destroying my nerves

Anyway, thanks in advance, and nice to join you all!

ylli122 wrote:I feel slightly ashamed to be asking this as a first post but here goes.

Never be ashamed to ask questions. It's how we learn.

ylli122 wrote:From the testing ive done, ive noticed is that IRQ1 is not being fired on neither of the real computers.

Let's work through this analytically: Your keyboard is sending scan codes, and you can read them if you poll. Also, your IDT is set up and your PIC is unmasked, right? So... is the interrupt just not being generated perhaps? What does bit 0 of the PS/2 configuration byte say? It should be 1.

ylli122 wrote:More frustratingly, on one of the real computers, ive actually got a PS/2 keyboard connected but still nothing and im starting to lose my mind.

Wait... so what's the other keyboard? If you disable USB legacy support and then wonder why you are not able to read a USB keyboard from the PS/2 chip, you should probably take a step back and look at your code from a higher level.

ylli122 wrote:Also, im writing this all in assembly (I know, it makes life a lot harder but Im just an assembly geek), so sorry if things seem like a bit of a mess.

In my experience, assembly is too "zoomed-in". Some things you have to do in it, yes, but for larger structures, I at least always get lost in a sea of instructions and it is hard to figure out how things connect any more. But you do you. I would still highly suggest writing in C.

ylli122 wrote:I feel slightly ashamed to be asking this as a first post but here goes.

I totally agree with 'nullplan'. Never be ashamed. We all started somewhere, and we all still don't know it all.

ylli122 wrote:Im writing a keyboard initialization routine and driver for a Long mode OS that I've started developing that seems to be going nowhere and its driving me up the wall.
My biggest issue is that the code works on Bochs but when I try it on two fairly modern computers, it comes to no avail.

Do you assign a standard keyboard in Bochs, or do you actually assign a USB keyboard via the UHCI: directive?
Bochs will always include a Legacy keyboard, no matter what you do with the USB emulation. Therefore, if you are using the (AT) Keyboard Controller for keyboard access, Bochs will always work.

ylli122 wrote:I assumed that it is the USB emulation layer causing me grief, so I disabled SMIs in the LEGSUP registers for UHCI, EHCI and xHCI controllers (the routines detect, run through the OS handoff routine for the latter two, set the registers and soft reset the controllers; or so I think), and nothing.

Depending on the controller, and the reset, the reset could be re-activating the emulation defeating the purpose of turning of Legacy support before the reset.

Also, as 'nullplan' asked, what is the keyboard type you are using? You don't mention if it is a AT style keyboard (PS2) or a USB keyboard. On a more modern machine, there isn't a PS2 port so it has to be a USB keyboard, yes?

Second, the USB Keyboard emulation is meant for DOS and other non-USB platforms. Period. Since any operating system that is 64-bit Long mode aware should have USB support, it is not guaranteed that the emulation even needs to function after moving to Long Mode. The mere fact of moving to Long Mode may turn off all System Management functions for the USB Legacy support.

Legacy support is only guaranteed to work while in real mode, maybe even unreal mode. It is (unconfirmed) that once a machine is in 32-bit PMode or 64-bit Long Mode, there is no need for USB Legacy Keyboard support. It is widely assumed that any operating system capable of 32-bit PMode or 64-bit Long mode can handle at least the UHCI. Also, between the time the system moves from real mode (legacy firmware assumed) to 64-bit Long mode and loads a USB driver, which is just a few seconds, is there a need for the keyboard?

Anyway, don't keep banging your head against the wall. It is probably the mere fact that the modern machines don't support Legacy Keyboard once you move to Long Mode. However, this is unconfirmed. I have yet to find a document that states this, though this is my opinion of what is happening.

And I agree, switch to C/C++. You will thank yourself later. If you do not, you will hate yourself later :-)

Ben
- http://www.fysnet.net/the_universal_serial_bus.htm

Hey all,
Well, it sure seems that I jumped the gun by asking the question!
It turns out my initialisation code was sure enough absolutely fine, save the fact that I wasnt waiting long enough between sending/recieving data to/from the keyboard IO ports! My keyboard routine now works perfectly fine on both machines.
I feel rather foolish, especially since I was essentially banging my head against the wall for two weeks over this and asked like 2 days before solving the issue. I guess it be like that sometimes.
Ill try and answer all your points, but thank you for answering so quickly, I was quite chuffed to see that I got responses so quickly!

Firstly, the two real machines, one is a custom built PC from about 2012, it has a single physical PS/2 port, and ive got a very late Model M and a Bluetooth USB mouse and keyboard (although the keyboard is deactivated right now), connected to it. The second computer is a Dell inspiron 7373 laptop. The former has EHCI and xHCI whereas the latter has only xHCI. To be very honest, im not sure if ive taken control of the controllers properly or not, however, since the PS/2 keyboard is working, I figure, at least for now, yes and dont mess with it too much I havent tested the USB keyboard just yet.
I defintely aim to fully implement USB support later especially since, well, its 2020.

Im using Bochs with the AT controller yeah so it makes sense as to why the code worked, but it was really confusing me as to why. I guess it didnt immediately occur to me that timing issues are a difficult thing to emulate properly.

I did however figure it was a timing issue after booting into DOS (yes I have a DOS partition on my HDD) and trying to run a similar intialisation routine (including the USB OS handoff routines) and debugging it with an Enhanced DEBUG clone. Stepping through the code, it became apparent to me that I wasnt waiting long enough (now whether it was me using DOS or just a eureka moment that made me realise this, I cannot be sure). Either way, thats sorted now.

With regards to being ashamed, well, I've been doing systems coding in my spare time for over 5 years (though never for long mode), and ive definitely written similar code before so I felt a bit like, whats wrong with me. Furthermore, it being a first post, it felt just embarrasing! But thank you both for your words of encouragement!

Finally, I know I know. I love C and I probably will write some of my higher level subroutines in C, but ive just always preferred the control I have with Assembly. Its a silly choice and at times, i've already hated myself but theres just something about the damn language that makes me want to write in it.

Either way, thank you both for your help (and to Ben thank you once again, for directing me to joining this forum!), and I look forwards to interacting with this forum more in the future!