atari-home.de - Foren
Hardware => Hardware (High-End) => Thema gestartet von: tost40 am Sa 15.08.2020, 09:30:52
-
Hallo,
hat jemand auf dem Milan eine USB-Karte am laufen?
Wenn ja, welche?
Von der Software her müsste es unter Mint laufen, oder?
Viele Grüße
Martin
-
Hallo,
hat da niemand Erfahrungen?
Viele Grüße
Martin
-
Leider nein, habe ich nie versucht. Da ich einen IDE Kartenleser (Hot Swap fähig) drin habe und auch eine Netzwerkkarte, war der Leidensdruck nie groß genug, da etwas zu unternehmen. Zumal ich MagiC verwende und es Treiber wahrscheinlich nur für MiNT gibt (wenn überhaupt).
-
Ich wollte eine USB2 PCI Karte mit VIA6212 Chip für den Milan gangbar machen. Leider bootet der Milan nach dem Einsetzen der Karte nicht mehr, sondern der Bildschirm bleibt einfach schwarz. Der Bootblock kommt mit der Karte offensichtlich nicht klar. Im PC läuft die Karte anstandslos.
Kennt jemand eine PCI-Karte (USB 1.1 vielleicht), mit der der Milan zumindest den Bootblock schafft? Anbei ein Foto von der Karte die ich probiert habe.
-
Gibt es überhaupt einen USB Stack für den Milan? Unter MiNT gibt es den ehci.ucd für PCI, müsste man mal in den MiNT Quellen schauen was für Chipsätze unterstützt werden?
Auf Macintosh Rechnern unter OS9 wurden z.B. nur PCI Karten mit NEC Chipsatz unterstützt.
-
Ist es nicht so, dass man mit einem PCI Adapter am Falcon eine PCI Karte mit NEC (USB) Chipsatz nutzen kann? Ich hatte mir damals extra eine solche Karte besorgt, aber nie benutzt, da ich keinen PCI Adapter habe. Das war weit vor der Lightning-Zeit.
Möglicherweise funktioniert das am Milan.
-
Beim Milan ist bestimmt noch wichtig ob 5V oder 3,3V PCI Karte ...
-
Gibt es überhaupt einen USB Stack für den Milan? Unter MiNT gibt es den ehci.ucd für PCI, müsste man mal in den MiNT Quellen schauen was für Chipsätze unterstützt werden?
Ich hatte mich erstmal an den vorhandenen Sourcen aus den Linux Quellen orientiert. Der VIA6212 ist dort recht gut dokumentiert.
Auf Macintosh Rechnern unter OS9 wurden z.B. nur PCI Karten mit NEC Chipsatz unterstützt.
Ich würde auch noch einen Test mit einer entsprechenden NEC-Karte machen. Die Frage ist halt, ob "neumodische" Karten prinzipiell bereits am Bootblock des Milan scheitern. Das PCI interface des Milan erkannte bisher bei allen Karten die Vendor- und Product-ID. Bei Netzwerk- und Grafikkarten bootet der Milan ohne Probleme, auch wenn das OS dann keine Treiber bereitstellen kann.
-
Ist es nicht so, dass man mit einem PCI Adapter am Falcon eine PCI Karte mit NEC (USB) Chipsatz nutzen kann? [...] Möglicherweise funktioniert das am Milan.
Hast Du die Karte noch im Zugriff und könntest kurz schauen, welcher NEC-Chip das wäre?
-
Beim Milan ist bestimmt noch wichtig ob 5V oder 3,3V PCI Karte ...
Ja, die Karte ist eine 5V Karte und sollte demnach elektrisch passen.
-
Schaue und suche mal dort -> https://github.com/freemint/freemint/tree/master/sys/usb/src.km/ucd/ehci
-------
struct pci_device_id ehci_usb_pci_table[] = {
{ PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB_2,
PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_SERIAL_USB_EHCI, 0, 0 }, /* NEC PCI EHCI module ids */
{ PCI_VENDOR_ID_PHILIPS, PCI_DEVICE_ID_PHILIPS_ISP1561_2,
PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_SERIAL_USB_EHCI, 0, 0 }, /* Philips 1561 PCI EHCI module ids */
/* Please add supported PCI EHCI controller ids here */
{ 0, 0, 0, 0, 0, 0, 0 }
-------
Ich würde sagen am besten eine möglichst alte NEC USB PCI Karte. Aber vielleicht und wahrscheinlich ist der NEC Chipsatz abwärtskompatibel, keine Ahnung?
Frage über das atari-forum.com mal am besten David Galvez ...
-
Ja soweit ich das in Erinnerung habe, wird eine NEC Karte benötigt! Hatte das zwar nie in meinem Milan getestet aber gab da wohl einige die das gemacht haben.
-
@Chocco frag mal @joska aus dem atari-forum.com. Könnte sein, dass der tatsächlich eine USB-Karte in seinem Milan am Laufen hat. Ich hatte auch überlegt eine einzubauen, aber leider ist der Platz dafür nicht vorhanden und ich benötige sie auch nicht zwangsläufig.
-
Ist es nicht so, dass man mit einem PCI Adapter am Falcon eine PCI Karte mit NEC (USB) Chipsatz nutzen kann? [...] Möglicherweise funktioniert das am Milan.
Hast Du die Karte noch im Zugriff und könntest kurz schauen, welcher NEC-Chip das wäre?
Ich habe die Karte derzeit nicht zur Hand. DIe Chancen stehen aber gut, dass es der NEC D720101 sein könnte. USB 2.0 jedenfalls. Soll auch in der Firebee werkeln, daher wohl auch die Treiber. Genaueres weiß ich aber nicht.
-
Hast Du die Karte noch im Zugriff und könntest kurz schauen, welcher NEC-Chip das wäre?
Ich habe die Karte derzeit nicht zur Hand. DIe Chancen stehen aber gut, dass es der NEC D720101 sein könnte. USB 2.0 jedenfalls. Soll auch in der Firebee werkeln, daher wohl auch die Treiber. Genaueres weiß ich aber nicht.
Ich habe eine PCI-Karte mit dem NEC Chip besorgt. Das PCI-BIOS des Milan erkennt auch diese Karte nicht. Ich kann mir eigentlich nur vorstellen, dass das PCI-BIOS von 1998 eine USB 2 Karte ignoriert/nicht erkennt, weil USB 2 erst ab 2000 in Mode kam.
Ist das möglich?
-
Ich glaube ich weiß jetzt, wo meine PCI USB Karte mit dem NEC Chip ist. Ich sehe morgen mal nach und melde mich.
-
Startet der Milan denn mit der Karte drin? Das BIOS ist dafür nicht unbedingt zuständig, die Karte muß von einem Treiber initialisiert werden (zumindest bei ISA Karten).
-
Startet der Milan denn mit der Karte drin? Das BIOS ist dafür nicht unbedingt zuständig, die Karte muß von einem Treiber initialisiert werden (zumindest bei ISA Karten).
Soweit ich es verstanden habe, wird die Erkennung der Karte vom BIOS vorgenommen. Die Initialisierung zur Benutzung übernimmt dann der entsprechende Treiber. Die Realtek Netzwerkkarte wird z.B. vom BIOS erkannt und gemäß der ClassID als Netzwerkkarte vom PCI-BIOS gelistet. Auch eine zugesteckte Matrox GraKa wird erkannt und gelistet, kann mangels Treiber aber nicht genutzt werden.
Die Liste der ClassIDs gibt es z.B. hier: https://blog.ladsai.com/pci-configuration-space-class-code.html (https://blog.ladsai.com/pci-configuration-space-class-code.html)
Ich habe jetzt zwei USB2-Karten versucht, aber das PCI-BIOS ignoriert sie irgendwie. Es wird nichtmal angezeigt, dass da überhaupt eine Karte im Slot steckt.
Da USB2 erst ab ca. 2000 eine Rolle spielt, könnte es ja sein, dass das PCI-BIOS im Milan (1998) die ClassID 0x0c0320 nicht akzeptiert, weil unbekannt. Das wäre doof, weil man das PCI-BIOS updaten müsste, was ohne Sourcen schwierig wird.
Edit: Vielleicht mal eine USB1.1 probieren..
-
PCI-Karten müssen sich (eigentlich) "ruhig" verhalten, solange ihre Register im Configuration-Space noch nicht initialisiert wurden, sollten also passiv am Bus hängen.
Manche frühe (USB-) Karten hatten allerdings einen "Legacy Support"-Modus, die - ohne dass die Karte vollständig initialisiert ist - dem Rechner eine PS/2-Tastatur und -Maus vorspielen konnten (damit man im BIOS nicht ohne dastand).
Nicht ausgeschlossen, dass sowas reinspielt. Da kommen dann so komische, "magische" Sachen wie "A20 Gate" ins Spiel, die ich nie verstanden habe (und auch nie verstehen wollte).
-
Soweit ich es verstanden habe, wird die Erkennung der Karte vom BIOS vorgenommen. Die Initialisierung zur Benutzung übernimmt dann der entsprechende Treiber. Die Realtek Netzwerkkarte wird z.B. vom BIOS erkannt und gemäß der ClassID als Netzwerkkarte vom PCI-BIOS gelistet. Auch eine zugesteckte Matrox GraKa wird erkannt und gelistet, kann mangels Treiber aber nicht genutzt werden.
Ich habe jetzt zwei USB2-Karten versucht, aber das PCI-BIOS ignoriert sie irgendwie. Es wird nichtmal angezeigt, dass da überhaupt eine Karte im Slot steckt.
Okay, dann startet der Rechner wenigstens. Dann sollte man mal mit lspci schauen, ob das was sieht. Vorausgesetzt, der USB PCI Controller im Milan kann mit der Karte was anfangen...
-
Soweit ich es verstanden habe, wird die Erkennung der Karte vom BIOS vorgenommen. Die Initialisierung zur Benutzung übernimmt dann der entsprechende Treiber. Die Realtek Netzwerkkarte wird z.B. vom BIOS erkannt und gemäß der ClassID als Netzwerkkarte vom PCI-BIOS gelistet. Auch eine zugesteckte Matrox GraKa wird erkannt und gelistet, kann mangels Treiber aber nicht genutzt werden.
Ich habe jetzt zwei USB2-Karten versucht, aber das PCI-BIOS ignoriert sie irgendwie. Es wird nichtmal angezeigt, dass da überhaupt eine Karte im Slot steckt.
Okay, dann startet der Rechner wenigstens. Dann sollte man mal mit lspci schauen, ob das was sieht. Vorausgesetzt, der USB Controller im Milan kann mit der Karte was anfangen...
Ich nehme an, das sollte "PCI controller" heissen?
Wenn die Karte nicht vom PCI scan (den das PCI BIOS beim Systemstart macht) als vorhanden erkannt wird, dann kann der PCI configuration space nicht gelesen werden. Da brauchst Du nicht weiter zu probieren.
Vielleicht sind das doch 3.3V-only Karten?
-
Ich nehme an, das sollte "PCI controller" heissen?
??? Ja.
Wenn die Karte nicht vom PCI scan (den das PCI BIOS beim Systemstart macht) als vorhanden erkannt wird, dann kann der PCI configuration space nicht gelesen werden. Da brauchst Du nicht weiter zu probieren.
Kann lspci keinen neuen scan "zu Fuß" machen?
Vielleicht sind das doch 3.3V-only Karten?
Dann sollten sie aber die 5V Kerbe nicht haben und sich daher gar nicht stecken lassen. 3,3V only ist IMO ziemlich selten.
-
Ich habe gerade mal lspci auf dem Falcon mit CTPCI gestartet, und zwar unter MagiC. Das listet brav die vorhandenen Karten auf. Und MagiC hat zwar einen _PCI cookie, aber wird der wirklich schon beim boot vom TOS gefüllt? Oder ist das ein Speicherbereich im Controller?
-
Ich habe gerade mal lspci auf dem Falcon mit CTPCI gestartet, und zwar unter MagiC. Das listet brav die vorhandenen Karten auf. Und MagiC hat zwar einen _PCI cookie, aber wird der wirklich schon beim boot vom TOS gefüllt? Oder ist das ein Speicherbereich im Controller?
Das PCI-BIOS ist beim CT60-TOS (für CTPCI) im Flash und die PCI-Enumeration wird bereits beim Booten durchgeführt (das müsste eigentlich im Output erscheinen). Danach sind die Karten aktiv (Speicherbereiche zugeordnet) und warten "nur noch" auf einen Treiber. Rate mal, woher ich das weiß ;)
Das lspci liest die Information lediglich aus (holt sich das _PCI cookie und darüber die PCI-Bios Einsprungpunkte).
-
Das PCI-BIOS ist beim CT60-TOS (für CTPCI) im Flash und die PCI-Enumeration wird bereits beim Booten durchgeführt (das müsste eigentlich im Output erscheinen).
Ja, weiß ich und sehe ich auch.
Danach sind die Karten aktiv (Speicherbereiche zugeordnet) und warten "nur noch" auf einen Treiber. Rate mal, woher ich das weiß ;)
Das lspci liest die Information lediglich aus (holt sich das _PCI cookie und darüber die PCI-Bios Einsprungpunkte).
Nur überlebt dieser Cookie den Start von MagiC bzw ist MagiC darauf vorbereitet? Muß wohl, wenn lspci was sinnvolles anzeigt, aber MagiC initialisiert doch sonst auch alles selber.
-
Also ich kann mir nur vorstellen, das im PCI-BIOS des Milan ein Bug ist. Erkannt und eingebunden werden verschiedene GraKa, Netzwerkkarten und SCSI-Controller. Diese lassen sich über lspci auch anzeigen.
Bei USB2 bootet die Maschine entweder nicht (VIA Chipsatz) oder die Karte wird nicht als PCI Device erkannt und in die Enumeration eingebunden (NEC Chip).
Wie könnte man z.B. über ein Programm im Auto-Ordner ein PCI-Device "nachmelden"? PCI unterstützt ja hot plug, um im laufenden Betrieb Devices zu tauschen.
-
Eine mögliche, weitere Ursache: USB-Karten sind meist Multi-Function-Devices, d.h. auf einer Karte sind mehrere Funktionen, die im PCI-Scan wie mehrere Karten auftauchen. NEC- (oder besser OHCI-/EHCI-, die sind alle mehr oder weniger identisch) USB-Karten haben meist 4 Functions (also praktisch wie 4 Karten in einem Slot).
Grafik- und Netzwerkkarten haben üblicherweise nur eine Function. Ich weiss, dass frühe Versionen des PCI-BIOS Multifunction-Devices nicht unterstützt haben (im Milan möglicherweise auch?), weil ich den Teil, der die abhandelt, für Didier Mequignon's CTPCI TOS beigesteuert habe.
Allerdings habe ich das so in Erinnerung, dass in dem Fall zumindest die erste Function auf der Karte im Scan auftauchen müsste - das scheint aber auch nicht der Fall zu sein?
Grundsätzlich kann die PCI-Enumeration auch nachträglich (z.B. im AUTO-Ordner) ablaufen. Dazu ist aber eine sehr genaue Kenntnis des (PCI-) Chipsatzes. der Speicherkonfiguration und ein Testsystem notwendig. Es ist ja (auch wenn's so aussieht) nicht so, dass da nur die Geräte aufgelistet würden (das wäre einfach): jede Karte wird (in einem speziellen Modus) abgefragt: "wer bist du, was kannst du", "wieviele Functions", "welche Speicheradressen", "welche I/O-Adressen", "welches Alignment", "Interrupts?", "Bus Master?", usw., ihre Konfigurationsregister entsprechend gesetzt sowie die Einstellungen gespeichert, damit sie später von den Treibern abgefragt werden können.
USB-Karten sind insofern nochmal speziell, dass sie Bus-Master sind (sie übernehmen temporär den PCI-Bus und schreiben "rückwärts" Daten in den Speicher des Hosts, der dafür natürlich entsprechend vorbereitet sein muss). Das macht's noch ein wenig komplizierter.
-
Grafik- und Netzwerkkarten haben üblicherweise nur eine Function. Ich weiss, dass frühe Versionen des PCI-BIOS Multifunction-Devices nicht unterstützt haben (im Milan möglicherweise auch?), weil ich den Teil, der die abhandelt, für Didier Mequignon's CTPCI TOS beigesteuert habe.
Hurra, ein Experte! 8)
Grundsätzlich kann die PCI-Enumeration auch nachträglich (z.B. im AUTO-Ordner) ablaufen. Dazu ist aber eine sehr genaue Kenntnis des (PCI-) Chipsatzes. der Speicherkonfiguration und ein Testsystem notwendig. Es ist ja (auch wenn's so aussieht) nicht so, dass da nur die Geräte aufgelistet würden (das wäre einfach): jede Karte wird (in einem speziellen Modus) abgefragt: "wer bist du, was kannst du", "wieviele Functions", "welche Speicheradressen", "welche I/O-Adressen", "welches Alignment", "Interrupts?", "Bus Master?", usw., ihre Konfigurationsregister entsprechend gesetzt sowie die Einstellungen gespeichert, damit sie später von den Treibern abgefragt werden können.
Wenn ersteres so einfach wäre, müßte das doch auch in lspci machbar sein. Und der PCI-Bus selbst wird ja schon vom BIOS initialisiert, so daß dessen Adressen und Konfigurationsregister bekannt sind. Die werden ja von lspci brav aufgelistet,
USB-Karten sind insofern nochmal speziell, dass sie Bus-Master sind (sie übernehmen temporär den PCI-Bus und schreiben "rückwärts" Daten in den Speicher des Hosts, der dafür natürlich entsprechend vorbereitet sein muss). Das macht's noch ein wenig komplizierter.
Für die Initialisierung und die Treiber schon, aber die reine Abfrage?
-
Grafik- und Netzwerkkarten haben üblicherweise nur eine Function. Ich weiss, dass frühe Versionen des PCI-BIOS Multifunction-Devices nicht unterstützt haben (im Milan möglicherweise auch?), weil ich den Teil, der die abhandelt, für Didier Mequignon's CTPCI TOS beigesteuert habe.
Hurra, ein Experte! 8)
/* PCI BIOS for CT60 with CTPCI
* Coldfire MCF547X/MCF548X & MCF5445X
*
* Didier Mequignon 2005-2012 e-mail: aniplay@wanadoo.fr
* Markus Froschle 2007
Mittlerweile habe ich schon mehr vergessen als ich damals wusste ;)
Grundsätzlich kann die PCI-Enumeration auch nachträglich (z.B. im AUTO-Ordner) ablaufen. Dazu ist aber eine sehr genaue Kenntnis des (PCI-) Chipsatzes. der Speicherkonfiguration und ein Testsystem notwendig. Es ist ja (auch wenn's so aussieht) nicht so, dass da nur die Geräte aufgelistet würden (das wäre einfach): jede Karte wird (in einem speziellen Modus) abgefragt: "wer bist du, was kannst du", "wieviele Functions", "welche Speicheradressen", "welche I/O-Adressen", "welches Alignment", "Interrupts?", "Bus Master?", usw., ihre Konfigurationsregister entsprechend gesetzt sowie die Einstellungen gespeichert, damit sie später von den Treibern abgefragt werden können.
Wenn ersteres so einfach wäre, müßte das doch auch in lspci machbar sein. Und der PCI-Bus selbst wird ja schon vom BIOS initialisiert, so daß dessen Adressen und Konfigurationsregister bekannt sind. Die werden ja von lspci brav aufgelistet,
Hab' ich was von "einfach" gesagt? :D
lspci fragt nur die Infos ab, die das PCI-BIOS kennt (über die vom PCI-BIOS bereitgestellten XBIOS-Funktionen). Ergo: wenn da die Karte nicht auftaucht, kennt das PCI-BIOS sie nicht. Am lspci rumzumachen bringt also nichts.
Wenn's nicht an der Karte selbst liegt (m.E. immer noch einigermassen wahrscheinlich), liegt's am PCI-BIOS.
Weil das beim Milan im ROM liegt, müsste es durch ein neues, fehlerbereinigtes PCI-BIOS im AUTO-Ordner ersetzt werden. Keine triviale Aufgabe und nicht an einem Samstagnachmittag gemacht (für sich schon nicht und erst recht nicht, wenn man die Innereien des Milans nicht kennt). KV (kannste vergessen), fürchte ich.
USB-Karten sind insofern nochmal speziell, dass sie Bus-Master sind (sie übernehmen temporär den PCI-Bus und schreiben "rückwärts" Daten in den Speicher des Hosts, der dafür natürlich entsprechend vorbereitet sein muss). Das macht's noch ein wenig komplizierter.
Für die Initialisierung und die Treiber schon, aber die reine Abfrage?
Korrekt. Aber was soll @Chocco (nur) mit der Abfrage? Dass die Karte drinsteckt und nicht funzt, weiss er auch so ;)
-
Der im Milan verwendete Controller ist ein Intel 82371 PIIX. Ich habe jetzt zwei günstige PCI USB 1.1 Karte bestellt. Mal sehen, ob die dann erkannt werden.
-
Das Datenblatt der PCI bridge ist da zu finden: https://www.digchip.com/datasheets/parts/datasheet/227/SB82371.php
Auf den ersten Blick ist dieser Chip nicht sonderlich intelligent, der sollte eigentlich mit allen Karten können, die elektrisch kompatibel sind.
-
Der im Milan verwendete Controller ist ein Intel 82371 PIIX. Ich habe jetzt zwei günstige PCI USB 1.1 Karte bestellt. Mal sehen, ob die dann erkannt werden.
Der 82371 ist die PCI<->ISA Bridge, kein PCI Controller.
Der PCI-Controller heißt im Milan PLX9080, Datenblatt ist hier: https://der-ingo.de/de/milanhelp/download.html
-
Der im Milan verwendete Controller ist ein Intel 82371 PIIX. Ich habe jetzt zwei günstige PCI USB 1.1 Karte bestellt. Mal sehen, ob die dann erkannt werden.
Der 82371 ist die PCI<->ISA Bridge, kein PCI Controller.
Der PCI-Controller heißt im Milan PLX9080, Datenblatt ist hier: https://der-ingo.de/de/milanhelp/download.html
Stimmt, ich hatte einfach die Meldung auf dem Bildschirm abgelesen und dabei das PCI ISA Bridge übersehen :)
-
Hier zum Milan PCI
-
Dann sollten sie aber die 5V Kerbe nicht haben und sich daher gar nicht stecken lassen. 3,3V only ist IMO ziemlich selten.
Auch da habe ich schon alles mögliche gesehen. 3.3V only-Karten mit zwei Kerben z.B.
P.S.: und, psst, nicht weitererzählen: ich hab' auch schon selber Kerben gefeilt. Nicht in eine PCI-, sondern in eine Riser-Karte, die "falschrum" war. Und ja, der Rechner läuft noch (mit der Riser-Karte) und allen Slots befüllt ;)
-
Vielleicht mal bei Uwe Schneider nachfragen?
https://www.uweschneider.de/Projekte_Milan.php
Gruß
Wolfgang
-
Hier zum Milan PCI
Vielen Dank, hier wird die Sache ja mal richtig gut erklärt! Ich frage mich, wie ermittelt das PCI-BIOS beim Booten, an welchen Adressen nach DeviceID und VendorIDs gesucht werden muss? Ist das im Controller hart verdrahtet oder besitzt der Controller ebenfalls ein kleines EPROM, in dem die Adressen abgelegt sind?
-
Evtl. hilft das:
Alle PCI-Spezifikationen enthalten eine vollständige Plug-And-Play-Unterstützung, das heißt, das Computer-BIOS oder das Betriebssystem kann feststellen, welche Ressourcen (Speicherbereiche, I/O-Adressen, Interrupt-Leitungen) eine solche Karte benötigt und diese so zuteilen, dass keine Konflikte zwischen den Karten entstehen.
Jede PCI-Karte wird durch einen eindeutigen Hersteller-Code (Vendor ID) identifiziert, welcher dem Hersteller durch die PCI SIG zugeteilt wurde, sowie durch eine Baugruppen-Nummer (Device ID), die jeder Hersteller für seine Karten frei vergeben kann. Dadurch ist die zugehörige Treiber-Software in der Lage, von ihr unterstützte Baugruppen sicher zu identifizieren.
-
Ich frage mich, wie ermittelt das PCI-BIOS beim Booten, an welchen Adressen nach DeviceID und VendorIDs gesucht werden muss? Ist das im Controller hart verdrahtet oder besitzt der Controller ebenfalls ein kleines EPROM, in dem die Adressen abgelegt sind?
Das ist im Datenblatt zum PLX9080 (S. 16ff) eigentlich recht gut erklärt. Es wird eben nicht an bestimmten Adressen nach irgendwas gesucht, sondern die Karten (bzw. die PCI-Slots) werden aktiv abgefragt.
Dazu wird der PCI-Controller in den "Configuration Space Access"-Modus gebracht. Dann wird für jeden Slot versucht, das VendorID/DeviceID-Register auszulesen (das Register ist auf der PCI-Karte). Wenn da was anderes als $FFFF_FFFF steht (das ist eine ungültige VID/DID-Kombination, die für "nix da" steht), steckt in diesem Slot eine Karte, die konfiguriert werden kann/muss.
Gelesen/geschrieben werden also immer Register des Controllers, der dann seinerseits Register auf der Karte (so vorhanden) liest/schreibt.
-
PDF vom VT6212L PCI USB 2.0 (https://datasheetspdf.com/pdf-file/607110/Via/VT6212L/1) da steht das der auch "Serial EEPROM Support for Boot Register Update" hat. Und in der Wiki https://de.wikipedia.org/wiki/Peripheral_Component_Interconnect gibt es auch eine gute Übersicht.
-
Ist doch beim Atari NEC Chipsatz only ...
-
Ist doch beim Atari NEC Chipsatz only ...
Um zu verstehen wie die Kommunikation bei PCI stattfindet kann man sich auch andere Datenblätter angucken.
-
PDF vom VT6212L PCI USB 2.0 (https://datasheetspdf.com/pdf-file/607110/Via/VT6212L/1) da steht das der auch "Serial EEPROM Support for Boot Register Update" hat.
Keine Ahnung wozu das gut sein soll, aber das EEPROM im USB-Controller hat mit der PCI-Konfiguration m.E. nichts zu tun.
-
Für mich liest sich das so als ob man ein externes Serial EEPROM optional damit ansteuern könnte... wozu ist mir aber auch nicht klar. Wobei ich mich immer noch Frage wie die Informationen zu den Ressourcen vom Mainboard-BIOS von der PCI-Karte abgerufen werden können... sind die da irgendwo gespeichert? Das BIOS kann ja nicht alle Hersteller und Geräte-ID's kennen. Grafikkarten haben ja ein eigenes BIOS aber viele Karten scheinen kein eigenes BIOS zu haben bzw. zu benötigen. Wann müsste denn zwingend ein BIOS auf einer PCI-Karte sein?
-
... Wobei ich mich immer noch Frage wie die Informationen zu den Ressourcen vom Mainboard-BIOS von der PCI-Karte abgerufen werden können... sind die da irgendwo gespeichert?
Hast Du den Text gelesen, den Du selbst oben verlinkt hast, bzw. was ich obendrüber geschrieben habe?
Die PCI-Karte wird bei der PCI-Enumeration abgefragt, welche Ressourcen sie in welchen Häppchen wo (Memory-Mapped oder I/O, bzw. Interrupts oder Bus Mastering) braucht (die Information ist auf der Karte hart verdrahtet). Das PCI-Bios teilt ihr dann ein passendes Häppchen zu und speichert diesen Wert auf der Karte in standardisierten Registern (im Configuration Space). Die Karte "weiss" dadurch, auf welchen Adressen sie sich angesprochen fühlen soll. So werden Kollisionen zwischen Karten (wie es beim ISA-Bus "normal" war) vermieden. Beim nächsten Boot ist die Info weg und wird aufs neue zugeteilt (es könnte ja sein, dass Du mittlerweile die Karte woanders reingesteckt hast).
Wenn Du's genau wissen willst: hier ist eine m.E. prima Beschreibung (https://wiki.osdev.org/PCI)
Das BIOS kann ja nicht alle Hersteller und Geräte-ID's kennen. Grafikkarten haben ja ein eigenes BIOS aber viele Karten scheinen kein eigenes BIOS zu haben bzw. zu benötigen. Wann müsste denn zwingend ein BIOS auf einer PCI-Karte sein?
Eine PCI-Karte braucht nur dann ein BIOS, wenn sie eins braucht (auf den meisten Karten ist keins drauf).
Grafikkarten haben meist eins, damit der Rechner auch beim Booten (also noch bevor der PCI-Scan lief) schon was auf dem Bildschirm anzeigen kann (da steckt üblicherweise ein "INT10H" - also ein "Ur-PC-BIOS" drin, das vom Rechner-BIOS dann benutzt wird). Oft genug ist es aber auch so, dass die Grafikkartenhersteller zusätzlich damit ihre IP verschleiern (bei meinem ColdFire-5484-Rechner z.B. muss deshalb zwingend beim Booten ein Mini-PC-Emulator das BIOS-ROM ausführen, weil ATI nirgends dokumentiert hat, wie die Clocks auf der Grafikkarte angesteuert werden).
-
@mfro, sicher habe ich das gelesen, allerdings muß ich manches teilweise sehr ausführlich erklärt bekommen bis ich's richtig verstanden habe. Danke das du dir die Mühe gemacht hast... super erklärt. :)
-
Eine der neuen (alten) USB 1.1 Karten ist heute angekommen. Es handelt sich um eine PCI USB 1.1 mit Lucent USS312 Chip. Gerade mal in den Milan eingesteckt und tatsächlich wird sie erkannt :D (siehe Screenshot)
Im nächsten Schritt würde ich eine Doku suchen und schauen, wie man die Karte initialisiert. Vielleicht gibt es ja auch einen Linux-Treiber, bei dem man sich etwas abschauen kann.
Genug Material zum Lernen habe ich jedenfalls erstmal. Vielen Dank nochmals für die Tipps.
-
Eine der neuen (alten) USB 1.1 Karten ist heute angekommen. Es handelt sich um eine PCI USB 1.1 mit Lucent USS312 Chip. Gerade mal in den Milan eingesteckt und tatsächlich wird sie erkannt :D
Na also, ist doch schon mal was (@Arthur: in dem Screenshot kann man übrigens schön sehen, wie das PCI-BIOS die Ressourcen verteilt hat).
Gibt es für den Milan schon irgendwelche USB-Treiber? Möglicherweise für die (gängigeren) NEC-Chips?
Falls ja, könnte es möglicherweise eine Abkürzung geben: die Karte scheint eine OHCI-Karte zu sein. Damit ist der Registersatz eigentlich standardisiert und falls es einen Treiber gäbe, müsste man dem bloss die VendorID+ProductID beibringen (indem man eine existierende, die man nicht braucht, einfach patcht). Falls es also einen Treiber gäbe, wäre das jedenfalls einen Versuch wert.
P.S.: das ist übrigens (seltsamerweise) tatsächlich *kein* Multi Function Device. Möglicherweise ist das doch die Ursache, dass die anderern Karten nicht erkannt werden?
-
Hört sich an als würde hier demnächst ein passender Treiber geboren werden... und ja der Screenshot von Chocco ist sehr erhellend.
-
Ich hatte meinen Milan heute auch mal wieder in Betrieb und folgendes Programm auf dem Raubvogel gefunden: PCI Info (Version 0.5a)
Das Programm gibt's leider nur in Französisch, aber man kann mit dem anscheinend eine Menge Informationen auslesen (siehe Screenshot). Es läuft leider nicht unter MiNT, aber dafür unter Magic. Unter TOS habe ich's nicht ausprobiert.
Was USB-Treiber für den Milan angeht: So wie es aussieht sind USB-Treiber in MiNT 1.18.0 enthalten. U. a. ein Treiber für die NetUSBee wenn ich das richtig sehe. Und es gibt für MiNT ein "USBTOOL":
https://github.com/freemint/freemint/tree/master/tools/usbtool (https://github.com/freemint/freemint/tree/master/tools/usbtool)
Zu was letzteres auch immer gut sein mag. Ich bin da leider nicht so der Fachmann für. :-(
-
Es gibt auf jeden Fall USB-Treiber für die NetUSBee für TOS, wenn ich das richtig sehe. Die Treiber können hier runtergeladen werden:
https://www.perdrixapps.com/usb (https://www.perdrixapps.com/usb)
Der Sourcecode der Treiber ist hier verfügbar:
https://github.com/anodynesoftware/netusbee (https://github.com/anodynesoftware/netusbee)
Stellt sich die Frage ob diese Treiber auch mit einer PCI-USB-Karte laufen, wenn auf der USB-Karte der Chipsatz verbaut ist, der von diesem Treiber unterstützt wird?
-
Kommt sogar noch viel besser! Und manchmal sieht man den Wald vor lauter Bäumen nicht! Es gibt auch USB-Treiber für TOS, die hier zu finden sind:
http://www.freemint.org/ (http://www.freemint.org/)
usb4tos wäre insofern auch noch ein Versuch wert? ;)
-
Nein, das ist ein wenig zu einfach gedacht.
NetUSBee = Phillips isp1160 Chip
Hier:
PCI-Karte mit Lucent USS312.
Lucent USS312 != Phillips isp1160.
Der isp116x weiss auch nichts von PCI.
Oder anders gesagt: wenn Du durstig in einer Taverne in Thessaloniki sitzt, nutzt es dir gar nix, wenn Du auf Hawaianisch ein Bier bestellen kannst.
-
!= = ungleich
-
Heute habe ich einige Dokumente zum OHCI gelesen und in einigen Sourcen (Linux und FreeDOS) geschmökert. Als erster Schritt müsste mittels OHCI-Treiber die Karte initialisiert werden. Das sieht nicht all zu schwer aus. Darauf aufbauend müsste ein USB-Stack gesetzt werden, der dann die einzelnen Geräteklassen unterstützt.
Was aktuell von @czietz für VME-USB gebaut wurde könnte dafür vielleicht angepasst werden?
-
Lightning VME und ST nutzen denselben USB-Chip wie die NetUSBee, eben aus dem Grund, dass es dafür einen Treiber gibt, der nur portiert werden musste. Wie Markus schon anmerkte, nützt Dir dieser Treiber nichts, wenn Du eine PCI-Karte ansteuern möchtest. Zielführend dürfte eher sein, weitere EHCI-kompatible Karten ausfindig zu machen und diese dem existierenden Treiber für USB-PCI-Karten bekannt zu machen: https://github.com/freemint/freemint/blob/master/sys/usb/src.km/ucd/ehci/ehci-pci.c
-
Heute habe ich einige Dokumente zum OHCI gelesen und in einigen Sourcen (Linux und FreeDOS) geschmökert. Als erster Schritt müsste mittels OHCI-Treiber die Karte initialisiert werden. Das sieht nicht all zu schwer aus. Darauf aufbauend müsste ein USB-Stack gesetzt werden, der dann die einzelnen Geräteklassen unterstützt.
Was aktuell von @czietz für VME-USB gebaut wurde könnte dafür vielleicht angepasst werden?
Im Freemint Kernel existiert ein ehci Treiber, diesen könnte man sicher anpassen.
-
Im Freemint Kernel existiert ein ehci Treiber, diesen könnte man sicher anpassen.
... wenn man eine EHCI-Karte hätte. @Chocco 's Karte ist aber OHCI.
-
Ja ok, stimmt schrieb er !
-
Ich hatte meinen Milan heute auch mal wieder in Betrieb und folgendes Programm auf dem Raubvogel gefunden: PCI Info (Version 0.5a)
Das Programm gibt's leider nur in Französisch, aber man kann mit dem anscheinend eine Menge Informationen auslesen (siehe Screenshot). Es läuft leider nicht unter MiNT, aber dafür unter Magic. Unter TOS habe ich's nicht ausprobiert.
Habe PCI Info heute geladen und es läuft prima auch unter Milan TOS. Die Ressource Datei ist im Ordner FR untergebracht. Vermutlich kann man einen Ordner DE erzeugen und dort eine übersetzte Ressource unterbringen. Die Ressource Datei lässt sich problemlos mit Interface öffnen und bearbeiten.
-
Im Freemint Kernel existiert ein ehci Treiber, diesen könnte man sicher anpassen.
... wenn man eine EHCI-Karte hätte. @Chocco 's Karte ist aber OHCI.
Das irritiert mich jetzt etwas. Ich habe in den letzten Tagen gelernt:
HCI = USB
UHCI = USB, wie Intel es für den Host Controller als Standard gesetzt hat
OHCI = USB, wie Compaq es als Standard gesetzt hat
EHCI = Die Erweiterungen für USB2 und zwar nur diese. Sobald ein Gerät über USB1.1 angesprochen werden muss, wird der Aufruf endsprechend des verwendeten Host Controller an den entsprechenden UHCI/OHCI Treiber weitergeleitet.
Wenn im Mint Kernel ein EHCI-Treiber enthalten ist, müsste dann dort nicht auch ein UHCI oder OHCI Treiber inkludiert sein?
-
Wenn im Mint Kernel ein EHCI-Treiber enthalten ist, müsste dann dort nicht auch ein UHCI oder OHCI Treiber inkludiert sein?
Sicher. Alles richtig.
Der EHCI-Treiber ist für die High-Speed Devices am Bus zuständig. Wenn er Full- oder Low-Speed Devices findet, gibt er die Zuständigkeit dafür an einen OHCI- (oder auch UHCI-)- Host Controller ab (um das alles noch ein wenig komplizierter zu machen, gibt es mittlerweile aber auch EHCI-Controller, die über einen "Rate Matching Hub" ohne die Hilfe anderer Geräte mit Low- und Full-Speed devices umgehen können).
Der OHCI Treiber in MiNT ist der für die NetUSBee. Mit dem kannst Du aber - wie schon gesagt - für deine Karte nicht besonders viel anfangen, weil er nichts über PCI weiss (wobei ein PCI-Treiber natürlich ähnlich aussehen wird, das Register-Interface ist ja weitgehend dasselbe). Einen Teil der Funktionalität kannst Du dort abspickeln, nur - wie ursprünglich erhofft - mit VendorID/DeviceID umpatchen ist es eben nicht getan, Du brauchst einen neuen HCD. So sehe ich beim isp1160 auf den ersten Blick (habe mich aber nicht tiefer damit beschäftigt) z.B. keine HCCA (Host Controller Communications Area), die ein PCI-Chip im Hauptspeicher des Rechners erwartet und per PCI Bus Mastering darauf zugreift. Kann er ja auch gar nicht haben, weil die NetUSBee ja am ROM Port hängt.
Für deine Karte wirst Du die aber brauchen.