OSDev.org

Hi, I'm new here and I'm also a newbie hobbyist OS developer.

I'm stuck at the IDT setup, the keyboard IRQ is not triggered when i press some keyboard button, I tried to fix it for a couple of days, had to understand a bit more about the PIC and why we need to remap the PIC IRQ lines to another offset in the IDT.

The weird thing is: the timer driver gets triggered (I don't know if it's being triggered once or more times, I did not manage to test it), but the keyboard driver routine is not being triggered (when I press some button). Both routines were loaded into an array of interrupt_handlers and the interruptions are being routed by a common irq_handler function, link to the code: https://github.com/ifest1/osdev/blob/main/cpu/idt.c

This common irq_handler is being called by the ISR routines in ASM inside a isr_common_stub which enables us to use a common irq_handler triggered by every interrupt. The ISR routines are created using three ASM macros, one for ISR with no error code pushed onto the stack, one for ISR's that the CPU pushes the error code onto the stack and the last one is for the devices IRQ's lines, 32 up to 47.
This is done here: https://github.com/ifest1/osdev/blob/ma ... errupt.asm

Back to the idt.c file, function idt_init the flow is:
- set_idt_gate for each ISR routine imported from interrupt.asm
- initialize the two PIC's master and slave, set cascade on master IRQ 2 and pass the identity to the second PIC, code: https://github.com/ifest1/osdev/blob/main/cpu/pic.c#L5
- set the idt pointer
- pass the idt pointer to the CPU
- init IRQ lines (masking the PIC's bits in the data port of each PIC)
- enable interrupts (asm sti)

Does anybody knows how can I debug this?

The most useful way to debug is to use a debugger (e.g. gdb) in conjunction with a virtual machine (e.g. emu). This will let you single-step through code, set breakpoints and examine variables and any other RAM. The qemu monitor is also a useful source of information.

Common causes of interrupts not functioning are improper masking in the PIC and failure to acknowledge the interrupt. I do wonder if the lineis what you intended as it make the coderedundant.

Do you flush the keyboard controller's output buffer? You'll only receive IRQ1 when the keyboard controller's output buffer is filled. If the output buffer is already full when you initialize the interrupt controllers and you never empty it, you'll never receive IRQ1.

Hey I found the issue... I forgot to implement the EOI PIC signaling after get the interruption handler fired. I also fixed the redundant conditionals, thank you folks.