Added 8259 PIC support #5

Merged
belliash merged 12 commits from :master into master 2023-11-29 20:07:17 +01:00
First-time contributor

This PR adds multiple routines to use the legacy 8259 PIC.

Purpose

In order to enable the APIC, the PIC must be properly disabled with masked IRQs.
This is accomplished by calling HlInitializePic(), which initializes the PIC and masks off every IRQ, and afterwards calling HlDisablePic(), which disables the PIC fully.
Incase APIC is not present on the host system (CPUID returns with APIC bit set to 0), it is possible to use the 8259 PIC instead, by not calling HlDisablePic().

Proposed changes

  • Added HlInitializePic(VOID)
  • Added HlSetMaskIrqPic(UINT Irq)
  • Added HlClearMaskIrqPic(UINT Irq)
  • Added HlDisablePic(VOID)
  • Added HlWritePic(UCHAR Register, UCHAR Value)
  • Added HlIoPortWait(VOID)
  • 8259 PIC is initialized and disabled at boot.
This PR adds multiple routines to use the legacy 8259 PIC. ## Purpose In order to enable the APIC, the PIC must be properly disabled with masked IRQs. This is accomplished by calling `HlInitializePic()`, which initializes the PIC and masks off every IRQ, and afterwards calling `HlDisablePic()`, which disables the PIC fully. Incase APIC is not present on the host system (CPUID returns with APIC bit set to 0), it is possible to use the 8259 PIC instead, by **not** calling `HlDisablePic()`. ## Proposed changes - Added `HlInitializePic(VOID)` - Added `HlSetMaskIrqPic(UINT Irq)` - Added `HlClearMaskIrqPic(UINT Irq)` - Added `HlDisablePic(VOID)` - Added `HlWritePic(UCHAR Register, UCHAR Value)` - Added `HlIoPortWait(VOID)` - 8259 PIC is initialized and disabled at boot.
Ghost added 1 commit 2023-11-26 10:40:24 +01:00
Ghost added 1 commit 2023-11-26 13:11:27 +01:00
belliash requested changes 2023-11-26 15:39:31 +01:00
@ -90,6 +90,25 @@
#define COMPORT_REG_MSR 0x06 /* Modem Status Register */
#define COMPORT_REG_SR 0x07 /* Scratch Register */
/* 8259 PIC ports */
Owner

Does any other platform than x86 and x86_64 support 8259 PIC? If not, this should be architecture specific.

Does any other platform than x86 and x86_64 support 8259 PIC? If not, this should be architecture specific.
belliash marked this conversation as resolved
@ -93,0 +94,4 @@
#define PIC_MASTER_COMMAND 0xA0
#define PIC_MASTER_DATA 0xA1
#define PIC_SLAVE_COMMAND 0x20
#define PIC_SLAVE_DATA 0x21
Owner

I think Master and Slave (PIC1 and PIC2) I/O port addresses are swapped.

I think Master and Slave (PIC1 and PIC2) I/O port addresses are swapped.
belliash marked this conversation as resolved
@ -146,0 +155,4 @@
*/
XTCDECL
VOID
HlIoPortWait(VOID)
Owner

Do you think this function might be useful anywhere else, or could we just call HlIoPortOutByte(0x80, 0x00); directly as currently it is used only in HlWritePic()?

Do you think this function might be useful anywhere else, or could we just call ```HlIoPortOutByte(0x80, 0x00);``` directly as currently it is used only in ```HlWritePic()```?
belliash marked this conversation as resolved
@ -11,0 +26,4 @@
/* Master PIC Vector offset */
HlWritePic(PIC_MASTER_DATA, 0x20);
/* Slave PIC Vector offset */
Owner

What do you think about putting an empty line before each comment? In my opinion it is easy to read, if comment says what does below block of code do and each block ends up with an empty line.

What do you think about putting an empty line before each comment? In my opinion it is easy to read, if comment says what does below block of code do and each block ends up with an empty line.
belliash marked this conversation as resolved
@ -11,0 +40,4 @@
HlWritePic(PIC_SLAVE_DATA, PIC_ICW4_8086);
/* Mask all IRQs by default */
for (UCHAR Irq = 0; Irq < 16; Irq++)
Owner

Do we need to mask all IRQs if we finally disable PIC and use APIC? Do we want to support PIC as a failover?

Do we need to mask all IRQs if we finally disable PIC and use APIC? Do we want to support PIC as a failover?
Author
First-time contributor

I have not found any mention of IRQs being explicitly masked or unmasked in any documents, so I masked them so the kernel doesn't get interrupted when the IRQ isn't ready to be served yet (in the case that PIC is indeed used as a failsafe).

I have not found any mention of IRQs being explicitly masked or unmasked in any documents, so I masked them so the kernel doesn't get interrupted when the IRQ isn't ready to be served yet (in the case that PIC is indeed used as a failsafe).
belliash marked this conversation as resolved
belliash approved these changes 2023-11-29 19:36:35 +01:00
Ghost force-pushed master from 3c5fb740b0 to c97f1156b7 2023-11-29 20:05:19 +01:00 Compare
belliash merged commit c8a54e602b into master 2023-11-29 20:07:17 +01:00
Sign in to join this conversation.
No description provided.