LISTING DES PÉRIPHÉRIQUES PCI
cs_patatalo
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
-
2 août 2006 à 00:01
_dune2_ Messages postés 141 Date d'inscription mercredi 19 juillet 2006 Statut Membre Dernière intervention 20 avril 2011 - 2 août 2006 à 10:45
_dune2_ Messages postés 141 Date d'inscription mercredi 19 juillet 2006 Statut Membre Dernière intervention 20 avril 2011 - 2 août 2006 à 10:45
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/38884-listing-des-peripheriques-pci
https://codes-sources.commentcamarche.net/source/38884-listing-des-peripheriques-pci
2 août 2006 à 10:45
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.
2 août 2006 à 10:14
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
@++
2 août 2006 à 10:07
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.
2 août 2006 à 09:43
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.
2 août 2006 à 00:01
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.
@++