Devices
-
bogdanontanu
Re:Devices
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.
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.
Re:Devices
Hi,
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
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).bogdanontanu wrote:Usually you can let BIOS setup the PCI devices at boottime if you do not deal with this in your OS.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Devices
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.
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.