OSDev.org

Hi.
A little introduction: my name is Sergio, from Barranquilla, Colombia. I'm 21 and about to start undergraduate study in mathematics. I'm currently working on a little operating system following the microkernel paradigm. My OS and programming understandings are from first-level books like the book on 4.4BSD, Lion's commentary on Unix V6, not from academia. I prefer using *BSD operating systems primarily because of their communities, BSD's rich history and that I do not share the concept of freedom imposed by the GPL.

A brief description of what have been done follows in the operating system I am attempting to develop:
1. BIOS jumps to custom MBR code.
2. MBR simply scans the partition table, and loads sector 0 from the partition selected. This loaded program is called first.
3. First is just 1 sector big, enough to read sector 1 from the partition and parse the ELF header of the next program. This one is called second. So, first loads up second.
4. Second prints some stuff using the BIOS, handles the a20-gate stuff, relocates IRQ's, sets up a temporary Interrupt Descriptor Table for handling interrupts when going 32-bits but before loading kernel. Then it loads the kernel, goes 32-bits and, initializes a small command-line interpreter.

Up to here, I have the following questions:
- I understand, from Intel SPG part 1 that local apic is enabled at boot. Is it still enabled after BIOS? or is the master 8259 connected directly to the INT/NMI pins? what about the ioapic? is it enabled? if so, is it acting as a 8259? is its outputs connected to LINTS? or directly to the processor interrupt pins INT/NMI? I really feel like needing a better background to this point to be able to understand how I might latter further configure an interrupt system.
- Does the APIC system work in real-mode?
- What happens to the APIC/8259 when going to protected-mode?

5. The terminal-handling facilities receives keystrokes until a new line. The 'start' command jumps to the kernel.
6. The kernel understands the simple format of a custom file-system. It loads the user-level servers, set up heaps for them, uses ACPIe820 for physical-memory mapping, creates paging structures, enables paging, and invoke each user-level server for the first time. The mechanism for interprocess communication is virtual-memory mapping.
7. The IO server probes devices, I think the old (unreliable?) way, that is, scanning all possible devices through CONFIG_ADDRESS/CONFIG_DATA IO space addresses.

Questions:
- Is this mechanism (probing buses) unnecesary/unreliable?
- According to the state of the APIC/8259 up to here, I mean, because I really ignore if the CPU is receiving interrupts directly from 8259 or through the local apic: if in legacy mode (8259 interrupts the CPU directly), can I still use the MP/ACPI table mechanism for devices? if receiving interrupts from local apic, are legacy devices connnected to ioapic? are they connected to 8259 and this, in turn, connected to ioapic?
- Probing devices the old way, how can I probe devices behind the PCI-ISA bridge?
- The result of device probing tells me, through the INTERRUPT LINE from PCI configuration space registers what IRQ all devices are issuing, but then I see that the PCI-ISA bridge, which is a multifunction device part of the SB600 chip from amd, issued IRQ0. In fact all functions from this device have IRQ0 at the INTERRUPT LINE. Is this valid?

Thanks for reading and I hope to find answers here.

The bios leaves you off in an environment that functions just like an old PC-AT, and it disables/changes the hardware settings to get there. That indeed means that the local apic is disabled and interrupts are generated from a virtual 8295 PIC.
Hardware can not see what happens inside the CPU execution unit. That means the interrupt wiring does not magically change between real and protected mode, and the processor will just get the same interrupts at the same time. One problem however is that the 16 bits of real mode are not enough to address the interrupt-related hardware and make the changes - you need at least 32-bit addresses for that. That does not mean you can go back to real mode and enjoy an APIC-based setup.


Hardware detection is generally required, and you need something that tells you what's in the box. However for most buses there is a starting point that can give you a full list: the PCI bus will give you most peripheral devices, ACPI will get you most chipset specifics, which means you only really need to probe one thing. You may assume that the architecture-defined devices (like the PIT and KBC) just exist without needing to actually probe them. The only problems come from having an ISA bus, which is the only time you'll need to try every known device to see if they happen to be there.

Interrupts should "appear" to come from a 8295 in legacy mode. There are several variations on how this is arranged, and the tables should tell you how exactly. It does mean you should be prepared for all such configurations.

Guess where they are, then try if they respond as expected.

The INTA you see listed on the PCI configuration is not necessarily wired to IRQ0 (actually, you're in trouble if it is since the PIT doesn't like sharing interrupts), nor is it necessarily used. Also, the ISA bridge does not define how interrupts from devices behind it are routed - you just have an extra set of wires called IRQ0..15 that are going from somewhere to somewhere.

Thanks for the response.
I now understand that when I do the irq vector reprogramming for the 8259 before switching modes because of intel's reserved vectors, the system is actually working in legacy mode and receiving interrupts directly from the 8259 master controller or from the ioapic acting like a 8259.
Because the project has various social implications, because the OS is really intended to stimulate systems programming at my local University (people there barely can do web programming), I wish not to have complicated mechanisms (although I have paging enabled and want to share virtual address space between kernel, user-level processes and user applications) that APIC would imply, neither I plan in the near future to mess with multiprocessor/multithreading environments. So I guess I'll continue using the legacy 8259 interrupt system and in fact shouldn't mess with irq remapping and just with the default irq sharing passed by acpi/bios.

If any other issued presents, I'll no doubt come and ask again.
Thanks a lot for your help.