Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Isaac wrote:Do I have to write code for IRQ2 (cascade for slave PIC)?
I don't think that you need to handle this interrupt, because the master PIC will convert it to the correct interrupt for you, but I could be wrong.
The wiki article on Interrupts states that IRQ 2 and 9 are never raised.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Isaac wrote:Do I have to write code for IRQ2 (cascade for slave PIC)?
I don't think that you need to handle this interrupt, because the master PIC will convert it to the correct interrupt for you, but I could be wrong.
The wiki article on Interrupts states that IRQ 2 and 9 are never raised.
IRQ2 can never happen (due to "cascade").
The wiki article is wrong about IRQ 9 - it's no different to any other IRQ line, and may be used by ISA devices or PCI devices (especially for older systems). For newer systems IRQ 9 tends to be used by ACPI (for its "system controller interrupt" or SCI), but nothing prevents a chipset from using a different IRQ instead.
Note that for ACPI there's basically 2 modes. Either the OS has taken control of ACPI (and the chipset's "system controller" sends SCI to the OS, and the OS handles the SCI by interpreting ACPI's AML), or the OS has not taken control of ACPI. If the OS hasn't taken control of ACPI yet, then the chipset's "system controller" doesn't send the SCI - instead, it sends an SMI and the firmware's SMM code handles the SMI.
This means that if ACPI happens to be using IRQ 9 (which isn't guaranteed), and if the OS hasn't take control of ACPI (like it probably should one day), then IRQ 9 wouldn't occur.
Note: I've edited the wiki page now...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
; send ICW 2 to primary PIC
mov al, 0x20 ; Primary PIC handled IRQ 0..7. IRQ 0 is now mapped to interrupt number 0x20
out 0x21, al
; send ICW 2 to secondary controller
mov al, 0x28 ; Secondary PIC handles IRQ's 8..15. IRQ 8 is now mapped to use interrupt 0x28
out 0xA1, al
From this code it looks like the primary PIC uses 8 interrupt entries, which means that IRQ 2 uses an interrupt entry. How can that be?
; send ICW 2 to primary PIC
mov al, 0x20 ; Primary PIC handled IRQ 0..7. IRQ 0 is now mapped to interrupt number 0x20
out 0x21, al
; send ICW 2 to secondary controller
mov al, 0x28 ; Secondary PIC handles IRQ's 8..15. IRQ 8 is now mapped to use interrupt 0x28
out 0xA1, al
From this code it looks like the primary PIC uses 8 interrupt entries, which means that IRQ 2 uses an interrupt entry. How can that be?
The code above simply tells the Master PIC and Slave PIC which interrupts to use. If you specify interrupt 10h, that particular PIC will use interrupt 10h through 17h.
It's just so happens that, due to the way that the two PICs communicate with each other, that you will never see an interrupt from IRQ2, but it still technically gets assigned an interrupt, just like any other IRQ. You can safely ignore this interrupt if it ever happens. Which it won't...
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott