OSDev.org

And now, when I want to configuere the APIC also with ACPI tables, how it's possible to determine the Interrupt Sources of the IO- and Local APIC like with IO Assignment Entries and Local Assignment Entries?

For Local Assignments I can only find an entry type in ACPI Tables for NMIs...What's with the other typs of interrupts possible at the Local Apic LINTs?

And for the IO Apic there is only one value, that indicates the global system Interrupts at these IO APIC. But how it's possible to determine which Device uses which global system Interrupt?
There are also "Interrupt Source Override Entries" but they are only definied for ISA devices. What's with PCI?


But in theses Assignment Entries, there is only a string for the bus and one for the Source Bus IRQ number of this bus. Isn't it?
Do I have to search at the data area to the corresponding bus, to determine which Source Bus IRQ is used by which device?

Cheers
Nooooooooooos

Hi,

First, I'm currently operating in "sleep deprived mode" - I'll check this post for mistakes when I wake up and edit it if necessary.



For ACPI's tables, you should find a local APIC interrupt assignment entry for NMI, but probably won't find one for ExtINT. AFAIK, ACPI assumes that if the OS and computer are both modern enough to support ACPI, then there's no need for both the PIC and I/O APIC to be used at the same time, and therefore there's no need for the PIC to send any interrupts once the OS starts using the I/O APIC (ie. "using I/O APIC" means no need for PIC, which means no need for ExtINT).



For ISA devices, ACPI assumes that devices are connected to the I/O APIC in the same way they're connected to the PIC (if a device is connected to PIC input #N then it's also connected to I/O APIC input #N). Interrupt Source Override Entries are only used to override this assumption (e.g. if the interrupt is level triggered, a different polarity, connected to a different I/O APIC input, etc, then it must have an Interrupt Source Override Entry).

For PCI devices the ACPI tables won't help. Instead this information is in AML (ACPI Machine Language), which is an interpretted byte code for an OOP language called ASL (ACPI Source Language). You can find this byte code in a table called the DSDT (Differentiated System Description Table). It's a *huge* pain in the neck.

I haven't attempted to write (or port) an AML interpretter, and haven't been able to find any other way to determine how PCI devices are connected to the I/O APIC (without using Intel's Multi-processor Specification tables, using manual probing techniques, or writing a "chipset driver" for each motherboard).



For PCI, the bus numbers used by Intel's Multiprocessor Specification are the actual bus numbers used by PCI itself, numbered from 0 to N. However, if MPS says "the IRQ comes from bus number 4" then you won't know if it's PCI bus number 4 or if there's only 3 PCI buses and the IRQ comes from the ISA bus (or an EISA bus, an MCA bus, etc). BTW you also need to find out what sort of bus it is before you can correctly decode the "Source Bus IRQ" which is encoded differently for PCI (see section "D.3 I/O Interrupt Assignment Entries For PCI Devices" if you're not sure about this different encoding).


Cheers,

Brendan

Now...Then I also could use ACPI table for general APIC support, so it's also possible to use the APIC without any SMP-support on the computer, and use SMP-Tables only for PCI support...If there aren't any SMP-Tables I could show a error message or search the Informations with ASL...

I detected that Bochs doesn't produce any Bus-Entrys for SMP-Tables....But I don't care, because I'm now going to configure my APICs with ACPI Tables....Does Bochs at least support these? And what's with ASL...?

Cheers
Nooooooooooos

Hi,



I'm not too sure what Bochs' BIOS does - I got annoyed with it several years ago (for a variety of reasons) and wrote my own replacement BIOS for Bochs. I've been using it since then.

AFAIK recent versions of Bochs dynamically create MPS tables and ACPI tables, and these tables should be correct (where "should be correct" is not the same as "is correct", and where the word "correct" may have different meanings to different people).



For an example (and because the online "CVS viewer" for Bochs is 3 years out of date) I've attached a copy of the latest ASL code used by Bochs/Qemu (which AFAIK originally came from Xen). This code is compiled by Intel's ASL/AML compiler to produce the AML "byte code" contained in the DSDT.

From my reading of it, it doesn't support the I/O APIC at all. The definitions for PCI bus/devices refer to PCI IRQ router connections (the PCI IRQ router is only used to connect PCI IRQs to the PIC chips), and does not refer to fixed "global IRQ" numbers that would be used if connections to the I/O APIC are being described. This is partly because they're using static ASL code - it isn't modified to reflect how you've configured Bochs, and therefore is mostly broken (unless you're lucky enough to have configurd Bochs to match it's ASL/AML).


Cheers,

Brendan

Thx...How can I prove with the ACPI tables, wheather I have to set the IMCR bit? With SMP tables I have the IMCRP bit in the Floating Pointer Structure...And is this the same as the PCAT_COMP bit in the MADT?

I don't think so, because PCAT-Compatiblity can also mean VirtualWire-Mode which even don't needs a setting of the IMCR bit...

EDIT: Do you think there are also existing multicore-systems, that don't produce any SMP-Tables, but could be configured with ACPI-tables?


Cheeers
Nooooooooooos

Hi,



AFAIK if the motherboard supports ACPI, then there is no IMCR.



The PCAT-Compatiblity flag only determines if the system also has PIC chips that need to be disabled, where "disabled" means setting the masks for each IRQ in the PIC chips (e.g. "mov al,0xFF; out PIC1+1,al; out PIC2+1,al"). Unless your OS supports booting from other firmware (e.g. EFI) then you can probably assume this bit is set, as the PC BIOS needs PIC chips.



I don't know of any systems that have APICs and/or support SMP that use the PC BIOS and have ACPI but don't have MPS tables. However, future PC BIOSs might not bother with MPS tables, which wouldn't completely break backward compatability (older "SMP capable" OSs that don't support ACPI would think it's a single-CPU computer without APICs and still work).

Also, EFI systems never have MPS tables (but do have ACPI). If you want to support 80x86 Apple hardware or if you want to make sure your OS won't need major changes if "white box PCs" shift to EFI, then it might be a good idea if the OS doesn't rely on MPS when ACPI is present.

Don't forget that one way of dealing with insanity (e.g. needing a large/complex AML interpretter just to figure out which IRQs devices use) is to hide the insanity behind some sort of abstration layer. This is the method I use - for me, there's a "motherboard driver", and the OS itself doesn't care where the motherboard driver gets it's information (ACPI/AML, MPS, hard-coded values, etc). This means I can ignore the ACPI mess for now (e.g. use MPS tables while I still can), and wait until Intel feel like writing a "generic ACPI motherboard driver" for my OS...


Cheers,

Brendan

Now when I have to reprogramm the IDs of IO/APICs (because they aren't unique) with only 4-Bit and when the first 16 IDs are occupied by LOCAL APICs, what I have to do? Leave the adress as before? But what's the sense of IO/APIC IDs? I don't need them at no time in my code...


Cheers
Nooooooooooos

Hi,



The short answer is, display an error message and refuse to boot!

If there isn't enough APIC IDs then no OS will work correctly, and people that design chipsets are usually smart enough to realise this. You (probably?) won't ever find a "normal" P6 system with more than 8 CPUs.

There are unusual P6 systems out there, but (AFAIK) they all use NUMA and the APICs use "cluster mode". In this case (for e.g.) you might have a 16 CPU computer with 4 NUMA domains and 4 CPUs per NUMA domain, where each CPU can only see other CPUs within the same NUMA domain and a special "APIC bridge" (so that within each NUMA domain only 5 APIC IDs are needed - one for each CPU and one for the APIC bridge).

IMHO these unusual systems aren't worth worrying about. They were extremely expensive and would be quite rare now (originally sold in low numbers at high prices). People that bought them paid the high price for a specific reason and installed special purpose software on them, and if any of them are still being used it's likely that the companies that own them would be unwilling to change OSs.

Eventually there will be a similar "not enough APIC IDs" problem with current CPUs. With 256 APIC IDs you can't have more than 255 CPUs, and "number of CPUs" tends to go in binary jumps (e.g. 4, 8, 16, 32, 64, 128, 256). This means 8-bit APIC IDs start looking inadequate when high-end servers start using 128 CPUs. This sounds like a lot, but IBM already sell off-the-shelf 80x86 based servers that support up to 32 CPUs (example). Because of this I'm expecting Intel to change to 12-bit (or larger) APIC IDs when they introduce CSI (or "Common System Interface" - Intel's answer to AMD's hyper-transport).



No software needs the I/O APIC IDs - it's the hardware that needs them...


Cheers,

Brendan

Now I have almost finished, but I'm thinking about the LocalApic VersionRegister...

When I want to enable a CPU I have to know, whether this CPU Apic is a 82489DX, because then I don't have to make a Startup IPI...
In the MPS-entry for Processors there is a LocalApic Verison Register, but not in the ACPI tables...Is there any standard for Versions of ACPI APICS?


Thx Nooooooooooos

Hi,



If you need the APIC version register, then you could get it from the local APIC itself.

However, the first version of ACPI wasn't released until around 1996 (IIRC) and Pentium II was released before then - if the computer has ACPI then it won't have an 82489DX local APIC...


Cheers,

Brendan

You are right...Now BIOS is producing wrong entries for IOAPICS...His first IOApic entry is one for an APIC with ID=2 (as Bochs installs the IOApic...) but then there are 10 more entries with IDs 3,4,5,...

Then all IOAPICs inclusive this with ID=2 have it's enable Bit in the entry clear...And the base adress for registers is strange: something like 0x3000000 (instead of 0xFEE0 0000 or something like this...)

Now...Does your BIOS support MPS and ACPI tables or should I use Qemu?


Thx Nooooooooooos

Hi,



Qemu uses the same BIOS as Bochs...

My BIOS has a BIOS configuration screen (like a real BIOS - "press DEL to enter setup") which allows you to choose which version of Intel's MPS you want (none, version 1.1 or version 1.4) and which version of ACPI to use (none, version 1.0, version 2.0 or version 3.0).

If you select ACPI version 2.0 it can generate the SRAT (System Resources Affinity Table), so that you can test how your OS behaves on NUMA systems, including allowing you to adjust how many CPUs per NUMA domain. If you select ACPI version 3.0 it can also generate the SLIT (System Locality Distance Information Table) with 4 different system topologies and 4 different NUMA ratios.

There's also a few special setup options intended for OS developers, like filling all RAM with 0xCC (so you can find out if your code relies on uninitialized data), leaving areas of the system memory map unaligned, allowing an ISA hole from 0x01000000 to 0x00FFFFFF to be enabled and (for NUMA systems) making the last domain have a CPU with no memory.

However, it is unfinished code.

It reached the point where it does everything I wanted it to do, so I started using it for OS development instead of completing it. Mostly it won't boot from hard drive or CD (you can only boot from floppy). It doesn't generate any DSDT (no AML code, as this would need to be generated dynamically to suit the hardware). Several fields in the FADT and FACS aren't correct (they're set to zero because Bochs lacked certain pieces of hardware when I wrote it).

Also, the I/O APIC interrupt assignment entries for PCI devices are "wrong". They match the hardware, but unfortunately the hardware is wrong - IIRC Bochs doesn't directly connect PCI IRQs to I/O APIC inputs 16 to 19 like they should be according to the I440FX chipset documentation. Instead Bochs sends them through the PCI IRQ router so they look like ISA interrupts rather than PCI interrupts. Because Bochs hardware is broken, my BIOS does the I/O APIC interrupt assignment entries for PCI devices in a similar way to Bochs BIOS.

Lastly, my BIOS is no longer being maintained and (apart from some minor changes) hasn't been for over a year. Basically it's enough for me to get my OS working, and when I get my OS working I'll write my own emulator (and assembler, compiler, etc)...


Cheers,

Brendan

Is your BIOS freeware and is there a possiblity to download it from anywhere?

I think first I don't use AML... My priority is to make my OS comfortable to develop on itself and so I don't have to use en Emulator...


Thx
Noooooooooos

Hi,



My BIOS is LGPL, but there isn't anywhere reliable to download it from. Gmail complains about binary email attachments (potential security problem) and it's too large to transfer via. the forums.

For now I've put my web server online, and will leave it online for a day or 2. Unfortunately this is on a server at my house with slow speed outgoing traffic (and faster incoming traffic), so as soon as the web search engines find out it's online I get huge amounts of lag (no free bandwidth for outgoing traffic, including my web browser's HTTP requests, online games, etc). This is why I leave the web server offline most of the time...

Anyway the link for the BIOS (464 KB "tar.gz", source and binaries) is http://bcos.hopto.org/bios2/latest.tar.gz.

Some notes....

There\'s actually 2 binaries - one that autodetects the chipset, and another one for "ISA only". For the normal version of the BIOS you'd need to change one line in your "bochsrc.txt" to something like:



For the "ISA only" version you'd want:



I'm also not sure which version of Bochs you're using, but you might need to modify Bochs a little and recompile it to avoid stupid error messages. If you're trying to emulate a multi-CPU computer and you get a "WARNING: HLT instruction with IF=0!" error message, then find the file "bochs/cpu/proc_ctrl.cc" and comment the warning out. Also, if it complains about HLT during BIOS code you'd need to comment that out too. For example (around line 95 in the file "bochs/cpu/proc_ctrl.cc") you may need to change it to something like:



Newer versions of Bochs don't have the "HALT instruction encountered in the BIOS ROM" hack, and might handle "HLT instruction with IF=0" correctly.

The "Press DEL to enter setup" is a hassle unless you've got the timing setup correctly in Bochs (e.g. the "ips=11000000" part) - it can be too quick or annoyingly slow.

Also, the BIOS stores it's setup in the CMOS. If you don't save and reload CMOS contents then it loses it's settings (including where to boot from and floppy drive setup). To fix this create an empty file (e.g. "cmos.img") that is either 64 bytes or 128 bytes long, and then add something like this to your "bochsrc.txt":



The first time you boot, the BIOS will find that the CMOS checksum is wrong and will restore some defaults. Then you'll need to enter setup and tell it that a floppy drive is connected and to boot from floppy. If Bochs is setup to save CMOS and reload it then you only need to do this once (otherwise you'll need to use the BIOS setup every time you boot).

Lastly, if you're testing NUMA you might get some strange results (e.g. where a multi-core chip is split across different NUMA domains). This is caused by bugs in the CPUID instruction emulation code in Bochs. I wrote my own version of the CPUID emulation code to fix this (and make other improvements).

I don't think I've forgotten anything - let me know if (when?) you have trouble getting it to work...


Cheers,

Brendan

Thx...now in general it works...But there is a problem, when I want to use the MPS tables in Version 1.4.
Sometimes (many times it works well) when I start bochs, it shows:Though that is only a warning, he don't doesn't anymore run further.
Because I'm working under windows it's a little bit difficult to compile Bochs myself (I don't have any experience in compile something even with Linux). I've already attempted to compile the Bochs-Debugger for SMP-support, because that was nowhere to download, but with MinGW and Cygwin it doesen't work...
Now, as you said, that newer Bochs Versions don't make problems with HLT, I use the latest Version of Bochs...

Is this fault really because of HLT instructions and the dealing of Bochs with them? I don't think so because there is also the instructions-fault, which I can not comment out.
And this is only a warning and should work even if Bochs doesn't like HLT with IF=0...

Cheers
Nooooooooooooos