mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM926ej-s DCache write-back fehler


Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MMU und DCache wird erst nach dem Image-laden eingeschaltet und 
konfiguriert. TCM wird nicht benutzt. Vielleicht hilfts: es ist ein 
AT91SAM9260.

Autor: Microman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Daniel G. (motello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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]
  • [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.