OSDev.org

1. does all devices connected to the computer have a unique address?

No,

Most devices have a range of addreses.
For the old legacy devices you might find a fixed range in documents.

Intermediate non-PNP ISA devices might have a few options choosable by jumpers. Some PNP ISA have some functions/interfaces for detecting and setting up those addreses and IRQ's used.

For the new PCI devices there is a way to interogate and to setup each device. Confilicts must be avoided...

Usually you can let BIOS setup the PCI devices at boottime if you do not deal with this in your OS.

Hi,

bogdanontanu wrote:Usually you can let BIOS setup the PCI devices at boottime if you do not deal with this in your OS.

Somewhere (perhaps within the Linux source but I can't remember & I'm not at home to check) I read that the BIOS's resource conflict resolution is often inadequate (depending on BIOS and devices).

I would assume that (at least some) BIOS's only do enough configuration to handle common devices (FDC, HDC, video) and possibly only configure them for "legacy" mode - for e.g. the VGA IO ports and memory range rather than the full set of IO ports and LFB, or perhaps the older hard drive IO ports rather than the full bus mastering method. In addition you may want to support "hot plugged" PCI devices (as supported by some server's hardware), where the resources can't be determined until the device is plugged in.

I'd do all of the device detection first, working from the CPU's bus down (e.g. PCI, USB then ISA). After this I'd allocate resources from the bottom up, starting with old ISA devices (with fixed resources), then Plug & Play ISA, then PCI. For Plug&Play ISA and PCI devices I'd leave them set to the BIOS default settings unless these settings conflict with an earlier device's settings.


Cheers,

Brendan

there are indeed "broken" bios that may not perform correct PCI configuration if they're in presence of "unexpected" components (i suppose it'll mostly be due to "bridges" added).

Personnally i won't be worrying too much about such troubles while developing an OS kernel:
- chances that you manage to find a broken system to test your code on are weak unless you get a large userbase
- linux code is there and GPL for anyone who'd like to fix your kernel on his broken system
- if even licensing issues prevent such code integration, one could imagine to write PCI fixing code as a real-mode module executed *before* your kernel actually gets loaded.

Hai all


i am really happy and thankfull for your response to my queation