OSDev.org

Gentlemen,
I sought and found not the answers to many questions stirring my mind.

What can PCI and PCI32 and PCI-X do for me and how do they differ?
Is PnP a standard, a chipset, an API? What can PnP-related thingies (like a bios function) do for me?
Can I access the PCI bus through ports, does it vary among motherboards? How can I get a list of the pci-cards? What info will I get?

How does the memory-mapped IO work?

Cheers to you

Hi,

Adek336 wrote:What can PCI and PCI32 and PCI-X do for me and how do they differ?

AFAIK things like AGP, PCI32 and PCI-X are just extensions to basic PCI which mostly only effect the speed of the underlying electronics, but don't change the software interface (with a few minor exceptions).

Adek336 wrote:Is PnP a standard, a chipset, an API? What can PnP-related thingies (like a bios function) do for me?

IMHO Plug & Play is both a concept and a standard. The concept of plug & play is to allow software to detect what hardware is present so that the correct device drivers and resources (IO ports, IRQs, etc) can be used automatically, which allows new devices to be simply plugged in. For PCI and USB this concept is part of the corresponding standards.

For ISA devices this concept wasn't part of the original ISA standards, which led to computer technicians setting jumpers on individual cards to configure resources (and resolve conflicts), and people opening cases to figure out what devices are present before installing operating systems. To remove this mess an additional "Plug & Play" standard was created for ISA devices.

Adek336 wrote:Can I access the PCI bus through ports, does it vary among motherboards?

It's almost impossible to avoid accessing the PCI bus itself - for e.g. if you do an "IN AL,0x64" (to read from the ISA keyboard controller chip) the CPU will ask the PCI host controller for the byte at IO port 0x64. The PCI host controller would send the request to a PCI to LPC bridge. The LPC bridge returns the contents of this IO port to the PCI host controller, which returns it to the CPU.

Each PCI device also has a "PCI configuration space", which is logically seperate from both the IO port space and the physical memory space. Each device's PCI configuration space is used to detect the device and configure the resources (IO ports and physical address space areas) it uses.

For 80x86 based computers there are 3 methods of accessing these PCI configuration spaces. The first is to use the PCI BIOS, while the remaining 2 methods are direct IO port access (of which one of these methods is deprecated). All 3 methods are standard - it can be expected that any given motherboard will support the PCI BIOS and at least one of the direct IO port methods (if it supports PCI at all).

[continued]

[continued]

Adek336 wrote:How can I get a list of the pci-cards? What info will I get?

You'd get a list of PCI devices (which includes the PCI host controller, PCI to PCI bridges, the PCI to LPC bridge and PCI devices built into the motherboard, not just PCI cards) by scanning the PCI bus (or busses - some computers have multiple PCI host controllers). Exact details of how to perform this scan would justify a book, although I will provide an overview and the list of reference material I used if requested.

The information you get for each device includes the VendorID and DeviceID of the device, the resources it's currently configured for, the class of device it is, and possibly the software interface it uses (if it's a standardized device type, like an IDE or USB controller) .

Adek336 wrote:How does the memory-mapped IO work?

At a conceptual level, the CPU can be thought to have an address bus, a data bus and an "IO select". When you do "OUT 0x12,0x34" or "MOV [0x12],0x34" the CPU puts the same signals on both the address bus and data bus, with the only difference being the state of the IO select. If the hardware completely ignored this IO select then there would be no difference between IO port access and a normal memory access.

On "PC compatible" computers hardware doesn't ignore the state of the IO select. For example, the RAM controller won't respond to a request on the bus if the IO select says the request is for IO space. Other devices may choose to use IO space for some things and/or memory space for others. A video card would use IO space for some things and memory space for others, but may also support different "modes" where the card responds to memory space requests instead of IO space requests. This is memory mapped IO, at the "PC compatible" hardware level.

Some architectures don't have a logically seperate IO space and memory space, so that everything is memory mapped IO (as would be the case if the CPU's IO select was ignored or didn't exist). The Commodore 64 was like this, where the video controller chip, sound chip, etc were all assigned regions of the address space .

In addition it's possible for the operating system to emulate memory mapped IO. In this case an area is reserved such that accessing it results in an exception (page fault or general protection fault), and the exception handler decodes the instruction used and performs the associated IO port access (I wouldn't recommend it).


Cheers,

Brendan

Thanks now it seems clearer for me
One more thing. What's the subtle difference between driver pull & push?

Cheers.

Hi,

Adek336 wrote:Thanks now it seems clearer for me
One more thing. What's the subtle difference between driver pull & push?

For an OS there's 2 ways to start drivers. The first way is to get any drivers you feel like and try to use them. If they don't initialize correctly then you remove them, leaving only the drivrs that work. Often this method is used in conjunction with a script or list of drivers (e.g. DOS config.sys). This is "driver push", as the drivers are pushed into the OS to see what happens .

The other method is for the OS to use a pile of auto-detection to create a list of drivers that the OS needs, and then try to load device drivers for this list. The nice thing here is that the OS will only try to "pull" drivers into the OS when it needs them, so (theoretically) a script or list of drivers doesn't need to be setup beforehand.

For example, when my OS scans the PCI busses it extracts the VendorID and DeviceID from each PCI device, and then uses them directly to find the driver - if a card has vendor ID 0x8086 and device ID 0x1234 the OS looks for a device driver called "/drv/pci/8086/1234.drv".

The good thing about the "pull" model is that users don't have to setup anything - it can be automated. It also makes things much more complicated for the OS as it needs to detect everything first. This isn't too much of a problem for PCI, USB and Plug & Play ISA where allowances for detecting the hardware is built into the relevant specifications, but most ISA cards don't support Plug & Play, and just about everything (that's not PCI) on the motherboard (serial ports, parallel ports, floppy driver controller/s, etc) don't support anything for detection either (which can result in a hybrid system, or messy hacks).

Even though the pull model makes the OS more complicated it does make the device drivers easier to write - when the device driver starts it knows the device is present and can be told by the OS which resources (IO ports, etc) it needs to use.

For a better idea of what's needed for the "pull" model, have a look at:
http://www.mega-tokyo.com/forum/index.p ... eadid=7745.



Cheers,

Brendan

http://www.delorie.com/djgpp/doc/rbinter/ix/1A/B1.html

1AB101 INT 1A - PCI BIOS v2.0c+ - INSTALLATION CHECK
..

1AB181 INT 1A - PCI BIOS v2.0c+ - INSTALLATION CHECK (32-bit)
..

Is this of significant difference?