Hi,
hmachine wrote:For question 1 (memory related):
-- In PCI spec. and some other related books they explain how to find size of mem. from base address and not where is mapped that base address in mem.
The PCI spec contains information that you can use to find out which PCI devices are using memory mapped I/O, and the address and size of these memory mapped I/O areas (in the physical address space). This has nothing to do with main RAM.
Note: See comments below about the PCI host bridge.
hmachine wrote: - Memory map can be viewed using bios int 0x15 (full exp. on wiki.osdev.org).
-According to M$, mem. map can be found trought ACPI (I'm not try that).
The ACPI specification says "Use Int 0x15, eax = 0xE820". This is the only sane/correct way of finding details about RAM that an OS can use, system areas (both ROM and RAM) that the OS can't use, areas reserved for certain things (ACPI areas), etc; and from this information you can figure out which areas are safe to use for things like memory mapped PCI devices.
hmachine wrote: -MMU is located in north bridge and can be programmed, bat I don't found how.
For "FSB" systems you'd need to examine registers in the chipset's memory controller (which is implemented in the chipset's PCI host controller); and for systems with the memory controller built into each physical CPU (systems with hyper-transport or quickpath) you'd need to examine MSRs and/or the registers implemented in the CPU's inbuilt PCI host controller. In all cases the information you get will be almost useless (it won't tell you which areas are reserved by firmware and which areas are free for the OS to use), and it'd involve writing hundreds of pieces of code (to support hundreds of different chipsets), where you can't get information for a lot of chipsets anyway (I think Intel is the only manufacturer of chipsets that provides documentation). For chipsets made by companies like VIA, NVidia, SiS, etc you're mostly screwed; but maybe you might be able to get limited documentation after lots of begging, signing non-disclosure agreements, etc (however I'd expect that even if these companies bother to talk to you at all, they'll start ignoring you as soon as you tell them why you're asking for the documentation).
A similar alternative might be to examine the SPP data from the RAM chips themselves (it's just as complex, just as chipset specific, and equally useless). Another option (at least for P6 and later CPUs) might be to examine how the firmware configured the MTRRs and make assumptions based on which areas are "write back" (but the assumption might be wrong, and the information you get will still be mostly useless).
Another option is to use the "System Management BIOS" functions, but these are designed for letting system administrators know details needed for hardware upgrades without going to the computer and opening the case (and not for OS's to rely on), and therefore they're mostly useless (unless you're writing a utility to let system administrators find out details needed for hardware upgrades).
hmachine wrote:2 (IRQ related):
--There is 3 (common)type of PICs (I/O APIC, (L)APIC, PIC (8259) ).
-I/O apic is used on multiprocessor boards.
I/O APICs (and local APICs) were originally intended for multi-processor, but either the local APIC alone, or both local APIC and I/O APIC, may be present on single-CPU systems. Almost all (80x86 ) single-CPU desktop/server systems since (roughly) the year 2000 have both local APIC and I/O APIC (although smaller devices intended for mobile use or thin clients might be different).
hmachine wrote: - (L)APIC or just APIC (L-mean 'local') is internal part of pentium processor family (starting from Pro version).
Yes, but it's possible for the BIOS to permanently disable the local APIC (so that it's impossible to enable it without rebooting, where the BIOS will just disable it again). As far as an OS is concerned there's no practical difference between "no local APIC" and "permanently disabled local APIC". Systems that use older (Pentium and P6) CPUs actually do have local APICs (that are almost always permanently disabled by the BIOS, except for multi-processor boards, and a few single-CPU server boards where you might find a "enable/disable local APIC" BIOS option).
hmachine wrote: - PIC(8259) is old well documented controller.
Yes - it dates back to the very first IBM PC (which had one PIC chip), and all "PC compatible" computers since then have had one PIC chip (e.g. ancient 8086 computers) or two PIC chips (all 80286 and later systems, and maybe even older systems - I don't remember the exact time when the second PIC was added).
hmachine wrote: I know that PCI share interrupt and that interrupts are mapped in standard 0-15 IRQ pins. Every PCI device have status registar and flags that says which functon (device can have multiple function i.e. flash mem. dev. +bluetooth dev in same package) asserts interrupt.
What I don't know is how to map (where to say: int 0x18-->IRQ5) this ints. I readed some APIC docs and don't find anything concrete(precisely) about this.
How the IRQ lines on each card is connected to the PIC depends a lot on the motherboard itself (and even different motherboards that use the exact same chipset can do this differently). To avoid confusion the BIOS stores the "PIC interrupt number" in the PCI configuration space for the device/s (in the 8-bit "Interrupt Line" field in the device's PCI configuration space, at offset 0x3C). This scheme works most of the time, but doesn't work in some case (hot plug PCI). For e.g. imagine a laptop and docking station, where the docking station is implemented as a hot-plug "PCI to PCI bridge" with lots of devices on the other side of the bridge. In this case it's impossible for the BIOS to configure PCI devices that don't exist during boot, so the BIOS can't set the "Interrupt Line" field in the device's PCI configuration space correctly during boot. To get around this (and for other reasons, like allowing the OS to change interrupt assignments); there's a "PCI IRQ Routing Table Specification" that the OS can use.
These "PIC interrupt numbers" are only for the PIC, and are useless once the OS starts using the I/O APIC instead of the PIC. For I/O APICs you need to parse MP specification tables and/or use ACPI to determine which device/s are connected to which I/O APIC inputs. Of course there's the same problem here - the MP specification tables and/or ACPI tables can't tell you about hot-plug PCI devices that didn't exist during boot. For MP specification tables you're out of luck. For ACPI there's a complex mess to handle parts of it (including notifying the OS when a device is plugged in, and helping configure the device); but I haven't got far enough with ACPI to give complete details.
hmachine wrote:3 ((wait==sleep, timer==(process,thread))==slice_of_time:
-- Problem: Seting timer for task switching on 10ms (100hz), some program ask for timer and interval of 6ms or 16ms ... i.e. default_interval mod requested_interval != 0 .
-Solutions: 1) Reprogram timer 2) Program one shot timer 3) Fake (use same default interval(10ms) for both case (6 and 16 ms)) 4)Force user to set: default_interval mod requested_interval==0.
Not sure what the question here is. If it's a poll, then my preferred method is "Program one shot timer"...
Cheers,
Brendan
):