Enumerate PCI Buses

[Multit4sker]

Hi All,

In the context of a school project on computers architecture, I have to make a PCI Bus Enumerator.
The code will be divided into two layers :
- An enumeration layer that handle enumeration of the differents buses and devices in each bus. It then must use a data structure to store all these informations (Tree maybe?) and other informations about the device (vendor id, device id, functions). It should generate a tree representing all the devices and buses.
This layer will then be ported to the kernel land (fictive of course).

- A display layer that take the data structure and display it (using dashes, colors, spaces etc... It must be fashion).

To make this program, I can use assembly languages or C language. I can't use any API. I must talk directly to the hardware and/or use BIOS routines.
I have to deliver a binary that runs on Linux or Win32.

Having only assembly concepts (Hello world :/), I don't see at all how can I start this project. I read some articles on OsDev and I more or less understood the operation (use two loops to browse the buses and devices and check for every device/bus if it exists and if it have functions). But I don't know how to code this.

It's why I ask for your help. Naturally, I don't want any pre-made code, I'm very motivated to learn.

Thanks.

(Sorry for my english, I'm french).

[Octocontrabass]

I can't use any API. I must talk directly to the hardware and/or use BIOS routines.
I have to deliver a binary that runs on Linux or Win32.

It sounds like you have to fight the operating system for access to the hardware...

[Combuster]

PCI for the hardware and ioperm for dealing with linux. Obviously it's nonsense to have to deliver Linux/Windows apps and not be allowed to use any APIs at all, so I assume that restriction is only for the PCI-related part.

[SpyderTL]

I can't use any API. I must talk directly to the hardware and/or use BIOS routines.
I have to deliver a binary that runs on Linux or Win32.

It sounds like you have to fight the operating system for access to the hardware...

It sounds like his professor doesn't understand how computers work.

I'd double check the requirements and make sure you aren't missing something.

[BrightLight]

I can't use any API. I must talk directly to the hardware and/or use BIOS routines.
I have to deliver a binary that runs on Linux or Win32.

It's not going to be easy, that is if you figure out a way to do it. Linux and Win32 prevent hardware access to programs. And I'm pretty sure they don't let you call the BIOS, either.

[Peterbjornx]

Is it required that the computer keeps operating normally afterwards?, you could use kexec() to load a stub kernel containing your pci code and a simple kprintf or on windows, load a driver that clears the interrupt flag and proceeds to load that same kernel

[Kevin]

Linux and Win32 prevent hardware access to programs.

Combuster already mentioned ioperm(). This will generally only work as root, but that's it.

It might be helpful to turn off hardware interrupts while you're accessing the PCI registers in order to avoid any conflicts with the kernel accessing them. After iopl(), this should be possible.

[Multit4sker]

Hi guys, I'm really sorry, I didn't see I had so much answers.
Obviously, I can't use API only on the PCI related part.
According to my professor, this program will be executed on a virtual machine.
Here is the homework if you can understand it better than me (Maybe I haven't explained it well) : https://www.dropbox.com/s/4e7ufkpshcsoc ... r.pdf?dl=0
Again, I don't tell you to make this for me, I want to do it myself (If I success, I will go out stronger :p ).

Thanks !

[SpyderTL]

Nope, you explained it perfectly.

The PDF actually says that you must a) write a PCI enumerator in ASM or C for a kernel that does not exist yet, and b) you must deliver an EXE that will run in Linux or Windows.

I'm not sure how both of these statements can be in the same document. They appear to be mutually exclusive. I would talk to the instructor and verify that this wording is correct, because it makes no sense to me...

Personally, I think that I would ignore the line about delivering an EXE that will run on Windows or Linux. I think that line is a mistake. It has nothing to do with OS development at all.

I did notice that they included a link to the osdev wiki as a reference for you to do research. Pretty cool!

[iansjack]

The PDF actually says that you must a) write a PCI enumerator in ASM or C for a kernel that does not exist yet, and b) you must deliver an EXE that will run in Linux or Windows.

Actually, the PDF says

You’ll create a userland mock-­‐up that will later be ported to the kernel space.

and deliver

A binary that runs on Linux or Win32.

That sounds perfectly doable to me, with no mutual exclusion involved. The only aspect I am not 100% sure of is whether userland programs can access the PCI memory space. But "lspci" does this very thing, so I presume it is possible.

[Combuster]

lspci runs unprivileged, so it will be using device files and system calls rather than direct port access (and the required mutual exclusion probably happens in the kernel).

[iansjack]

Yes. A little research turned up this paper from AMD that shows that lspci uses kernel APIs: http://developer.amd.com/wordpress/medi ... access.pdf . But it also points out that a userland program can access the memory directly (via /dev/mem). It says that it is inadvisable to do so as it might affect system stability. I can't see that reading the configuration space could cause such problems, though writing could be a mistake.

Bottom line - it can be done, and this is presumably what the question intends. Really, the Wiki article on PCI tells you just about all you need to know. (And a bit of research will no doubt tell you how to do it in Windows.)

[onlyonemac]

The PDF actually says that you must a) write a PCI enumerator in ASM or C for a kernel that does not exist yet, and b) you must deliver an EXE that will run in Linux or Windows.

I assume (read: hope) that they mean a *binary* that will run on Linux or Windows, not an *EXE*. Linux does not use .exe files, and if they're going to the trouble of mentioning Linux I certainly hope that they are not mentioning it just for the few Wine users out there...

[iansjack]

The PDF actually says that you must a) write a PCI enumerator in ASM or C for a kernel that does not exist yet, and b) you must deliver an EXE that will run in Linux or Windows.

I assume (read: hope) that they mean a *binary* that will run on Linux or Windows, not an *EXE*. Linux does not use .exe files, and if they're going to the trouble of mentioning Linux I certainly hope that they are not mentioning it just for the few Wine users out there...

That's probably why the PDF specifies "binary" rather than "EXE".

[onlyonemac]

The PDF actually says that you must a) write a PCI enumerator in ASM or C for a kernel that does not exist yet, and b) you must deliver an EXE that will run in Linux or Windows.

I assume (read: hope) that they mean a *binary* that will run on Linux or Windows, not an *EXE*. Linux does not use .exe files, and if they're going to the trouble of mentioning Linux I certainly hope that they are not mentioning it just for the few Wine users out there...

That's probably why the PDF specifies "binary" rather than "EXE".

I was assuming that when SpyderTL wrote "The PDF actually says..." that he was quoting it exactly as it was written in the PDF.