OSDev.org

Tested again stll reports 8 all with header type 0x00000000

bye
pkd

hmm. i think i'm starting to get it better. According to http://www.acm.uiuc.edu/sigops/roll_your_own/7.c.0.html, only devices with header_type&0x80 set have multiple functions (clicker blindly assumes that any number of functions is avl. on any devices)

Moreover, only header_type&0x7f==0x01 are PCI-to-PCI busses and according to http://www.acm.uiuc.edu/sigops/roll_your_own/pci.h structure of PCI type 1 headers, the header then contains how many busses are behind the bridge (so we could reduce the amount of work done by gradually increasing the amount of busses.)

http://prdownloads.sourceforge.net/clic ... z?download

should actually fix the bug (hopefully).

On systems having multiple bus (that is, most systems), the number of buses to be probed should be adjusted automatically by reading the 'max bus' on the bridge header.

as soon as confirmed, i'll patch the "PCI info" page on the FAQ with the new knowledge

now it reports 8 devices on my toshiba laptop, but no more vga devices. hmmm ... it is plain possible, that the ati rage mobility 128 device installed on my laptop belongs to the class of misbehaving devices - it does not even support vbe2.0 bios.

apart from that it works. Would be nice - as a next step - to display the names of the devices, say "3com 3c59x NIC" or so.

But what talk I have I not yet implemented this stuff myself.

http://prdownloads.sourceforge.net/clic ... z?download

should hopefully *really* fix it. I had the opportunity to test it on real hardware myself first, this time, and it reported everything correctly (hope so)

the missing video card with 0.8.20c is due to a misdetection of PCI-to-PCI bridges bug

@BI, that'd be great to have names, indeed, but that means having the whole table of product and vendors IDs and that's not something i'm willing to do in the microkernel ...

detects 11 devices, lists also some multifunction devices on console01.

one vga0 video device is registered. Thats plain ok.

regarding the names ... well, I wouldn't have them in the microkernel itself too - but in some process, which actually performs the pci-enumeration and registration stuff - and loads the drivers and sorta into memory? bad idea?

no. that'd certainly be a good idea though i don't have KDS access for user-level code so far, so it'll need a bit more time before such a fancy feature can be added ...

Ive been away for a few days so sorry it has taken so long to reply.

It works now reporting only eth0, Ive also looked through most of the devices and they all seem to report properly, The only one that has any problem is vidio reports an Unknown but i think that is to do with the TV-OUT on my graphics card which is an ATI-Radeon 9600.

Keep up the good work

pkd.

hmu. more likely to be due to a not-yet-very-well-supported pci-to-pci bridge

http://prdownloads.sourceforge.net/clic ... z?download
http://prdownloads.sourceforge.net/clic ... z?download

Finally, the sources are there. Thanks for those who helped with the tests.
The new 0.8.20 release should compile on cygwin platforms (no need for a cross-compiler, no longer need for DJGPP under WinXP) and the image should run fine in BOCHS and QEMU (if you give enough "slave drives" to QEMU ...)

Hi,

I've based my PCI enumeration code on what I've found in here, and I have a couple problems with some base addresses: they are off by one.

For example:
EIDE, base_addr4: FFA1
NICS: base_addr0: E801, E881, EC01 (I have three).

However, other base registers -appear- to be fine. Whether they are or not is another matter ;-)

My code is fairly identical in terms of enumerating a single device, and everything else works fine (we've got a realtek 8139 pci driver working on real hardware, for instance). Having to subtract 1 from various base registers seems very, very, very bad ;-)

Latest code is viewable at http://glek.net/subversion/os/kernel/modules. File of most interest is PCI_bus.ml

Jonathan

I've not decoded the baseAddr's in the Clicker PCI code, you should find a function exported from the pcicore code called 'makePciResource' which is called by clicker device drivers to use as an ioResource, this amongst other things, decodes the baseAddr into an ioport or memory range.

http://www.acm.uiuc.edu/sigops/roll_your_own/7.c.html explains how the addresses in PCI are encoded.

Hope this is of some help to you