LISTING DES PÉRIPHÉRIQUES PCI pci, scan, bios, x86, Source N°38884

Information sur la source

Catégorie :Application Unix Classé sous : pci, scan, bios, x86 Niveau : Débutant Date de création : 01/08/2006 Date de mise à jour : 02/08/2006 10:19:48 Vu / téléchargé: 3 323 / 304

Auteur : _dune2_

Ecrire un message privé

Note :
Aucune note

Commentaire sur cette source (5)

Ajouter un commentaire et/ou une note

Description

Cliquez pour voir la capture en taille normale

Salut,
ce code réalise le listing des cartes PCIs du système.
Il a été écrit pour montrer les possibilités d'intéractions sur la gestion des cartes PCI en passant uniquement par le Bios système. Ce dernier point permet un portage facile de ce code sous windows ou dos car seules "printf" et "ioperm" sont appelés, et ils ont été appelé via un "call" pour permettre une couche d'abstraction sur ces 2 fonctions.

Ces accés au bus PCI peuvent servir d'exemple pour l'écriture d'un micro-OS par exemple ou alors pour l'écriture d'un bootstrap lorsqu'il n'y a pas de fonction de gestion des périphériques PCI fourni par l'OS.

Dans cette exemple, je n'effectue que la lecture du VendorID et du DeviceID, mais on peut tout à fait lire les BAR0...BAR4 (Base Address Register 0..4) des cartes PCIs pour ensuite les remapper dans l'espace d'adressage local via un appel à "mmap" et s'en servir ...

Source

Dans le zip.

Dans le zip.

Conclusion

Pour compiler cet exemple, il faut utiliser nasm puis gcc et non ld, car on utilise des appels aux fonctions de la libc :
nasm -f elf pci_scan.asm
gcc pci_scan.o -o pci_scan

Ensuite, l'utilisation des IOs < 1024, il faut être root pour pouvoir l'executer ... (et heureusement car on réalise un accés au système physique)

Voilà ...

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

pci_scan.asm 10 217 octets

Télécharger le zip

Historique

02 août 2006 10:19:48 :: Remplacement de la simple fonction _lire_16bits par les fontions pci_read_byte, pci_read_word et pci_read_dword pour réutilisation.

Sources de la même categorie

Toutes les sources de la catégorie Application Unix

Sources en rapport avec celle ci

Commentaires

Commentaire de patatalo le 02/08/2006 00:01:53 administrateur CS

salut,

bof bof bof, peut mieux faire...

2 appels a deux fonctions externes non incluses
ioperm n'a aucun rapport avec le bios.
pas de structure PCIBRIDGE, PCINONBRIGDE, ...
pas de fonctions pci_read_byte, pci_read_word, pci_read_dword
pas de possibilité d'ameliorer pour un micro-OS et pas grand chose en rapport avec le BIOS.

@++
Commentaire de _dune2_ le 02/08/2006 09:43:18

Salut,

Pour les 2 appels aux fonctions externes, elles sont présentes pour ne pas noyer le code dans la gestion de l'affichage sur une console pour le "printf". Ensuite, l'appel à "ioperm" est nécéssaire sous linux pour autoriser l'accés aux IOs situés à une adresse inferieure à 1024, d'où sa présence.

Je suis d'accord avec toi pour les routines pci_read_(byte|word|dword), je vais les réecrire en les isolant du reste.

Maintenant, le but de ce code est de montrer l'utilisation des IOs du Bios (enfin, il me semble ? non ?) pour acceder aux différents périphériques PCI de manière simple sans utiliser l'OS (et je ne pense pas utiliser l'OS en accédant aux IOs 0x0CFC et 0x0CF8, arrête moi si je me trompe ?).

Pour ce qui est des périphériques PCI, l'utilisation d'un bridge ou non est totalement transparent et ne change en rien l'énumération des périphériques (à ce que je me souvienne ...). Je ne vois donc pas l'interêt de gérer une structure PCIBRIDGE et PCINONBRIDGE. Peux-tu préciser le fond de ta pensé sur ce point ? Je peux avoir omis quelque chose, et je serai content d'être remis dans la bonne direction ;)

dune2.
Commentaire de _dune2_ le 02/08/2006 10:07:22

re,

Oui, tient, d'ailleur ... je viens de réaliser que 1024 correspond à 0x0400 ... or 0x0CF8 et 0x0CFC sont au-delà de 0x0400. Et pourtant, aprés plusieurs tests, il s'avère que l'appel à "ioperm" est nécéssaire pour acceder à 0x0CF8 (j'ai eu un doute suite au post de Patalo). Sinon, c'est le segfault assuré (réaction normal pour un accés à un espace d'adressage interdit).

C'est bizarre cette différence de comportement par rapport au "man" de ioperm :
[...]
DESCRIPTION
Ioperm positionne les bits de permission d'accès du processus aux ports commençant à l'adresse from étalés sur num octets à la valeur turn_on. L'utilisation de ioperm nécessite les privilèges de Super-User.

Seuls les 0x3ff premiers ports d'entrée/sortie peuvent être indiques de cette manière. Pour d'autres ports, il faut utiliser la fonction iopl.
[...]

Mais il est bien évident que l'appel à ioperm n'est nécéssaire qu'au bon fonctionnement sur un système linux.

dune2.
Commentaire de patatalo le 02/08/2006 10:14:46 administrateur CS

re,

c'est tout simplement qu'une enumeration ne sert pas a grand chose si elle n'est pas utilisee pas ensuite et donc pas tres utile pour un micro-OS.

l'utilisation des structures PCIBRIDGE, PCINONBRIDGE n'est peut etre pas tres utile pour une enumeration mais fait au moins une structure PCIHEADER qui est identique pour les deux, ton code sera plus clair pour tout le monde.

l'acces aux ports 0xCFC / 0xCF8 n'utilise pas le bios, il existe réellement des fonctions bios pour ce genre d'opérations donc je ne vois pas non plus le rapport avec le bios. (il existe également des fonctions bios pour faire de la sortie ecran).

utiliser l'interface linux, je ne vois toujours pas en quoi cela peut servir à un micro-OS.

c'est juste ça

@++
Commentaire de _dune2_ le 02/08/2006 10:45:18

re,

OK, je comprends mieux ta réaction :)

Pour l'utilisation sur un micro-OS, je voulais parler uniquement de la partie _pci_read_byte, _pci_read_word, _pci_read_dword, qui permet d'acceder à l'espace de configuration d'un périphérique PCI en utilisant le N° de bus, device et fonction. L'énumération des cartes PCI n'est en fait qu'un exemple concret montrant son utilisation (j'ai donc rajouté l'affichage des device_id et vendor_id aussi à titre d'exemple). Je suis tout à fait d'accord que celà n'apporte strictement rien à un micro-OS. Mais cette énumération peut servir de base pour rechercher un périphérique précis (ou une classe de périphérique) en réutilisant cette énumération et en comparant le vendor_id et device_id des cartes trouvés. Ensuite, l'accés aux autres informations de la carte, et en particulier des différentes zones d'adresses remappable de la carte (BAR0-BAR5), se fera aussi par ces fonctions de bases (sauf le remapping des zones bien entendu, qui nécéssitera une petite conversation avec l'IOMMU de manière à avoir son remapping virtuel du bus physique coté soft ;) ).

Tu as tout à fait raison pour ce qui est de la structure PCIHEADER, je vais la rajouter pour remplacer les indexes de lecture par des constantes ce qui eclaircira la lecture pour ceux qui ne connaissent pas forcément l'organisation d'un espace de configuration PCI (header commun d'ailleur au PCI, PCI-X, PCI-Express et AGP puisque tous ces bus sont énumérés au même titre et peuvent être utilisés par le même moyen).

Et merci pour la précision sur les IOs 0x0CF8 et 0x0CFC, je pensais qu'ils représentaient une sorte d'interface avec le Bios (Ecriture commande @0x0CF8 et Lecture resultat @0x0CFC).

dune2.

Ajouter un commentaire

Discussions en rapport avec ce code source

Interruption Bios ou Dos ? par Valmont

interruption du bios et du dos sous windows par eedy31

interruption BIOS par project0

Probléme d'Affichage pour les chaines de caractères par HwW_Mb

Cherche doc instructions asm x86... par akboy7015

lire information du BIOS par Sogec

le bios fonctionnement (prog) par chercheur de connaisance

Lecture du code du bios par KATMAI666

Serai t'il possible de faire démarer un systeme d'exploitation sans bios par nico20011caus

bios par Hardouz