www.mikrocontroller.net

Forum: FPGA, VHDL & Co. von PCIe Board in PC Arbeitsspeicher schreiben


Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielleicht eine ziemlich blöde Frage, weiß ich nicht. Aber ich stehe vor 
einem (kleinen?) Problem.

Ich habe hier ein PCIe Dev Kit von Altera und soll u. A. Daten vom FPGA 
an den PC senden. Nachdem ich mir die DMA Beispiele angesehen und die 
Dokus gelesen habe ist meine Überlegugn nun, ob es nicht auch ohne DMA 
geht.
Der ganze DMA Kram (zumindest in der vorhandenen Beispielanwendung) wird 
im Design recht groß und ich steige da noch nicht ganz durch (kann sich 
ja noch ändern).

Das Prinzip das hier benutzt wird (Daten vom PC in ein DMA Register im 
FPGA schreiben, dieser wird dadurch gestartet und schickt die Daten aus 
dem angegebene Adressbereich an den ebenfalls angegebenen Adressbereich 
des PCs) klingt für mich simpel.

Nun ist die Frage, ob ich das auch ohne DMA (Controller) realisieren 
könnte. Dann würde doc hschätzungsweise die CPU sich damit rumschlagen 
müssen!? Wäre kein Problem. Die bestehende anwendung läuft auf einem 
Pentium I, wird aber durch nen Core2 ersetzt. Was ich damit sagen will, 
die CPU sollte dafür genügend reserven haben.

Ich kann bisher Daten in beide Richtungen senden (nutze bisher Windriver 
von Jungo, war dabei, bin aber nicht der Softwareexperte und habe daher 
bisher nur damit rumprobiert, allerdings scheint mir das ganze nur 
bedingt flexibel zu sein). D. h. ich kann mit dem Windriver Daten ans 
PCIe Board senden, dort wertet sie meine Logik aus und antwortet z.B. 
darauf.

Nun würde ich halt gerne, nachdem der PC den Befehl gesendet hat, 
größere Datenmengen (im niedrigen MB Bereich) an den PC senden.
DMA kam mir da natürlich als erstes in den Sinn, scheint mir aber recht 
kompliziert zu implementieren zu sein.

Jetzt aber mal zu der eigentlichen Frage:
1. Ist es mein beschriebenes vorgehen (ohne DMA Controler) möglich? Also 
Daten vom PCIe Board an Speicherbereiche des PCs zu schicken und diese 
Dort (nachdem z.B. nen Interrupt ausgelöst wurde) auszulesen?

2. Wie reserviere ich für soetwas einen Speicherbereich am PC? Mei 
nerster Gedanke was malloc(). allerdings wird dies wohl so einfach nicht 
gehen, der Speicherbereich wird ja für das laufende Programm reserviert 
und ja auch nur im virtuellen Speicher freigegeben.

3. Falls es so funktioniert wie ich es vor habe, wie sieht es mit 
Geschwindigkeit aus?

4. Welche Alternativen hätte ich?


Vielleicht kann mir da ja jemand helfen, vielleicht bin ich ja auch 
völlig auf dem Holzweg.

KDC

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab da wohl eben ein wenig Halbwissen von DMA durcheinander 
gebracht. Die eigentlichen Fragen bleiben aber bestehen.

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo KDC,

also vorab, ich denke, wenn Du so etwas noch nie gemacht hast, brauchst 
Du ca. 4 Wochen bis das alles läuft wie Du es haben willst. Vielleicht 
etwas schneller wenn Du das alles mit Junko machen willst. Du brauchst 
aber auf jeden Fall einen Gerätetreiber.

Zu Deiner eigentlichen Frage, ob Du 'einfach' vom End-Point ins PC 
schreiben kannst, leider nein. Du schreibst ohnehin nie zum CPU sondern 
der MEM Schreib- oder Lesezugriff von Deinem End-Point wird vom Chipset 
(z.B. Intel ICH, I/O Controller Host) abgefangen und ins Systemspeicher 
umgeleitet.

Nächster Punkt, es muss vorher ein Zielbereich im System Speicher 
gelockt werden (sonst kriegs't einen schönen Blue Screen o.ä). Hier gibt 
es verscheiden Ansätze. Hängt z.B. davon ab, ob Applikations (User Mode) 
SW auch auf die Adressen zugreifen soll/darf oder nicht. So oder so 
(User Mode oder Kernel mode only) muss dann die sog. Scatter/Gather 
List, die den Zielbereich im Speicher beschreibt, an Dein DMA Controller 
übermittelt werden. Dein HW kann dann diese Adressen verwenden.

Wenn Du Windows im Sinn hast, würde ich der umfangreiche WDK (Windows 
Driver Kit) von der MS Webseite holen und ein sog. KMDF (Kernel Mode 
Driver Framework) Treiber schreiben. Es gibt einige Beispiele auch für 
PCI.

Wenn Du Linux im Sinn hast, ist m.E. die Information leider recht 
verteilt. Ein guter Startpunkt ist der Rubini Buch, "Linux Devce 
Drivers". Es gibt sogar irgendwo eine Online version (google, wikipedia 
etc.).

Die Grundkonzepte zwischen Win und Linux sind recht ähnlich.

Zusammengefasst: Wenn Dein End-Point ein DMA Master sein will, brauchst 
Du leider unbedingt einen Gerätetreiber. Ich denke bis das Fundament 
steht hast Du schon so ca. 500 'C'-Codezeilen zu schreiben. Das Testen 
kann nervig sein, vor allem unter MS.

Bzgl. des Durchsatzes ohne DMA. Das geht nur wenn die CPU auf Deine 
Karte schreibt. Hier wirdst Du kaum über 2,5 MByte (typ. Response Zeit 
von 1.6 us für ein DWord) beim Lesen bzw. 10 MB beim Schreiben kommen 
(schneller weil keine Completions).

Viel Erfolg,
Charles

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Charles,

also erstmal zum Gerätetreiber:
Da nutze ich zur Zeit halt den Jungo Treiber, der auch DMA kann. Das 
Dumme ist nur, dass Altera sowohl von der Hardware als auch vo nder 
software her keinen Quelltext für die DMA Beispiele zur Verfügung stellt 
bzw. gibt es für das einzige offene VHDL Beispiel keine spezielle 
Software die mit dem Beispiel zurechtkommt.

Es ist so, dass ich das ganze für meine Diplomarbeit brauche. Bisher 
habe ich wie gesagt den PCIe Core am laufen, kann auch Daten schreiben 
(Memory Write Request) und Lesen (Memory Read Request + Completion). 
Dabei komme ich tatsächlich auf geschwindigkeiten im niedrigen MB/s 
Bereich.

Die Sache ist die, dass ich für den Treiber eigentlich gar nicht 
zuständig sein sollte, das sollte ein anderer Diplomand machen. 
Allerdings ist der noch nicht verfügbar. Die Anwendung soll im Endeffekt 
utner Linux laufen.

Da ich aber im Endeffekt mit der Geschichte weniger zu tun haben 
sollte/wollte, habe ich unter windows den Jungo Treiber verwendet, auf 
dem basieren auch die Altera Beispiele und man brauchte helt nicht viel 
machen und er lief out-of-the-Box mit einigen Beispielen (dummerweise 
kein offenes DMA Beispiel).
Linux soll ja im prinzip vom Treiberschreiben einfacher sein. Da gibt es 
auch einen OpenSource Treiber von einem anderen User, der aber nicht 
vollständig ist. Könnte ich aber zur Not drauf aufbauen.

Zum DMA:
Das mit den Adressbereichen und dem freigeben ist mir schon klar, kann 
ja nicht einfach mal eben irgendwelche wichtigen/benutzten 
Speicherbereiche platt machen. Bluescreen ich komme! Meine Frage 
diesbezügliche wäre ja, ob und wie ich die Bereiche für externe Zugriffe 
freigeben könnte.

Ich habe das mit dem DMA bisher so verstanden: Ich schieb dem FPGA Infos 
in sein Register (Quell Adresse, Ziel Adresse, Länge, etc.) und sag ihm 
er soll den Transfer starten. Und er überträgt dann die Daten als Memory 
Write Request mit der entsprechenden PC Adresse die Daten an den PC.

Mein Problem ist, dass ich mir gerne den ganzen Kram an DMA Logik im 
FPGA sparen würde (sofern möglich) da ich nur in Richtung PC senden 
möchte, und das auch "nur" 4MB und auch nicht in zerstückelte 
Speicherbereiche sondern am Stück. Vier Wochen wären kein Problem ^^

Meine Frage ist halt, ob/wie ich den Speicherbereich am PC freigeben 
könnte, ob der Ansatz so funktioniert (also im Endeffekt nur Daten vom 
FPGA aus an die Speicherbereiche am PC schicken, die Bereiche hab ich 
dem FPGA natürlich vorher mitgeteilt) und welche Geschwindigkeit dabei 
zu erzielen ist.


Ich hab mit mit dem "Software" Logic-Analyzer halt das angesehen, was 
das DMA Beispiel im DMA Transfer macht, und das war nur TLPs (Memory 
Write Req) senden.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich glaube Du haust da zwei Sachen drucheinander,
wenn dein PCIe Core einen Memorywrite initiert IST das ein DMA. Da 
beisst sich Maus keinen Faden ab.

Ich glaube wo Du dich vor fürchtest ist Scatter/Gather sprich eine Liste 
von (4kB) Blöcken abzuarbeiten, welche Dir der Treiber zur Verfügung 
stellen muss...

Scatter/Gather ist sicherlich guter Stil, jedoch nicht unbedingt 
notwendig. Wenn Du einen Treiber baust der Dir bei Systemstart einen 
entsprechend grossen Speicherbereich alozierst, dann bekommst Du den (im 
Normalfall) auch am Stück zur Verfügung gestellt.

Du musst Dir dann noch die physikalische Adresse zu deinem 
Speicherbereich geben lassen, dafür gibt es Betriebsystemfunktionen.

Der rest läuft dann wie Du schon gesagt hast, über einfache Writes.
Die zu erzielende Geschwindigkeit ist dabei höher als bei 
Scatter/Gather, da Dir du keine Zeit zum Übertragen von Tabellen 
benötigst.

Gruß

Andreas

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi KDC,

mir ist immer noch nicht ganz klar wie Eure gesamte Arbeit ausschauen 
soll. Kommt dann noch eine Applikation SW dazu, die die Daten irgendwie 
visualisieren/auswerten soll oder was macht Ihr damit.

Denn, normalerweise wird der Datenverkehr immer von einer 
Applikation-SW, auch natürlich Demon, Dienst o.ä, eingeleitet. Dein 
Hardware kann von sich aus eigentlich nur über Interrupts eine 
Betriebssystem aktivität auslösen aber da wird es richtig aufwendig. 
Falls Dein HW Daten im Speicher sozusagen auf Vorrat halten soll, dann 
wird in der Regel ein Treiber vorher einen Speicherbereich reservieren 
(z.b. kmalloc) und die Adresse von diesem Puffer in die HW schreiben.

Das Gesamtsystem würde aber eher so ausschauen.
Eine Applikations-SW (auch Demon natürlich) hat z.B.
fH = open("/dev/irgendwas", PARAMS);
BytesRead = read(fH, buf, sizeof(buf));

Das System weiss welcher Treiber sich hinter "/dev/irgendwas" verbirgt. 
Dein Treiber hat einen Callback vereinbart der vom System aufgerufen 
wird als Folge des 'read' Befehls oben. Als Parameter bekommt er einen 
Zeiger auf 'buf', einen Puffer im User Space.

Der Treiber reserviert dann normalerweise Kernelspeicher (kmalloc) und 
übergibt diese Adresse an Dein HW. Wenn der HW signalisiert hat, dass er 
fertig ist (Interrupt, Polling eines Status Regs etc. etc.) kopiert der 
Kernel die Daten nach '*buf' mit copy_to_user() und der read() Befehl 
wird abgeschlossen.


Was ich zeigen will ist, ein DMA Treiber ist alles andere als trivial. 
Meine persönliche Meinung ist, wenn der Treiber eh von einem Komilitonen 
geschrieben werden soll und Dein Thema eigentlich der HW ist, 
konzentriere Dich doch lieber auf einer vernünftigen Simulation für Dein 
Konzept. Die Altera Umgebung ist doch diesbzgl. gar nicht so schlecht. 
Die gewünschte Übertragungsrate wirdst Du auf jeden Fall im Zielsystem 
erreichen. Mit DMA kommst Du problemlos in Richtung 100 MByte vielleicht 
sogar bis hinauf zu ca. 180 MByte oder so (x1 PCIe). Letzendlich muss 
nur der Treiber Dein HW schnell genug mit Zieladressen versorgen.

Ein Vorschlag für Dein DMA Controller wäre ein 64bit x N 
Zieladressen-FIFO, der vom Treiber periodisch gefüllt wird. 64 Bit weil 
48 Bit Start-Adresse (IA64 Hardware) + Grösse des Zielbereichs. Du 
spezifizierst dann Deinen Komilitonen was die maximale Bereichsgrösse 
ist, die Du bearbeiten kannst (z.B. 32 KByte oder 64 KByte). Dein 
Controller holt sich dann sequentiell Ziel-Deskriptoren aus diesem FIFO 
und beschreibt sie mit posted PCIe Pakete. Du brauchst natürlich auch 
ein Signalisierungsmechanismus wenn ein Bereich abgeschlossen ist 
(Interrupt, Register Polling, Stempel an eine andere Speicheradresse etc 
etc.)

Nochmals, viel Erfolg
Charles

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke ihr beiden!

Das hat mir schon einiges gebracht, in dem es mich im Endeffekt 
bestätigt hat, dass meine grundsätzliche Idee nicht ganz bescheuert war 
;)

Die Anwendung gibt im Endeffekt gelegentlich (natürlich von einer 
Software gesteuert) Befehle an eine Logik, die damit einen Testchip 
beschaltet. Irgendwann ist der Punkt erreicht, wo der Speicher im 
Testchip ausgelesen werden soll. Das sind maximal 4 MB.

Daher reicht es mir im Endeffekt, Daten als normalen Memory Write 
Request an das FPGA zu schicken, und halt nach einiger Zeit(dann aber 
halt auch möglichst schnell) die Daten aus dem Chip Speicher zu lesen.

Wie gesagt, der Rest funktioniert soweit ganz gut, ich würde jetzt halt 
nur gerne den Abtransport der Daten realisieren. Dazu nochmal meine 
überlegungen:
1. PC reserviert Speicher.
2. PC Teilt FPGA die Adresse des reservierten Speichers mit
3. FPGA sendet die Daten (sofern PCIe Core sagt es sei Ready) 
hintereinander weg an die (natürlich mit Inkrementierung) erhaltene 
Speicheradresse
4. Wenn das FPGA fertig ist sendet es eine MSI mit Interrupt an den PC
5. Wenn der PC den Interrupt empfängt (alternativ Polling) holt die 
Software sich die Daten und wertet sie aus/speichert sie in eine Datei

Das war im Prinzip so, wie ich es mir vorgestellt hatte, und wie ihr es 
auch beschrieben habt, oder?

Dann noch zwei kurze Fragen dazu:
1. Wie groß können die reservierten Speicherbereiche sein?
2. Wenn ich es z. B. mit kmalloc mache, habe ich dann die tatsächliche 
physikalische Adresse? Oder wie komme ich da dran? Und der Chipsatz/PCIe 
Bus kann einfach in den Speicherbereich schreiben auch wenn ich ihn (in 
der anwendung) reserviert habe? Reservierung ist also nur für das 
Betriebsystem?


Zum Thema Simulieren: Ja, von Altera gibt es da Simulationswerkzeuge, 
wobei mir eigentlich der praktische Test immer lieber ist (zumindest bei 
so einer Anwendung).

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi KDC,

Deine Punkt 1) bis 5) sind so in Ordnung. Nur nebenbei, MSI ist aus PCIe 
sicht kein Interrupt sondern ein Memory Write an eine vom System 
vorgegebene Adresse. Der 1 DWord Payload wird, bis auf den unteren acht 
Bits (der Vektor), auch vom System vorgegeben. Noch ein Punkt: 
Windows-XP (und früher) kann kein MSI. Ach ja noch ein Punkt, wenn Dir 
PCIe Kompatibilität im Sinne der Spec. ein Anliegen ist, musst Du auch 
Legacy Interrupts (INTA bis INTD Messages) unterstützen, wenn Du 
Interrupts implementierst. Das System 'entscheidet' dann welches Du 
benutzen darfst und trägt das in die Konfiguration Space ein.

kmalloc() reserviert physischen Speicher und zwar bis zu einer maximalen 
Größe von ca. 128 KByte (ja, Kilo). Für größere Bereiche gibt's 
vmalloc() aber dann musst Du (genauer gesagt Dein Treiber Kollege) 
letzendlich eine Scatter/Gather Liste der physischen Adressen anfordern 
und dies dann an den FPGA übertragen. vmalloc() bekommt einen virtuellen 
Speicherbereich. Ich denke, wenn Du ein S/G-Listen FIFO in Deinem DMA 
Kanal implementierst, bist Du hier sehr flexibel auch gegen späteren 
Änderungen im Treiber Konzept. Der Treiber muss Dein HW nur mit Adressen 
versorgen. Es ist dann egal, ob der Treiber mit einem grossem 
(virtuellen) Puffer, mit Wechsel Puffer oder noch was arbeitet. Dein HW 
arbeitet natürlich mit physischen Adressen.

Das mit dem Simulieren verstehe ich. Auch ich sehe natürlich lieber 
persönlich nach, ob etwas 'blinkt und rappelt' nur ab einer gewissen 
System Komplexität ist das leider nicht mehr effektiv. Vor allen die 
Fehleranalyse kann uferlos sein. M.E. hast Du diese Komplexitätsschwelle 
schon überschritten. Ich würde wenigstens zweigleisig fahren.

Grüße,
Charles

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das MSI kein Interrupt ist war mri schon klar, gibt je keine weiteren 
Signalleitungen sondern geht alles über die eine tx Leitung, somit muss 
das ja quasi ein normales Datenpaket mit speziellem Inhalt sein. Aber 
danke nochmal für den Hinweise.

Genauso dass XP kein MSI kann, hatte ich irgendwo schon gelesen, aber 
wieder verdrängt.

Ich bin grad dabei mich mal ein wenig mit Linux auseinander zu setzen. 
Es gibt ja dieses Buch aus dem O'Reilly Verlag welches kostenlos als pdf 
zur Verfügung steht über Linux Treiber.

Da steht übrigens drinne, dass mit free_pages (oder so) und order=9 
irgendwas um die größenordnung 512kB möglich sein soll. Bei so großen 
Bereichen muss man ja aber sicherlich drauf aufpassen, ob die wirklich 
allociert werden können wenn sie am Stück zur Verfügung stehen müssen.

Da gehts dann vielleicht, wie du ja auch vorschlägst, Richtung 
Scatter/Gather. Muss ich mir mal ansehen.

Und nochmal zur Simulation:

Ich hab bisher nur einmal diesen Altera BFM verwendet und ein Beispiel 
zu testen. Ist das wirklich viel effizienter das darüber zu machen als 
mit SignalTap sich einfach z.B. den Datenverkehr und einige andere 
Signale anzusehen? Wie gesagt, Simulieren habe ich bisher 
vernachlässigt, nur um einzelne Logik Blöcke zu testen habe ich das 
benützt.

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Fragen sind so heute beim lesen noch aufgetaucht:

1. Wie bekomme ich unter Windows nen zusammenhängenden physikalischen 
Adressbereich und dessen Adresse?
2. Kann ich per Memory Write Request ohne sonstige Einstellungen in den 
Speicher schreiben (vom FGPA aus) oder muss ich am PC dafür noch 
irgendwas vorbereiten? (ausser Bereich freigeben)
3. Wenn ich am PC in den Speicherbereich vom PCIe Board schreibe(also z. 
B. das erste Byte von Bar0) wird dass dann vom Root Complex automatisch 
in ein TLP umgewandelt oder muss ich da selber aktiv werden.

Ich glaub das wars. Windows deswegen, weil ich da halt mit Windriver von 
Jungo nen einfaches Toolkit habe, womit ich auch schon kleine 
Testsoftware geschrieben habe und was für mich, der sich eigentlich 
nicht um die Treiberseite kümmern soll, wesentlich simpler und 
unaufwendiger ist. Die dritte frage richtet sich aber doch eher an 
Linux, damit hab ich heute rumgespielt, aber leider kein Modul geladen 
bekommen :/

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi KDC,

mit den 512 KB wäre ich tatsächlich vorsichtig. Ich kenne nur die 
Angabe, dass kmalloc() bis 128 KByte spezifiziert ist. Kann schon sein, 
dass neuere Kernel Versionen diese Zahl noch mal erweitert haben. Habe 
ich mich ehrlich gesagt nicht drum gekümmert. Ich verwende meistens 
vmalloc(). Wenn kmalloc() nicht die gewünschte Anzahl zurückliefern 
kann, liefert er meines Wissens keine (retcode = 0).

Als Vergleich, unter Windows habe ich mal in einen Treiber ein Tracer 
eingebaut, der die Größe der einzelnen S/G-List Elementen ausgegeben 
hat. Gleich nach dem Laden habe ich 4 mal 20 MByte angefordert (für 4 
DMA Kanäle). Ich habe nie gesehen, dass ein S/G Element größer als 3 
Seiten (3 x 4K Byte) war. Ich bin noch nicht dazu gekommen, die Messung 
unter Linux zu wiederholen.

Bzgl. der Simulation, das Problem mit dem SignalTap ist, dass Du nur ein 
oder wenige Übertragungen anschauen kannst. Mit der Simulation, kannst 
Du z.B. eine ganze Regression Sequenz übers Wochenenende laufen lassen.

Es ist eine Weile her seitdem ich mir das Altera BFM angeschaut habe. 
Damals zumindest war es auf verilog bassiert, sah aber sehr vernünftig 
aus. Ich hoffe, dass Dein Simulator mixed language (VHDL/Verilog) kann.

Grüße,
Charles

Autor: Christian Leber (ijuz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@KDC
2.) ohne IOMMU nicht, also generell nicht
3.) ja

Passend fuer die Anwendung ist
pci_alloc_consistent
wenn man frueh nach dem booten alloziiert bekommt man auf jeden Fall 2 
MB.

Bei entsprechender Fragmentierung bekommt man aber nicht mehr als 4kB.
(bzw. eine page)

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke euch beiden für die Antworten! Wobei ich mir jetzt bei Frage drei 
nicht sicher bin mit deiner Antwort. Ich mach sowas auch, aber auf 
"oder-Fragen" mit ja antworten ist immer etwas unglücklich ;) aber ich 
nehme mal an du meinst er macht daraus automatisch nen TLP (sonst 
hättest du ja evtl. noch mehr dazu geschrieben).

Wie gesagt, danke euch allen, das einzige was ich leider immer noch ned 
wei ist, wie ich bei Windows an freien physikalischen Speicher kommen. 
Aber das lässt sich ja hoffentlich rausfinden.

KDC

Autor: Christian Leber (ijuz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@KDC
Ja, hab die Frage nicht ganz gelesen, wird natuerlich automatisch 
umgewandelt.

BTW. ich wuerde an deiner Stelle den Treiber selbst schreiben und auch 
etwas testcode, denn Du weisst nicht wielange es dauert bis der andere 
Diplomand mit seinem Zeug voran kommt.
Mach daraus einfach noch ein Kapitel in deiner DA.

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi KDC,

wie Du unter Windows an physischen Speicher kommst ist aus dem Stand 
nicht so einfach.
Aus dem User Mode (d.h. Borland, VisualXxx usw.) geht das überhaupt 
nicht. Windows versucht verzweiflet den unbedarften vor sich selbst zu 
schützen. Am Anfang hast Du erwähnt, Du würdest mit Jungo arbeiten. 
Falls Jungo die Einbindung von Funktionen aus der Windows WDK erlaubt, 
würde ich versuchen Speicher in der gewünschten Größe aus dem Kernel 
non-paged Pool anzufordern. Aber 4 MByte ist schon ziemlich Richtung 
Obergrenze für Speicher Blöcke, die aus dem Pool angefordert werden 
sollten.

Der Aufruf wäre ExAllocatePoolWithTag(type, nbytes, tag)
  type : NonPagedPool
  tag  : Ein Bezeichner, wenn ich mich recht errinnere, max 6 Zeichen 
und
         vermutlich auch noch als UNICODE string. Ich muesste 
nachschauen.

Rückgabe Wert ist ein Pointer auf eine Virtuelle Adresse. Du kannst
MmGetPhysicalAddress(PVOID baseAddr) verwenden um die physische Adresse 
zu bekommen.

Nachdem ich das gesagt habe, muss ich leider auch gleich sagen, 
Microsoft weisst darauf hin, dass diese Methode nicht für DMA verwendet 
werden soll. Ich habe es nur erwähnt, weil es zusammen mit Jungo 
funktionieren könnte (nie probiert, habe kein Jungo).

Wenn man es 'richtig' machen will, wird es wirklich kompliziert. Vergiss 
nícht, ich habe schon am Anfang von ca. vier Wochen gesprochen. Wenn Du 
wirklich ein eigener Bonsai Treiber schreiben willst, damit Du z.B. den 
TLP Inhalt in einem  Borland/VisualXxx Program sehen möchtest, hast Du 
einiges vor Dir.
Als erstes, WDK und SDK von der Microsoft Seite laden. Da ist die ganze 
Docu drin und viele viele Beispiele.

1) Für Dein Treiber (hier empfehle ich dringendst das KMDF Treiber Model 
(s. WDK), alles andere ist viel zu kompilziert) brauchst Du einen 
Registry Eintrag, damit Deine Applikations SW es überhaupt finden kann. 
Hierzu brauchst Du einen sog. GUID (globally unique Id). Die wird mit 
GENGUID.exe aus der SDK generiert. Den String hieraus kommt als 
'#DEFINE' in Deinen Treiber, Deine Applikation SW und Deine *.INF Datei

Dein Treiber wird übrigens immer mit dem WDK C-Compiler in einem DOS Box 
übersetzt. VisualStudio usw. kann das nicht.

2) In der Applikations Software (Borland/VisualXxx) verwendest Du
SetupDiGetClassDevs()
SetupDiEnumDeviceInterfaces()
SetupDiGetDeviceInterfaceDetail()

um einen Handle zu Deinem Treiber aufzubauen. (s. Beispiel in der SDK)

3) Mit
CreateFile()
ReadFile(drvHandle, buf,....)
kannst Du dann Daten von Deinem Treiber abholen.

---------------
Nun zum Treiber:
1) genauso wie unter Linux musst Du letzendlich einige Callbacks 
vereinbaren. Vor allem,
DriverEntry()
EVT_WDF_DRIVER_DEVICE_ADD
EVT_WDF_DEVICE_PREPARE_HARDWARE

In Deiner EVT_WDF_DEVICE_PREPARE_HARDWARE erfährst Du, wie Deine PCI 
Base Address Register gemapped sind

2) Mindestens ein IO-Queue Anlegen. Das Betribssystem leitet Deine 
ReadFile() Aufrufe hierhin. Die KMDF bietet dann einige Aufrufe um Queue 
Einträge abzuholen. Oder genauer, KMDF ruft Deine Callbacks auf, wenn 
Queue Einträge vorhanden sind.

3) Aus Deinem Queue Eintrag (IRP, I/O Request Packet in Windows Jargon) 
musst Du nun Zugang zum 'buf' aus Deinem ReadFile bekommen (am besten 
den sog. DMA_DIRECT Methode verwenden. Auch hier s. KMDF Docu)
Mit
WdfDmaTransactionInitializeUsingRequest(..CallbackFuerDma()...)
WdfRequestRetrieveOutputBuffer()
wird im Wesentlichen Deine DMA Übertragung gestartet.

Deine Routine CallbackFuerDma(), bekommt dann die Scatter/Gather Liste 
zu Deinem 'buf' im User Space vom System mitgeteilt und diese Adressen 
schreibst Du in Dein Hardware.

4) Mit WdfRequestComplete() wird das ganze abgeschlossen.

Das hier sind eigentlich nur als Stichwörter/Orientierungspunkte gemeint 
für Dein Studium der WDK Beispielen. Es lässt sich wirklich nicht 
umfassend auf nur einer HTML Seite beschreiben. Ab besten, den PLX 9x5x 
bzw. pcidrv Beispiele aus der WDK anschauen. Rechne, wie gesagt, mit 
einigen hundert Code Zeilen, viele Blue Screens und natürlich vier 
Wochen.

Grüße,
Charles

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cfgardiner schrieb:
> Rechne, wie gesagt, mit
> einigen hundert Code Zeilen, viele Blue Screens und natürlich vier
> Wochen.

Nicht zu vergessen das Serial oder FireWire Kabel sowie ein 2. Rechner 
für den Kernel-Debugger :)

Autor: cfgardiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Christian,

ach für einen Bonsai Treiber braucht man das alles eigentlich nicht, 
auch wenn es MS vorschreibt. Klar man kommt vielleicht damit etwas 
schneller ans Ziel. Sofern man sich z.B. mit dem ganzen PnP Zeug nicht 
auseinander setzen muss, kann man schon darauf verzichten.

Wen ich z.B. für einen Demo oder auch kleineres Projekt o.ä einen 
Treiber schreibe, mache ich immer nur folgendes:
- Compilere mit Debug
- Verify aktivieren
- Nach einem Reboot, Crash Mini-Dumps mit WinDbg analysieren.

Die angemeckerte Zeilen sind meistens in der Nähe vom tatsächlichen 
Fehler, zumindest sofern man mit dem KMDF Model gearbeitet hat.

Klar, alles Abwägung.

Grüße,
Charles

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich seh schon, zumindest nen komplett eigener Treiber droht mir überden 
Kopf zu wachsen. Bei Linux bekomme ich nicht mal ein Modul 
compiliert/geladen und an Windows will ich lieber gar nicht denken ;-)

Nunja, der Jungo Treiber hat eine funktion um Speicher für DMA zu 
reservieren, allerdings weiß ich nicht ob die für meine Zwecke 
funktioniert, das werde ich dann mal als nächstes testen.

Dann habe ich gehört, dass es hier im Haus auch schon ne 
treiberentwicklung gab, für eben dieses Board aber eine anderen 
Anwendung. Da bin ich auch dran mit den Code mal zu besorgen. Ansonsten 
muss doch Linux herhalten.

Ich schau mal was sich machen läßt.

Autor: KDC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So,

ich wollte mich nochmal bei allen bedanken, die mir geholfen haben.
Bin zwar was den DMA Teil angeht noch nicht fertig, aber das Prinzip 
funktioniert soweit super!

Und um noch ein bisschen Wissen beizusteuern:

mit __get_free_pages(GFP_KERNEL, 10) läßt sich unter Linux im Treiber 
ein zusammenhängender Speicher von 4 MB reservieren. Der aktuelle Kernel 
kann meines Wissens auch noch order (ist das zweite Argument, 2^n * 4kB) 
11, also 8 MB.

GFP_KERNEL geht in meinem Falle, da mein PCI (Express) Board 64 bit 
Adressen verwalten kann, falls das nicht geht muss man es um __GFP_DMA 
ergänzen, damit ist bei mir aber dann die zweite oder dritte Allozierung 
schief gegangen.

So, wie gesagt, vielen Dank euch allen nochmal!

KDC

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.