Brendan wrote:
Only very old systems have the IMCR - newer systems don't, and all systems that support ACPI won't. The "PCAT_COMPAT" flag in the MADT only says that PIC chips are present, and doesn't mean that there's also an IMCR.
ok thanks, IMCR was mentioned only in MP spec and I'm not parsing MP structures...
Brendan wrote:
The next step would be parsing the MADT properly - using the "Interrupt Source Override" structures to determine how legacy ISA IRQs are connected to IO APIC inputs. Once you know this you can setup the IO APIC to recognise/handle the legacy ISA IRQs (including the PS/2 controller).
in MADT there was only one "Interrupt Source Override" with Source 00h and Global System Interrupt 02h
it looks like exactly from ACPI manual
Quote:
if your machine has the ISA Programmable Interrupt Timer (PIT) connected to ISA IRQ 0,
but in APIC mode, it is connected to I/O APIC interrupt input 2, then you would need an Interrupt Source
Override where the source entry is ‘0’ and the Global System Interrupt is '2'
I'm not even sure if I'll need PIT, because I can use APIC timer...
also as I said I don't know how to set up IO APIC, where should I look?
Brendan wrote:
You should probably also learn how the APICs handle interrupt priorities and decide what should use which interrupt vectors; and setup the local APIC properly - e.g. setup a "spurious interrupt", set the TPR, LDR, etc.
I've read chapter 10 of Intel manual 3A, but I still don't really understand how it all works together, I think I need more information on how to do programming... maybe I don't know how to read it
or there isn't enough information for me
Brendan wrote:
It's far too easy to make design flaws that make it hard to add support for multi-CPU later (without rewriting lots of code). Things like locking and reentrancy (and scalability) need to be considered during the design, and something designed for single-CPU is rarely usable. I wouldn't start doing anything with IRQs (or IO APICs) until after you've proven that the local APICs are configured correctly by sending IPIs between different CPUs.
Also, I wouldn't bother with any device drivers until boot/initialisation code, CPU feature detection, physical memory management, virtual memory management (including the "multi-CPU TLB shootdown" stuff that requires IPIs), scheduling (including using the local APIC timer, and the ability to start and terminate processes if it's a micro-kernel) and IPC are all "working". Then I'd start doing some sort of "device manager", which would be responsible for deciding (and tracking) which devices use which resources (including which IRQs and which interrupt vector/s).
I understand that, but currently I don't want to work with it, I'll start implementing it after keyboard and probably hdd. it's pretty possible that some parts will need to rewrite but I'm not worried about it and every big change requires some code rewriting