pci id und chipset bei Hardware

lockdoc

lockdoc

Well-Known Member
Hi,

evtl. kann mir ja jemand sagen, was der Unterschied zwischen der pci id (dem 4 stelligem hex code des devices) ist und der chipset Nummer.

Gibt es da ein 1 zu 1 mapping und wo koennte ich das nachschlagen?

LG
 
Soweit ich weiß, braucht jeder Treiber eine Vendor ID und PCI-ID um die passende Hardware zu erkennen. Eine Abbildung zur Chipsatz ID hab' ich noch nicht gesehen, denke auch dass die gebraucht wird für's Papier.
 
Vendor ID, Device ID und Revision ID sind standardisierte Felder im PCI Config Space, welche Device Treiber nutzen können (sollen), um einen bestimmten PCI Endpunkt zu identifizieren. Die Vendor ID wird von einem Konsortium vergeben; die andern Felder dürfen Vendoren selbst wählen.

Ich vermute mal, dass Du mit "Chipset Nummer" meinst, was wir üblicherweise oben im Datenblatt eines Chips finden, d.h. mit welcher Nummer Menschen das Bauteil referenzieren: Da ein Chip gleich mehrere Endpunkte haben kann, gibt's keine 1:1 Zuordnung von Chip auf PCI IDs.

Beispiel: Die Southbridge der AMD Geode LX Prozessoren heisst offiziell "CS5536" und stellt mehrere PCI Endpunkte bereit. Vendor ID ist immer 0x1022 für AMD; die Device ID ist je nach Endpunkt unterschiedlich, z.B. 0x209A für den IDE Controller oder 0x2094 für OHCI.
 
Danke fuer die Antworten.

hmm, also kann mir folgendes passieren?

Ich suche mir ein neues notebook raus, vergleiche die chipsets mit den jeweiligen man pages und sehe, dass alle unterstuetzt werden. Nun kaufe ich mir das Teil und auf einmal geht es doch nicht,
da der chipset aus der manual page nur eine einzige der device ids funktioniert.

???
 
Ja, das kann passieren. Sicherer ist daher das Vorgehen mit den Device-ID: Einfach das Gerät im Markt einschalten und im Windows-Hardwaremanager die Device-IDs rausschreiben. Anschließend nach diesen in /usrc/src/sys greppen. Findet er sie, sind die Chancen gut, dass es funktioniert.

Es gibt aber zwei Einschränkungen:
- Einige Geräte werden nicht anhand der Device-ID identifiziert, stattdessen anders.
- EInige Hersteller - z.B. Intel bei WLAN-Karten - sind dazu übergegangen diverse unterschiedliche Geräte hinter einer Device-ID zu verstecken und ihren universellen Treiber das intern auseinanderzupfen zu lassen.
 
So nochmal eine Frage zum Device Subsystem:

Code: 
1111:2222 3333:4444

a) Bedeutet das Subsystem, dass der vendor 1111 ein Device 2222 irgendwo in seine Hardware einbaut, welches er gar nicht entwickelt hat, sondern sich den Chip vom Vendor 3333 mit der Device ID 4444 nimmt?
b) oder genau umgekehrt?
c) oder bedeutet es was ganz anderes?
 
"Subsystem Vendor ID" und "Subsystem ID" sind zwei Felder um Karten voneinander zu unterscheiden. Für die "Subsystem Vendor ID" ist wie bei der "Vendor ID" eine offizielle, von der PCI-SIG vergebene Nummer nötig; die "Subsystem ID" kann vom Hersteller frei gewählt werden.

Ich meinte irgendwo gelesen zu haben, dass diese Felder typischerweise für die Identifikation des Karten-Herstellers (vs. der des Chip-Herstellers) verwendet werden. So hätten dann zwei Netzwerkkarten, die zwar den selben Chip verbauen, aber von unterschiedlichen Herstellern geliefert werden, die selben "Device ID" u. "Vendor ID", aber unterschiedliche "System Vendor ID" und "Subsystem ID".
 
Also, wenn es ein Subsystem gibt, dann ist das subsystem relevant fuer den treiber und nicht vendor_id:device_id?
 
Vincent Vega schrieb:
" So hätten dann zwei Netzwerkkarten, die zwar den selben Chip verbauen, aber von unterschiedlichen Herstellern geliefert werden, die selben "Device ID" u. "Vendor ID", aber unterschiedliche "System Vendor ID" und "Subsystem ID".
Zum Vergrößern anklicken....

Nachdem ich jetzt eine weile im Netz nach infos gesucht hab und viel gelesen habe, habe ich das jetzt erst richtig verstanden wie du das meintest.

So und jetzt nochmal eine Frage um ganz sicher zu gehen, anhand eines Beispiels:

Es gibt die NIC "RTL8111/8168B PCI Express Gigabit Ethernet controller" mit 0x10EC : 0x8168 (vendor : device).

Nun haben 2 Unterschiedliche Mainboards diesen Chip onboard drauf:
Code: 
#vendor device
1043	83a3	ASUSTeK Computer Inc.	M4A785TD Motherboard
1458	e000	Giga-byte Technology	GA-EP45-DS5 Motherboard

Jetzt hat man einen Treiber dafuer entwickelt, und der Entwickler hatte nur das Giga-byte Mainboard zur hand um das zu testen.

Kann der Entwickler jetzt wissen, dass dieser Treiber auch fuer das ASUSTeK Mainboard funktionieren wird?
 
Code: 
vendor device vendor  chip name
0x10EC 0x8168 Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller

Nun suche ich in der datenbank nach allen sub_vendors und sub_devices mit den selben vendor_id und device_id, wie der RTL Chip.

Code: 
vendor device sub_ven sub_device vendor                 name
0x10ED 0x8168 0x1043  0x83a3     ASUSTeK Computer Inc.  M4A785TD Motherboard
0x10ED 0x8168 1458    0xe000     Giga-byte Technology   GA-EP45-DS5 Motherboard

Jetzt behandel ich die sub_vendor und sub_device Ids, als Vendor und Device Id,
wenn ich dafuer jetzt einen Eintrag als Vendor/Device finde, dann sind das eigenstaendige re-branded chips.
Finde ich keinen Eintrag, dann sind es Karten (wie in dem Beispiel Mainboards mit einem Onboard Chip), welche diesen Chip benutzten.




So jetzt kommt ein Beispiel, wo ich rebranded Chips finde:

Code: 
vendor device vendor chip name
0x8086 0x1229 Intel  82557/8/9/0/1 Ethernet Pro 100

Ich kucke also wieder, welche sub_vendor und sub_devices gibt es mit
vendor=8086 und device=1229:
Code: 
vendor device sub_ven sub_device vendor     name
0x8086 0x1229 0x0e11  0xb1a4     Compaq     NC7131 Gigabit Server Adapter

Ich nehme jetzt 0e11 als vendor und b1a4 als device und kucke ob ich einen Eintrag finde.
Und voila, gelistet als:
Code: 
vendor  device vendor chip name
0x0e11  0xb1a4 compaq NC7131 Gigabit Server Adapter
Daran sehe ich, dass es ein rebranded chip ist.

Ich hoffe, dass das soweit klar ist.


So jetzt wegen meiner Frage... was genau hast du da nicht verstanden?? xD
 
lockdoc schrieb:
Code: 
vendor device sub_ven sub_device vendor                 name
0x10ED 0x8168 0x1043  0x83a3     ASUSTeK Computer Inc.  M4A785TD Motherboard
0x10ED 0x8168 1458    0xe000     Giga-byte Technology   GA-EP45-DS5 Motherboard
Zum Vergrößern anklicken....

Jetzt verstehe ich; die IDs der beiden Mainboards sind Subsystem ID u. Subsystem Vendor ID. Das war mir durch Deinen ursprünglichen Post nicht ganz klar geworden.

Die Frage war ja, ob ein Entwickler nun wissen kann, dass sein Treiber, den er auf einem der beiden Boards entwickelt und getestet hat, auch auf dem anderen Board funktioniert. Meiner Meinung nach lässt sich hier keine pauschale Antwort geben. Einerseits kann man es nicht wissen, wenn man es nicht getestet hat. Anderseits werden die meisten Entwickler nicht alle möglichen Kombinationen von Chip und Card Manufacturer zum Testen da haben und dennoch funktionieren die meisten Treiber...
 
Hmm, also ist es ein: sollte, aber muss nicht., hier waere es mal interessant eine Statistik zu haben bei wieviel Prozent das sollte so liegt.

Aber gut, damit ist jetzt definitv eine Antwort da. Vielen Dank
 
Es gibt dort draußen grundsätzlich aus Sicht des Systems zwei Arten Geräte:

1. Generische Chips werden softwareseitig immer gleich angesprochen, d.h. der verwendete Treiber ist unabhängig dem, der den Chip in sein Produkt verbastelt hat, immer gleich. In den letzten 10 Jahren gab es einen kleinen Trend zu diesen Geräten und inzwischen sind die allermeisten solche. Der Grund ist einfach: Die Hersteller der Geräte können sich die Entwicklung bzw. Anpassung eines eigenen Treiber sparen und auf die Arbeit des Chipherstellers zurückgreifen.

2. Spezielle Geräte, die unabhängig des verbauten Chips eigene Treiber benötigen. Wie oben gesagt in den letzten Jahren selten geworden, da die Hersteller keinen Bock haben für jeden Mist eigene Treiber zu bauen und so. Trifft man heute fast nur noch in Spezialhardware, nicht mehr in Massenhardware für Konsumer. Der vielleicht bekannteste Vertreter dieser Gattung ist die VIA Envy24 Soundchipfamilie, wo wirklich Karte anders war und der Entwickler der FreeBSD-Treiber sie manuell durchgemessen hat.

Ich ahne worauf du hinaus willst. Ich habe mich da schon mal drum gezofft und bleibe dabei: Herausfinden ob Hardware unterstützt wird indem man nach Device-ID in /usr/src grept, funktioniert nicht. Zumindest nicht für den Laien. Dafür gibt es mehrere Gründe:
1. Nicht alle Treiber beinhalten Device-ID. Zum Beispiel krallt sich "ahci" alles, was er als AHCI Controller erkennt, was es genau für ein Gerät ist, ist ihm völlig egal.
2. Wenn eine Device-ID vorhanden ist, ist es keine Garantie, dass das Gerät auch gegriffen wird. Die Device-ID kann auch Teil eines Quirks sein, der das Greifen explizit verhindert. Sie kann Teil der ID-Datenbank sein. Und so weiter.
3. Da heutige Hardware wie gesagt meist generisch ist, reicht es sehr oft aus eine fehlende Device-ID nachzutragen und schon rennt der Kram. Das tritt gerade dann auf, wenn ein Chiphersteller mal wieder eine neue Revision bringt. Zum Beispiel ist Realtek dafür sehr bekannt.

Der einzige Weg sicher sein zu können ist in die Hardwarenotes zu schauen. Da dort aber nicht alles drinsteht und auch nicht drinstehen kann, bleibt nur einen Kernel zu booten und die dmesg zu analysieren. Das ist einer der Gründe, weshalb ich es immer noch gut fände, wenn alle Nutzer Konsequent die dmesg ihrer neu gekauften Hardware in den dmesg-Thread stellen würden. Ab und an kann Google eine liefern...
 
Hi Yamagi,

das ist wirklich relativ schwer auf diesem Gebiet Fuss zu fassen, da ich darueber nicht so leicht Informationen finde, darum bin ich dir schonmal sehr Dankbar fuer die Beschreibungen.

Yamagi schrieb:
Der einzige Weg sicher sein zu können ist in die Hardwarenotes zu schauen. Da dort aber nicht alles drinsteht und auch nicht drinstehen kann, bleibt nur einen Kernel zu booten und die dmesg zu analysieren.
Zum Vergrößern anklicken....

Die Hardwarenotes arbeiten allerdings auf chipset Ebene und ich konnte keine Info's zur device ID finden. Und soweit ich jetzt mitbekommen habe ist die Beziehung von Chipset zur device Id und umgekehrt leider nicht eindeutig.

Jetzt wuerd ich gerne noch wissen, inwiefern die Infos in der dmesg sehen kann, was mir pciconf nicht bieten kann.
 
lockdoc schrieb:
Jetzt wuerd ich gerne noch wissen, inwiefern die Infos in der dmesg sehen kann, was mir pciconf nicht bieten kann.
Zum Vergrößern anklicken....

pciconf sagt dir nur, dass ein Treiber gegriffen hat. Die dmesg sagt dir dazu, was er meint gefunden zu haben. Nehmen wir zum Beispiel mal die Netzwerkkarte:

Code: 
em0@pci0:0:25:0:	class=0x020000 card=0x849c1043 chip=0x15038086 rev=0x05 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = network
    subclass   = ethernet

Okay, da ist also eine Intel-NIC im System und em(4) hat sie gegriffen. Aber was genau sehen wir nicht.

Code: 
em0: <Intel(R) PRO/1000 Network Connection 7.1.9> port 0xf040-0xf05f mem 0xfa600000-0xfa61ffff,0xfa628000-0xfa628fff irq 18 at device 25.0 on pci0
em0: Using an MSI interrupt
em0: [FILTER]
em0: Ethernet address: 14:da:e9:0f:80:71

dmesg sagt uns aber. Es ist eine "PRO/1000", die einen MSI nutzt. Ihre MAC-Adresse ist "14:da:e9:0f:80:71".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben