Hallo, ich habe die MMU und die Caches für meinen ARM926ej-s eingerichtet. Es läuft mit write-through wunderbar, doch sobald ich write-back für programmcode und daten einschalte passiert nur noch mist. Es wird keine kontext-umschaltung vorgenommen und speicherbereiche auf die per DMA zugegriffen wird (EMAC) sind vom write-back ausgeschlossen und laufen mit write-through. Hat jemand eine Idee, was ich übersehen haben könnte? Grüße Daniel
Daniel G. schrieb: > ich habe die MMU und die Caches für meinen ARM926ej-s eingerichtet. Es > läuft mit write-through wunderbar, doch sobald ich write-back für > programmcode und daten einschalte passiert nur noch mist. Wann schaltest Du write-back denn ein? Vor oder nach dem Laden des images? Liegen Code/Daten im TCM? Diese sollten idealerweise non-cacheable markiert sein. Gruß Marcus http://www.doulos.com/arm/
MMU und DCache wird erst nach dem Image-laden eingeschaltet und konfiguriert. TCM wird nicht benutzt. Vielleicht hilfts: es ist ein AT91SAM9260.
Hallo Daniel, ich habe selber schon für dem AT91SAM9263 programmiert mit MMU, CACHES und DMA. Soweit ich mich erinnere, mußte der Speicher der für DMA verwendet wird, komplett "non-cachable" und somit auch ohne "write-through" sein. Vielleicht hilft Dir das weiter. Gruß Microman
Hi Microman, DMA bereich ist not cached and not buffered. Irgendwo muss ich doch was übersehen haben. Ich habe eine 'round-robin with interrupts' architektur. Ich hoffe es hat noch jemand eine Idee. Grüße Daniel
Daniel G. schrieb:
> DMA bereich ist not cached and not buffered.
Habe ganz oben Quatsch geschrieben. Der Speicherbereich in dem die
EMAC-Buffer und Descriptoren liegen sind wirklich nicht cached und nicht
buffered, also ist auch kein write-through an.
Daniel G. schrieb: > Habe ganz oben Quatsch geschrieben. Der Speicherbereich in dem die > EMAC-Buffer und Descriptoren liegen sind wirklich nicht cached und nicht > buffered, also ist auch kein write-through an. Der Speicher weiß nicht ob er cached oder buffered oder beides ist. Es ist daher ziemlich egal wie der nun konfiguriert wurde, vorausgesetzt die Kommunikation zwischen Core und externem Master funktioniert richtig. Wenn das Einschalten des WB zu Problemen führt, dann liegt das eben daran, dass der Prozessor denkt, er hätte was in den Speicher geschrieben, während das tatsächlich nicht der Fall ist. An geeigneten Stellen muss man dann eine cache clean Operation ausführen (siehe TRM des ARM926EJ-S). Gruß Marcus http://www.doulos.com/arm/
Marcus Harnisch schrieb: > Der Speicher weiß nicht ob er cached oder buffered oder beides ist. Aber möglicherweise CPU+Cache? Ich kenne diesen ARM nicht, aber oft sind Caches für verschiedene Adressbereiche unterschiedlich eingestellt oder konfigurierbar. Der Adressbereich eines solchen typischerweise per DMA angesprochenen RAMs wäre dann als non-cachable definiert, sei es implizit, sei es per expliziter Konfiguration. Aufräumen vom Cache wäre dann unnötig. Eine Variante dazu findet sich schon bei einem ARM9 ohne Cache aber mit Puffern, bei dem sich das normale RAM gleich dreimal im Adressraum befindet, mit unterschiedlichen Eigenschaften was Pufferung angeht.
A. K. schrieb: > Ich kenne diesen ARM nicht, aber oft sind Caches für verschiedene > Adressbereiche unterschiedlich eingestellt oder konfigurierbar. Genau. Das wird hier über die MMU page tables gemacht. > Der Adressbereich eines solchen typischerweise per DMA > angesprochenen RAMs wäre dann als non-cachable definiert, sei es > implizit, sei es per expliziter Konfiguration. Aufräumen vom Cache > wäre dann unnötig. Wird auch oft so gemacht. Allerdings gibt es durchaus Situationen, in denen ich bei meinen DMA-transferierten Daten die Geschwindigkeitsvorteile eines Caches ausnutzen möchte. Es ist nur so, dass niemand außer dem Core etwas davon weiß. Die Aussage `mußte der Speicher der für DMA verwendet wird, komplett "non-cachable" und somit auch ohne "write-through" sein' las sich, als ob der DMA controller irgendwie voraussetzen würde, dass der Speicher auf irgendeine spezielle Art und Weise konfiguriert wäre. Das ist nicht der Fall. > Eine Variante dazu findet sich schon bei einem ARM9 ohne Cache aber > mit Puffern, bei dem sich das normale RAM gleich dreimal im > Adressraum befindet, mit unterschiedlichen Eigenschaften was > Pufferung angeht. ?? Das muss dann aber herstellerspezifisch sein. ARM966E-S/968E-S haben genau einen write-buffer, der aber bei jeder passenden und unpassenden Gelegenheit automatisch rausgeschrieben wird. Gruß Marcus http://www.doulos.com/arm/
Marcus Harnisch schrieb:
> ?? Das muss dann aber herstellerspezifisch sein.
ARM966E-S im STR9.
Es gibt 2 Buffer, einen im D-TCM, einen im AHB-Interface. Eines der
beiden Interfaces hat 2 gespiegelte Adressbereiche mit unterschiedlichen
Eigenschaften und das RAM ist sowohl über D-TCM als auch über AHB
ansprechbar.
Interessant finde ich, dass sich sowohl das ST-Manual als auch der dafür
eigentlich prädestinierte Hitex-Guide sorgfältig um die Frage
herummogeln, wozu das gut ist und was man besser wie macht. Wenn man
sowas nicht schon aus anderer Quelle kennt steht man dumm da.
Marcus Harnisch schrieb:
> ?? Das muss dann aber herstellerspezifisch sein.
Nö. Hab nochmal nachgesehen. Ist eine generelle Eigenschaft vom
ARM966E-S. Den AHB gibt's jeweils gespiegelt buffered und unbuffered und
im D-TCM ist natürlich auch noch ein Buffer.
Eieiei. Jetzt sind wir schon wieder off-topic :-) A. K. schrieb: > Es gibt 2 Buffer, einen im D-TCM, einen im AHB-Interface. Eines der > beiden Interfaces hat 2 gespiegelte Adressbereiche mit unterschiedlichen > Eigenschaften und das RAM ist sowohl über D-TCM als auch über AHB > ansprechbar. Ich bin mir absolut sicher, dass der D-TCM des ARM966E-S keinen write buffer enthält. [gerade mal ins STR9 manual geschaut] Das ist herstellerspezifisch! Man hat die TCMs offenbar an verschiedenen Stellen in den Adressraum eingeblendet. > Interessant finde ich, dass sich sowohl das ST-Manual als auch der dafür > eigentlich prädestinierte Hitex-Guide sorgfältig um die Frage > herummogeln, wozu das gut ist und was man besser wie macht. Du kannst den RAM Speicher offenbar sowohl als TCM oder als AHB RAM benutzen. Das habe ich auch mal so implementiert. Dabei muss man aber an der ARM966E-S macrocell (unter Verlust jeglicher Garantieansprüche) herumpfuschen. Das kann abhängig von der Anwendung aus folgenden Gründen gut sein: 1. Einheitlicher Adressbereich für alle Komponenten. Das RAM wird auch von der CPU nur über AHB angesprochen. Wahlweise buffered oder unbuffered. Da man keine MPU/MMU hat sind Adressaliase die einzige Möglichkeit, das Verhalten zu konfigurieren. 2. Ein Master (z.B. DMA controller) kann dem Prozessor die Daten sozusagen von hinten reinstecken (AHB ausgelastet), während der bereits elegant über sein eigenes TCM interface auf den schon geschriebenen Daten arbeitet. Dazu ist natürlich ein dual-port RAM nötig. Gruß Marcus http://www.doulos.com/arm/
Marcus Harnisch schrieb: > Ich bin mir absolut sicher, dass der D-TCM des ARM966E-S keinen write > buffer enthält. Ähm... Aus dem Manual vom ARM966E-S von ARM: "To minimize the occurrence of stall cycles and to decouple the processor from memory wait states, there are write buffers in the DTCM and ITCM interfaces." > Das ist herstellerspezifisch! Man hat die TCMs offenbar an > verschiedenen Stellen in den Adressraum eingeblendet. Die TCMs nicht, deren Adressbereiche sind vom Core festgelegt. Aber das am D-TCM hängende RAM taucht zusätzlich via AHB auf, mit einem Busarbiter dazwischen. Yep, das könnte herstellerspezifisch sein. Aber daraus stellt sich mir die Frage, wie man beim ARM966E Systemen per DMA auf das RAM zugreift, wenn es sich nicht im AHB-Adressraum befindet? > Das kann abhängig von der Anwendung aus folgenden Gründen gut sein: Sicher. Aber ich stelle mir bei solcher Lektüre ab und zu mal einen Umsteiger von AVRs vor, der sich als nächste Leitersprosse sowas auserkoren hat.
A. K. schrieb: > Ähm... Aus dem Manual vom ARM966E-S von ARM: Stimmt. Rev 2 hat einen. Habe nicht gesehen, dass STR9 den enthält. Der WB des TCM ist aber für Software nicht sichtbar, da der Prozessor die einzige Komponente ist die den Write Buffer sieht, und der Write Buffer Read-After-Write-Hazards selbständig auflöst. Wenn da beim STR9 noch ein AHB interface ranbastelt, dann muss man eben sehen wie man das löst. Dieses Problem hatte ich seinerzeit zum Glück noch nicht :-) Gruß Marcus http://www.doulos.com/arm/
Marcus Harnisch schrieb: > Der WB des TCM ist aber für Software nicht sichtbar, da der Prozessor die > einzige Komponente ist die den Write Buffer sieht, Das ist genau der gleiche Effekt wie ein im Thread vorher erwähnter Write-Cache, nur kurzlebiger. Wenn man, ähnlich dem was du oben skizzierst, der Effizienz halber per D-TCM auch auf jene Bereiche vom RAM zugreift, die per DMA verwendet werden. Denn das DMA sieht den Buffer im D-TCM nicht, daher wär's schon besser, wenn nichts für DMA wichtiges drinsteht. Folglich ist es einfacher, aber langsamer, auf DMA-Bereiche im RAM auch seitens des Prozessors nicht über das TCM sondern nur über die AHB-Spiegeladresse zuzugreifen, was ungefähr einem Zugriff auf einen non-cachable Adressbereich entspricht. Und damit sind wird wieder on-topic.
A. K. schrieb: > Folglich ist es einfacher, aber langsamer, auf DMA-Bereiche im RAM auch > seitens des Prozessors nicht über das TCM sondern nur über die > AHB-Spiegeladresse zuzugreifen, was ungefähr einem Zugriff auf einen > non-cachable Adressbereich entspricht. Und damit sind wird wieder > on-topic. Nein. Das obige gilt unter Umständen für den STR9 -- der ist aber dem OP vermutlich völlig egal. Da man dem DMA controller ohnehin irgendwie mitteilen muss, wann er anfangen kann, lässt sich dort (wie bereits um 09:18 gesagt) auch noch eine geeignete cache clean Operation unterbringen. Die Nutzung der Daten im core entscheidet, ob eine Speicher Region sinvollerweise cacheable ist oder nicht. Der DMA Zugriff ist dann sekundär. Wir sollten vielleicht mal wieder den OP zu Worte kommen lassen. Gruß Marcus http://www.doulos.com/arm/
Ich kann es mir bislang nur so erklären, dass ich einfach einen DMA Zugriff übersehen habe und diese Daten auch noch in die non cached, non buffered region verschieben muss. Bisher sind dort nur die EMAC buffers und descriptors untergebracht. Ich werde morgen noch mal alles im MCU TRM durchgehen und mich wieder melden. Grüße, Daniel
Bin nochmal durch das AT91SAM9260 manual gegangen, konnte aber nichts finden was neben der EMAC per DMA zugreift. Wie gesagt, RX/TX buffer und RX/TX desriptoren sind in nicht cached, nicht buffered region. Wo soll ich noch suchen?
Daniel G. schrieb: > Bin nochmal durch das AT91SAM9260 manual gegangen, konnte aber nichts > finden was neben der EMAC per DMA zugreift. Wie gesagt, RX/TX buffer und > RX/TX desriptoren sind in nicht cached, nicht buffered region. > > Wo soll ich noch suchen? Am besten wäre mal eine Fehlerbeschreibung die etwas mehr hergibt als "es passiert nur noch Mist". Bekommst Du data aborts, /prefetch aborts/, oder "nur" falsche Daten? Kannst Du nachvollziehen, ob es sich um ein Kohärenzproblem handelt? Einfach mal alle Pages auf WT schalten und nacheinander auf WB wechseln. Schauen was passiert. Vielleicht wird der Fehler auch indirekt, durch verändertes Programm Timing, hervorgerufen. Gruß Marcus http://www.doulos.com/arm/
Hallo, das Problem hat sich gelöst nur leider weiß ich nicht warum es vorher überhaupt aufgetreten ist. Hatte es nochmal versucht und es ging... Nun läuft code und data sowie der Stack mit der write-back policy. Schade nur, dass das Umschalten von WT zu WB kaum einen Geschwindigkeitsvoretil bringt. Danke für die Hilfe! Schöne Grüße und allen frohe Festtage! Daniel
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.