|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > OS4 und Zorro III DMA | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
03.01.2008, 09:36 Uhr mboehmer Posts: 350 Nutzer |
So, eine Frage an die Experten: es geht um Zorro III DMA auf dem A4000 unter Amiga OS4 Classic. (REMARK: ich bitte um Zurückhaltung und sachliche Diskussion, auch wenn ich an späterer Stelle MOS und OS4 vergleichen muss. Danke im Voraus, liebe Trolle.) Nachdem bislang keiner der Experten bei Hyperion meine Anfragen beantwortet hat, probier ich es hier mal, vielleicht weiß jemand was. Mein Problem dreht sich um die neue USB2 Karte Deneb, die (auch) im DMA-Modus betrieben werden kann. Das ganze funktioniert bestens unter OS3.x auf dem A4000T, es gibt ein Testprogramm, das DMA-Transfers aus der Karte und vice versa durchführt. DMA funktioniert in alle Speicherbereiche (also ChipRAM, Motherboard FastRAM, Turbokarten RAM); als Turbokarte kommt (wie erwartet) eine CSPPC zum Einsatz. Im Testprogramm werden die DMA-Transfers wie üblich mit CachePreDMA() und CachePostDMA() behandelt; diese Funktionen liefern unter OS3.x normalerweise die physikalisch zu verwendende Adresse eines Speicherbereichs zurück, und kümmern sich um die entsprechenden Cache Flushs im Prozessor. Unter OS4.x schauts aber auf einmal ganz anders aus: beide Funktionen liefern, unabhängig von den Parametern, stets 0x00000000 zurück, was für mich heisst: kein DMA möglich. Showconfig liefert leider keinerlei Informationen über die Adressen des Speichers im System mehr unter OS4, wie es unter OS3.x noch der Fall war. Was mich jetzt verwundert: - einzige bekanntermassen funktionierende DMA-Hardware unter OS4 ist der CSPPC SCSI-Kontroller - alle anderen SCSI-Kontroller mit ZIII DMA (A4091, Fastlane, A4000T internal SCSI) werden nicht unterstützt - als Bemerkung in der Compatibility List steht: "kein DMA in Speicher der CSPPC möglich" - unter MOS laufen diese Kontroller aber Also: sind die CachePreCMA() und CachePostDMA() Funktionen unter OS4 momentan broken, oder handelt es sich um ein prinzipielles Problem? Zweiteres scheint nicht so, denn MOS benutzt ebenfalls den PPC, und dort gehts ja... Was mich stutzig macht: alle DMA-Erweiterungen, die *nicht* auf der CSPPC sitzen, gehen offiziell nicht. Über Hilfe und Infos wäre ich dankbar. Und bevor spekuliert wird: die Deneb läuft unter OS4 Classic im PIO Modus wunderbarst mit Poseidon V3.x, also keine Panik :-) Michael [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 09:53 Uhr MaikG Posts: 5172 Nutzer |
>- als Bemerkung in der Compatibility List steht: "kein DMA in >Speicher der CSPPC möglich" Das hat jemand in einem anderen Threat halbwegs beschrieben. So wie ich das verstanden habe: Beim nativen cybppc.device werden ständig daten per Prozessor umgeschaufelt. Es steht kein SCSI experte zur Verfügung der dem SCSI-Chip beibringen kann die Daten an verschiedenen stellen abzulegen - was bei OS4 aber wohl nötig ist. Nun ist der SCSI-Chip jedoch auf der CSPPC. Wenn man bei OS4 überhaupt einen zusammenhängenden Speicher bekommen will muss man MEMF_PUBLIC benutzen. Dann hat OS4 auch keine übereinstimmenden Adressen, also ein AllocVec der als start $8100000 zurückgibt liegt wohl nicht wirklich Physisch(für die Hardware) an dieser Adresse. Direkt zu den Funktionen kann ich nichts sagen, die kenne ich nicht... [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 12:29 Uhr tboeckel Posts: 124 Nutzer |
Zitat: Broken nicht unbedingt, aber obsolete. Durch die neue virtuelle Speicherverwaltung sind nicht nur physikalische und virtuelle Adresse nicht mehr unbedingt gleich, sondern der physikalische Speicher kann auch aus mehreren Blöcken bestehen. Das müssen DMA-fähige Treiber beachten. CachePreDMA() kann aber diesen Sachverhalt nicht passend "rüberbringen": code:With release 50, CachePreDMA/CachePostDMA is considered obsolete. Instead, StartDMA/EndDMA should be used. Due to the virtualized address space of AmigaOS 4, device drivers doing DMA *MUST* use either CachePreDMA/CachePostDMA or StartDMA/EndDMA, *and* be prepared for segmented transfers. StartDMA(), EndDMA() und GetDMAList() wurden dafür implementiert. Dafür wird aber das neue SDK benötigt, was leider immer noch nicht öffentlich ist. "obsolete" heißt aber nicht zwangläufig auch "geht gar nicht mehr". Ich denke mal, daß die virtuelle Adresse, die du angibst, mehrere physikalische Blöcke umfaßt, weswegen CachePreDMA() dann einen Fehler zurückgibt, weil es einfach nicht funktionieren kann. Unter OS3 waren die physikalischen Blöcke halt immer zusammenhängend, unter OS4 nicht mehr. Es könnte also höchstens der erste Block verwendet werden, von dem man ohne GetDMAList() aber nicht mal weiß wie groß er überhaupt ist. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 12:45 Uhr TetiSoft Posts: 197 Nutzer |
Zitat:Nach der Veröffentlichung von OS4Classic wurde noch ein Bug in den DMA-Funktionen gefunden, wenn ich mich recht erinnere schlägt er zu wenn der Puffer mehr als eine MMU-Page (4k) umfaßt. Zitat:Es basiert auf dem OS3 Quellcode und liefert zusätzliche Informationen (PCI-Boards, PPC-CPU), ich verstehe nicht was fehlen sollte. Zitat:Der Treiber alloziert einen eigenen DMA-Puffer und kopiert die Daten um. Der Bug in den DMA-Routinen scheint da nicht zuzuschlagen. Zitat:Wir nahmen an daß die Treiber selbst wenn sie die exec-DMA-Funktionen verwenden ggf wegen der unterschiedlichen CPU-Cacheline-Größe oder der MMU-pagesize-Größe nicht laufen. Zitat:Bei Zorro-Karten? Das sollte nur bei PCI-Karten da stehen. Bitte ggf. präzisieren damit das korrigiert werden kann. Zitat:Die Funktionen sind momentan defekt. Ob alte 68k DMA-Treiber mit der PPC cachelinesize und pagesize mit gefixten Funktionen laufen können oder nicht ist wohl derzeit nicht bekannt. Weiteres demnächst per PM. Zitat: Schick :-) [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 12:49 Uhr TetiSoft Posts: 197 Nutzer |
Zitat: Wenn ich mich recht erinnere ist MEMF_PUBLIC nicht dasselbe wie MEMF_CONTINUOUS (oder so ähnlich), bei MEMF_PUBLIC ist nur garantiert daß der Speicher öffentlich lesbar/schreibbar ist und nicht ausgelagert werden kann, aber nicht daß er an einem Stück ist. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 16:03 Uhr MaikG Posts: 5172 Nutzer |
>Wenn ich mich recht erinnere ist MEMF_PUBLIC nicht dasselbe wie >MEMF_CONTINUOUS (oder so ähnlich), Den Flag kenne ich nicht, wenn dann ist der neu. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 16:55 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG: Stimmt, ist erst im nächsten SDK. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 18:36 Uhr mboehmer Posts: 350 Nutzer |
Zitat: Nun, das ist schon mal eine Aussage - leider heisst das aber auch, dass 68k Treiber fuer OS3.x unter OS4 nicht ohne Neuanpassung laufen werden, wenn DMA im Spiel ist? Wann darf man denn als Hardwarehersteller damit rechnen, Zugriff auf das SDK zu erhalten? Von Hyperion bekomme ich momentan keinerlei Antworten. Zitat: Zersplitterte DMA-Bereiche sind für meine Deneb prinzipiell zwar keine Problem, aber werden in Sachen Performance natürlich nicht unbedingt einen Schub nach Vorne bringen. Im Endeffekt muss ich dann einen grossen DMA-Transfer in viele kleine aufteilen, mit dem jeweiligen Overhead vor und nach dem DMA-Transfer. Mal sehen, wann Hyperion antwortet. Michael [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 18:41 Uhr mboehmer Posts: 350 Nutzer |
Zitat: Unter OS3.x bekomme ich alle Memory-Segmente angezeigt (also: ChipRAM, onboard FastRAM, RAM in der CSPPC). Unter OS4 ist nur noch der ChipRAM-Block gelistet, das Motherboard FastRAM ist weg (da nicht nutzbar), und das RAM der CSPPC wird ebenfalls nicht mehr angezeigt. Zitat: Also Elbox-mässig? Erst mal DMA per SCSI-Chip, dann Polling per CPU? Zitat: Ist mit einer Anpassung dieser Treiber denn zu rechnen? Speziell A4000T onboard wäre nicht uninteressant. Zitat: PCI-Karten könnten das eigentlich auch, da sie über eine Zorro-Bridge eingebunden werden. Wenn diese PCI-DMA auf Zorro III DMA umsetzen *würde*, müsste das auch tun. Zitat: Gerne. Michael [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 18:43 Uhr MaikG Posts: 5172 Nutzer |
>Nun, das ist schon mal eine Aussage - leider heisst das aber auch, >dass 68k Treiber fuer OS3.x unter OS4 nicht ohne Neuanpassung laufen >werden, wenn DMA im Spiel ist? Viele HW Treiber gehen nicht. Bei der X-Surf braucht man ein Spezielles device. Subway auf X-Surf (<3) geht nicht auf V3 und A1200MB wohl schon. Auf der X-Surf geht hingegen die Hypercom3+. Die Toccata geht, die VLAB-Motion nicht. Ist nun schwer zu sagen welcher Treiber nun DMA verwendet und welcher nicht. >Wann darf man denn als Hardwarehersteller damit rechnen, Zugriff >auf das SDK zu erhalten? Ist doch frei verfügbar. ftp://ftp.hyperion-entertainment.biz/AmigaOS4_SDK/SDK_51.22-nocontrib.lha >Also Elbox-mässig? Erst mal DMA per SCSI-Chip, dann Polling per CPU? Ja. Das tolle daran ist unter OS4 Classic hat man etwa mit 70 MB/s zugriff auf das Ram. Wie sich das auf die SCSI Geschwindigkeit auswirkt ist klar... [ Dieser Beitrag wurde von MaikG am 03.01.2008 um 18:47 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 19:10 Uhr Blackbird Posts: 634 Nutzer |
Zitat: argl... wo habt ihr immer eure Infos her ?   -- regards Blackbird Have a look at: http://www.blackbird-net.de Skins for PlayCD OS3.9 BlackShoot, Zombies Apocalypse, GalagaWars, VcdImager-Gui,PerfectPaint [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2008, 19:25 Uhr ZeroG Posts: 1487 Nutzer |
@MaikG:Zitat:Es gibt nur eine Hand voll DMA-fähiger Zorrokarten und die dürften Herr Böhmer bekannt sein. Kann die Karte kein DMA kanns der Treiber auch nicht. Die X-Surf/VLAB Sache hat nicht wirklich was mit dem Thema dieses Threads (DMA) zu tun, da liegt der Hase woanders im Pfeffer. Mach dazu bitte ein neues Thema auf wenn du das nochmal beleuchten willst. Zitat:Das ist das letzte öffendlich SDK in der minimal Ausführung, für die entwicklung von DMA-Treibern braucht man zugriff auf das neue (unveröffendlichte / noch in Arbeit) SDK das die benötigten Funktionen und Definitionen für DMA-Zugriffe und durchgängige Realspeicherbereiche zugänglich macht (AllocVecTags(), MEMF_CONTINUOUS, usw.). @Blackbird: Man kann so einiges an Infos aufschnappen wenn man regelmäßig auf AmigaWorld.net / Amigans.net die Developer-Foren mitliest. Auf UtilityBase.com sind so gut wie alle OS4 Entwicker angemeldet und das Umfeld ist auch danach, da gibt es oft interressante Kommentare aus erster Hand zu lesen. Ist ja nicht das erste mal das jemand fragen zu DMA unter OS4 stellt... [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2008, 22:29 Uhr mboehmer Posts: 350 Nutzer |
Hallo ZeroG,Zitat: Nicht nur das, die wichtigsten dieser Karten liegen mir auch zum Testen der diversen Busterfeatures in realiter vor. Zitat: Hm. Wenn ein DMA-Treiber unter OS3.x und OS4 im JIT laufen soll, ohne den Programmierer zum Neukompilieren zu zwingen, dann wird hoffentlich die Speicherverwaltung von OS4 so schlau sein, einen mit MEMF_PUBLIC angeforderten Bereich im Speicher auch nach Möglichkeit als real linearen Bereich zu liefern. Das betrifft im speziellen AllocVec(). Bei USB haben wir es leider nicht in der Hand, da der USB-Treiber z.B. den Pufferspeicher fuer eine DMA-Übertragung eines MSD von extern bekommt, üblicherweise mit MEMF_PUBLIC angefordert. Ich habe grade einige Tests mit CachePreDMA() und AllocVec() durchgeführt. Und das deutet auf ein Problemchen hin, das DMA in der jetzigen Version von OS4 nahezu nutzlos macht: CachePreDMA() kann nur mit Blöcken kleiner 4kB umgehen, alle größeren Speicherblöcke liefern konstant NULL als Länge des linearen Speichers im Block. Meines Wissens unterstützt kein Zorro III DMA-Gerät bisher Scattered / Gathered DMA Transfers, bei dem in einem DMA-Zyklus Daten aus der Zorro III Karte in mehrere reale Speicherblöcke transferiert werden, die (MMU gemappt) für den Treiber einen linearen Bereich ergeben. Selbst wenn ein Update diesen Bug in CachePreDMA() erledigt, habe ich die Befürchtung, dass mit AllocVec() allozierter Speicher in relativ kleinen Blöcken (4kB) linear ist, und ein größerer DMA-Transfer (bei USB2 mehrere 10kB) entweder unnötig mit Overhead belastet wird (pro 4kB Block einmal DMA Engine Setup, CachePreDMA(), Interrupt, CachePostDMA()) oder die Zorro III Karte Scattered / Gathered DMA Transfers mit entsprechend vielen Blockregistern beherrschen muss. Zitat: Wenn ich die Zeit hätte, alle Amiga-Foren im Netz zu lesen und aufmerksam mitzuverfolgen, ja... Zitat: Ja, wenn du jetzt auch noch einen Link auf einen Thread in einem deiner anderen Foren gesetzt hättest, der mir einige Infos liefert, wäre das natürlich fein gewesen. Vielleicht kannst du das ja nachholen? @tboeckel: CachePreDMA() ist eigentlich nicht obselete. Der Aufruf liefert einem ja die notwendigen Infos, bei einem nichtlinearen Speicherblock muss man halt per Hand rekursiv die einzelnen Blöcke rauspfriemeln und entsprechend handeln. Michael [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > OS4 und Zorro III DMA | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|