Page 1 of 1

hardware resources

Posted: Tue Sep 28, 2010 11:05 am
by a5498828
when pc starts, hardware resources like port, memory and irq are assigned to devices.

how is it done?
- does entire bus (pci) is granted pool of resources, and it must divide it between devices, or each device independly receive resources directly?


- how many device buses exist in mobo?
i know that usb is built on pci, what about ata/sata/com/lpt and others?

Re: hardware resources

Posted: Tue Sep 28, 2010 12:24 pm
by bewing
a5498828 wrote:when pc starts, hardware resources like port, memory and irq are assigned to devices.

how is it done?
Some are hardcoded (such as the PIT, keyboard, ISA DMA, PCI config registers). The BIOS assigns all the rest during boot time. Get a copy of RBIL and look at the PORTS file.
a5498828 wrote:- does entire bus (pci) is granted pool of resources, and it must divide it between devices, or each device independly receive resources directly?
No, the BIOS sets each device independently.
a5498828 wrote: - how many device buses exist in mobo?
i know that usb is built on pci, what about ata/sata/com/lpt and others?
Almost everything is built on PCI. Each motherboard is different. One of the main tasks of an OS during boot-time is to detect all the devices. This is a very complicated thing to do, and is described for each device in the wiki. There is no simple way. This is what all of us are working on, for all of our OSes.

Re: hardware resources

Posted: Tue Sep 28, 2010 2:01 pm
by Brendan
Hi,
a5498828 wrote:when pc starts, hardware resources like port, memory and irq are assigned to devices.

how is it done?
- does entire bus (pci) is granted pool of resources, and it must divide it between devices, or each device independly receive resources directly?
Firmware scans the PCI buses, and assigns resources to devices (memory mapped IO areas and IO port ranges) and also configures PCI to PCI bridges (assigning a "bus ID" to the bus on the other side of the bridge, then scanning devices on the new bus, then telling the bridge which memory mapped IO areas and IO port ranges are forwarded from one bridge to another). There's probably also a few other things done during this scan, like checking if any devices have ROMs, then mapping the ROM into the physical address space and copying the ROM into RAM (into the area from 0x000C0000 to 0x000F0000), then unmapping the ROM from the physical address space.

For ISA there's never more than one ISA bus. There's an "ISA Plug and Play" specification which allows the BIOS (and/or an OS) to autodetect ISA devices and assign resources to them. In this case detection and configuration is a relatively slow thing (because it's retro-fitted to ISA and has to avoid conflicts with cards don't support Plug and Play), so most BIOSs that support it cache information (in non-volatile memory) about ISA devices (and maybe other things) to speed it up. To help an OS find out about these devices there's some "Plug and Play BIOS" functions that the OS could use. There's also an "EXTENDED SYSTEM CONFIGURATION DATA SPECIFICATION" that describes a standardised way for the BIOS to store/cache information about devices, and to allow the OS to cooperate with the BIOS when the OS wants to change things.

Unfortunately most ISA devices don't support Plug and Play. For "non-PnP" ISA cards there's typically jumpers on the card itself which are used to tell it which resources to use (it can't be done by software). For these cards an OS has to "probe" or ask the user to tell the OS about them. As far as I know, none of the ISA devices built into the chipset (not cards) ever support "ISA Plug and Play". Because the BIOS is designed for a specific motherboard it knows about these devices, and if the resources used by them isn't hardwired the BIOS can use the chipset to enable/disable them and change the resources they use. That doesn't help an OS much, but information about these devices may be in the ESCD, and (for newer systems) these devices are described in the ACPI.

There was also "VESA Local Bus", which is an extension to ISA. As far as I know software (BIOS) can just treat these cards the same as it would ISA.

For MCA and EISA, both of these bus types support autodetection (similar to PCI), and unlike PCI there's only one of these buses (rather than a hierarchy of buses like PCI). I honestly don't know much about these buses, as they were rare before they became obsolete and are extremely rare now (e.g. not worth bothering with).

Finally there's "PC Card" (or PCMCIA or CardBus), which is something I know very little about (other than it's derived from PCI, but is slightly different to PCI). It's mostly obsolete now too - it was much more common than EISA or MCA, but was only used for laptops (and laptops have a significantly higher rate of attrition - it's much harder to upgrade components in a laptop, and after about 5 years the battery needs typically needs to be replaced and the owner decides to throw it away and get a newer/faster laptop). Because of the attrition rate, I've never really bothered looking into "PC Card". It got superseded by USB and ExpressCard (where ExpressCard relies on PCI Express and USB, and isn't a separate type of bus).
a5498828 wrote:- how many device buses exist in mobo?
i know that usb is built on pci, what about ata/sata/com/lpt and others?
First, there's a "bus" (something that could potentially be shared by 3 or more pieces of hardware, including a "controller") and a "link" (something that connects one piece of hardware to another, that can't be used by more than 2 pieces of hardware).

Things like Quickpath or Hyper-transport; DMI (which isn't visible to software and acts as a connection between northbridge and southbridge), and SATA are links, not buses. Other types of links include the old (proprietory) CD-ROM interfaces (typically found on sound cards from the 80486 era - "Sony", "Panasonic" and "Creative" interfaces), video (VGA/SVGA), PS/2 ports, and both serial and parallel ports. Most forms of networking could also be considered links (e.g. modern ethernet, infiniband, etc).

For buses, there's stuff I already mentioned above; plus IDE/ATA/ATAPI, SCSI, USB, IEEE 1394 (Firewire), the old floppy interface, SMBUS and I²C.


Cheers,

Brendan