Anfängerfrage MMU ARM

[heinz (Gast)]

Hallo,

ich spiel mit einem Raspberry rum und versuch mich jetzt an der MMU

was ich will ist ein identity mapping mit 1 MB Sections

Versteh ich das richtig dass ich dann nur die Basetable brauch (also 
keine Subpages)

Kommt in die Basetable Bit 31 .. 20 die physikalische Adresse auf die 
gemappt wird?

Gruss Heinz

[Sascha (Gast)]

Hallo Heinz,
so in etwa ja, also die Physicalische Adresse, die Domaine und noch ein 
paar Attribut. Ist nur der Eintrag in die Tabelle da 1MB die Größte 
Section sein dürfte. Bei kleinerer Unterteilung gibts dann eine weitere 
Tabelle.Also Tabelle von der Tabelle usw.
Achtung: Wird die Tabelle aktualisiert müssen die Caches geleert werden, 
die MMU abgeschaltet werden, MMU-Caches geleert und neu eingeschalten 
werden. Sonst gibts Probleme da im Cache noch etwas anderes über den 
Speicherbereich steht. Die MMU verwaltet ja auch die Cache Attribute.

Ich habe das ganze mal vor ca. 2 Jahren auf einem ARM9 gemacht.

Gruß Sascha

[heinz (Gast)]

Hallo Sascha,

mir gings eigentlich nur um den Cache, der funktioniert ja ohne MMU 
nicht.

Hab das jetzt auch mal runterprogrammiert und funktioniert auch, aber 
noch nicht ausgetestet.

Ich hab jetzt eine Base Translationtable ohne Coarsepages also auch ohne 
Tables. Mir ging es auch um den Speicher so brauch ich halt "nur" 16 KB

Gruss Heinz

[Marcus H. (mharnisch)]

Sascha schrieb:
> Achtung: Wird die Tabelle aktualisiert müssen die Caches geleert werden,
> die MMU abgeschaltet werden, MMU-Caches geleert und neu eingeschalten
> werden. Sonst gibts Probleme da im Cache noch etwas anderes über den
> Speicherbereich steht. Die MMU verwaltet ja auch die Cache Attribute.

Beim ARM11 (ARMv6) muss man im Gegensatz zum ARM9 ohnehin die Caches und 
TLB invalidieren bevor man sie erstmalig verwendet.

Hier geht es anscheinend um eine statische Initialisierung bevor Caches 
und MMU überhaupt in Betrieb genommen werden, sodass man sich im 
laufenden Betrieb darüber keine Gedanken mehr machen muss.

Solange lediglich die Adresszuordnung dynamisch verändert werden 
(gleiche Attribute) müssen die D/I Caches beim ARM11 (ARMv6) ebenfalls 
nicht geleert werden, da hier VIPT Caches zum Einsatz kommen. Ein TLB 
flush ist dennoch fällig.

Gruß
Marcus

[Sascha (Gast)]

Hallo,
super man lernt immer noch was dazu.
PS. genau so habe ich es auch gehalten MMU ja, aber nur damit man in den 
genus der Caches kommt. Übrigens kann man die Caches auch bei 
Register(Hardware) und statischem Speicher abschalten (bringt dort 
relativ wenig).
Gruß Sascha

[heinz (Gast)]

Hallo zusammen,

ich hab immer noch ziemliche Probleme mit dem Verständnis der MMU

  base = (uint32_t*) 0;


// pinmod  
  base[GPFSEL1] &= ~(7<<18);
  base[GPFSEL1] |= 1<<18;

// set timer
  base[C1] = base[CLO] + 0x080000;
  base[CS] = 2;

// set irq controller
  base[0x2000B210 /4] = 0x0;
  base[0x2000B20C /4] = 0x80|1;

// 512 MB RAM cachable
  for (i=0;i<512;i++){
     MMUTBL[i] = i<<20 | 0x0C0E;
  }

// rest shared device
  for (i=512;i<4096;i++){
     MMUTBL[i] = i<<20 | 0x0C06;
//10987654321098765432109876543210     
//                   0110000000110
//             0000TEXapP dom0CB10
     
  }
    
  start_mmu(MMUTBL);
  start_l1cache();
//  enable_fiq();




while(1){
  base[GPCLR0] = 1<<16; // LED off
  tmp=0;
  while (tmp<1000000){
    tmp++;
  }
  
  base[GPSET0] = 1<<16; // LED on
  tmp=0;
  while (tmp<1000000){
    tmp++;
  }
};

So läuft das Programm wie es soll - die LED toggelt

Jetzt versuch ich die LED in einem IRQ Handler zu Toggeln

void c_irq_handler ( )
{
  static uint32_t t=0, i;
  asm("push {r0,r1,r2,r3,r4,r5,r6,r7,lr}");

  base[C1] = base[CLO] + 1000000;
  if (t){
    t=0;
    base[GPSET0] = 1<<16;
  }
  else{
    t=1;
//GotoXY(1,160);
//DrawString((uint8_t*)"1"); 
    base[GPCLR0] = 1<<16;
  }

  base[CS] = 2;
  asm ("pop  {r0,r1,r2,r3,r4,r5,r6,r7,lr}");
  asm ("subs pc,lr,#4");
}

das funktioniert wenn ich die Zeile
  start_l1cache();
auskommentiere. Also kein Cache

Mit Cache bleibt die LED aus

Kommentar vor dem Print weg füllt sich mein Bildschirm mit Einsen

Also versuch ich es in Assembler

s_irq_handler:
push {r0,r1,r2,r3,r4,r5,r6,r7,lr}

ldr r9,=0x20003004
ldr r10,[r9]
add r10,#999424
ldr r9,=0x20003010
str r10,[r9]

cmp r12,#0
mov r9,#0x10000
ldrne r10,=0x2020001C
ldreq r10,=0x20200028
str r9,[r10]
moveq r12,#1
movne r12,#0

ldr r9,=0x20003000
mov r10,#2
str r10,[r9]

pop  {r0,r1,r2,r3,r4,r5,r6,r7,lr}
subs pc,lr,#4

Ergebniss
Die LED geht mal an und bleibt dann an oder sie leibt aus

Und jetzt weiss ich nicht mehr weiter. Wäre nett wenn mir jemand ein Tip 
gibt

Gruss
Heinz

[Marcus H. (mharnisch)]

heinz schrieb:
> das funktioniert wenn ich die Zeile
>   start_l1cache();
> auskommentiere. Also kein Cache

Hab keine Ahnung, was genau Du in der Funktion anstellst...
Hast Du den Cache invalidiert, oder schaltest Du ihn nur ein?

[heinz (Gast)]

Das sollte eigentlich sauber sei

.globl start_l1cache
start_l1cache:
    mov r0, #0
    mcr p15, 0, r0, c7, c7, 0 ;@ invalidate caches
    mcr p15, 0, r0, c8, c7, 0 ;@ invalidate tlb
    mrc p15, 0, r0, c1, c0, 0
    orr r0,r0,#0x1000 ;@ instruction
    orr r0,r0,#0x0004 ;@ data
    mcr p15, 0, r0, c1, c0, 0
    bx lr

Ich habe gedacht ich brauch vielleicht ein memory barrier, aber wieso 
sollte es dann funktionieren wenn ich eine Schleife in dar Main mache?

hätte ich schreiben sollen
wenn ich es mit dem Version IRQ probiere habe ich am Ende eine Schleife

while(1){};


hmm - Unterschied ist dass ich der ohne IRQ Version in der Main zig mal 
einen Zugriff auf den Speicher mache. Ich versuch morgen mal was 
passiert wenn ich in der IRQ Version in Schleife sinnlos eine Variable 
ändere

Gruss
Heinz

[Marcus H. (mharnisch)]

Also zumindest der TLB sollte vor dem Einschalten der MMU invalidiert 
werden. Eine ISB sollte dem Einschalten der MMU und der Caches folgen.

[heinz (Gast)]

.globl start_mmu
start_mmu:
    mov r2,#0
    mcr p15,0,r2,c7,c7,0 ;@ invalidate caches
    mcr p15,0,r2,c8,c7,0 ;@ invalidate tlb

    mov r2,#0x03
    mcr p15,0,r2,c3,c0,0 ;@ domain 0 = Manager

    mov r2,#0
    mcr p15, 0, r2, c2, c0, 2 ;@ 16k pagetable 
                              ;@ always use Translation Table Base Register 0.

    mcr p15,0,r0,c2,c0,0 ;@ tlb base
;@    mcr p15,0,r0,c2,c0,1 ;@ tlb base

    mrc p15,0,r2,c1,c0,0
    ldr r1,=0x000001     ;@ enanle mmu
    orr r2,r2,r1
    mcr p15,0,r2,c1,c0,0

    bx lr

Hab jetzt mal versucht den Speicher in der Schleife zu belasten - bringt 
auch nichts

>Eine ISB sollte dem Einschalten der MMU und der Caches folgen
Was ist eine ISB?

Gruss
Heinz

[heinz (Gast)]

Hab jetzt mal die IRQ Routine und die Endlosschleife geändert

void c_irq_handler ( )
{
  static uint32_t t=0;
  asm("push {r0,r1,r2,r3,r4,r5,r6,r7,lr}");
  
DrawString((uint8_t*)" "); 
DrawDec(t);
DrawString((uint8_t*)" "); 

  base[C1] = base[CLO] + 1000000;

  if (t){
    t=0;
    base[GPSET0] = 1<<16;
  }
  else{
    t=2;
    base[GPCLR0] = 1<<16;
  }

  base[CS] = 2;
  asm ("pop  {r0,r1,r2,r3,r4,r5,r6,r7,lr}");
  asm ("subs pc,lr,#4");
}

Schleife

while(1){
  tmp=0;
  while (tmp<1000000){
    tmp++;
  }
  DrawString((uint8_t*)"1"); 
};

Und was bekomm ich auf den Bildschirm
"11111111 0  2 11111111 0  2 1111111....." Einsen sind es mehr

Die blinkt also schon - nur ein bischen kurz

Gruss
Heinz

[Marcus H. (mharnisch)]

heinz schrieb:
>>Eine ISB sollte dem Einschalten der MMU und der Caches folgen
> Was ist eine ISB?

Instruction Synchronization Barrier. Stellt sicher, dass der nächste 
Befehl garantiert aus dem Speicher bzw Cache kommt und kein 
möglicherweise "veralteter" Opcode aus der Pipeline genommen wird.
DSB für den Daten Cache entsprechend auch.
Memory Barriers sind nach kontextverändernden Befehlen (context changing 
instructions) vorgeschrieben. Siehe ARM ARM.

Auch eine interessante Frage ist, ob die Inline Assembler Befehle der 
ISR garantiert an den entsprechenden Stellen eingefügt werden, oder ob 
der Compiler da noch mal "nachbessert".

[Sascha (Gast)]

Hallo,
ich habe das Problem auch bei einem CM4 mit dem Interrupt feststellen 
können. Wollte dort auch nur eine LED Togglen lassen. So und jetzt zu 
dem Problem. Es wird ein Read-Modify-Write Speicherzugriff über die 
I/O-Register ausgeführt. Lesen und Schreiben sind aber trotz deiner 
Assembler oder C Struktur im Arbeitsablauf richtig, werden aber duch die 
Unterstützung des Read und Write Cache nicht richtig ausgeführt, 
jedenfalls Zeitlich. Da brauchst du zwingend einen DSB Befehl. Alle 
IO-Register (Adressen) solltest du in der MMU-Tabelle als none-cachable 
und none-bufferable einstellen. Also keinen Cache und keinen 
Write-Buffer für I/O und Hardwareregister.

Gruß Sascha

[heinz (Gast)]

Okay kann ich mal einfügen.

Die Inline Befehle stehen an der richtigen Stelle (objdump)

Ich lass mir jetzt auch den Stand vom Counter 1 anzeigen und der zählt 
hoch.
Beim Wechsel von t=0 zu t=2 in fast Nullzeit

Ich brauch scheinbar in der IRQ Routine eine Memory Barriere. Broadcom 
sagt

"In order to keep the system complexity  low  and data throughput high, 
the BCM2835  AXI system does  not always return read data in-order"
.....

"You should place:
•  A memory write barrier before the first write to a peripheral.
•  A memory read barrier after the last read of a peripheral. "

Werde ich dann später mal versuchen

[heinz (Gast)]

Mal weiter probiert

Eine Data memory barrier bringt nichts
Datacache invalidieren und es funktioniert wie es soll

Für die Performance kann das ja wohl keine Lösung sein?

Ich bin davon aushehangen, dass wenn ich den Speicherbereich über 2 Gig 
(da ist die Peripherie eingeblendet) in der Translationbase Tabelle als 
nicht cachbar ausweise ein flush nicht nötig ist

Gruss
Heinz

[Sascha (Gast)]

Hallo Heinz,
ja Cache und Performanche ist für viele Anwendungen wie ein trojanisches 
Pferd.
Wenn man auf einem solchen Controller programme schreibt wie auf einem 
Mikrocontroller mit hochfrequenten Interrupts oder ständiges 
Contextswitching dann hat man in der Tat mit dem Cacheverwalten mehr 
Arbeit als manchmal Vorteile. Das habe ich auch schon auf meinem ARM9 
bemerkt. Diese Teile sind halt schon eher auf die Verarbeitung von 
Multimedia ausgelegt. Es gibt aber auch die Möglichkeit im Cache 
verschiedene Bereich fest einzulagern sozusagen verschiedenen 
Programmteilen zuzuweisen, wie dem Interruptsheduler oder 
Betriebssystem.

Gruß Sascha

[Marcus H. (mharnisch)]

heinz schrieb:
> Datacache invalidieren und es funktioniert wie es soll

Prima!

> Für die Performance kann das ja wohl keine Lösung sein?

Das machst Du doch in Deiner Anwendung nur einmal nach dem Reset. Beim 
Invalidieren im laufenden Betrieb kann man durchaus selektiv vorgehen 
und muss nicht den gesamten Inhalt verwerfen.

> Ich bin davon aushehangen, dass wenn ich den Speicherbereich über 2 Gig
> (da ist die Peripherie eingeblendet) in der Translationbase Tabelle als
> nicht cachbar ausweise ein flush nicht nötig ist

Ist er auch nicht. Aber Du hast ja noch andere Datenzugriffe im 
Programm.

[heinz (Gast)]

@Marcus Harnisch

Das hast Du falsch verstanden
Ich versuch im Timerinterupt (zum Testen 1 Hz) eine LED zu toggeln. 
Zugriff auf den entsprechenden Ausgang ist Memory Mapped 0x2020001C.

Ich sehe über eingetreute Prints dass meine IRQ Routine einmal nach 1 
Sekunde und dann sofort wieder "ohne" Zeitverzögerung aufgerufen wird

Die LED toggelt nur wenn ich jedesmal am Anfang der IRQ Routine den 
Daten Cache invalidiere.

  for (i=512;i<4096;i++){
     MMUTBL[i] = i<<20 | 0x0C06;
//10987654321098765432109876543210     
//                   0110000000110
//             0000TEXapP dom0CB10
     
  }

Jetzt habe ich meiner Meinung nach (auch) diesen Speicherbereich als 
shared Device deklariert.
0x0c06 = 0b110000000110
TEX = 000
B = 1
C = 0
AP = 11 sollte keine Rolle spielen weil domain 0 als Manager defieniert 
ist

Eigentlich sollte das also am Cache vorbeigehen. Wobei dann aber wieder 
die Aussage von Broadcom entgegen steht.

[heinz (Gast)]

Und weil das alles zu einfach war

void c_irq_handler ( )
{
  static volatile uint32_t t=0;
  asm("push {r0,r1,r2,r3,r4,r5,r6,r7,lr}");

  base[C1] = base[CLO] + 1000000;

  if (t){
    t=0;
    base[GPSET0] = 1<<16;
  }
  else{
    t=2;
    base[GPCLR0] = 1<<16;
  }

  base[CS] = 2;
  base[CS] = 2;

  asm ("pop  {r0,r1,r2,r3,r4,r5,r6,r7,lr}");
  asm ("subs pc,lr,#4");
}

so funktioniert es ohne Bariere oder Flush
man beachte die Zeile

  base[CS] = 2;

ist 2 mal vorhanden

Gruss
Heinz

[Marcus H. (mharnisch)]

heinz schrieb:
> Das hast Du falsch verstanden
>
> Die LED toggelt nur wenn ich jedesmal am Anfang der IRQ Routine den
> Daten Cache invalidiere.

Nee, hab ich nicht. Ich meinte nur, dass es nicht nötig sein sollte. 
Anscheinend haben Deine Probleme auch nichts mit dem Cache zu tun, 
sondern vermutlich mit irgendeinem kritischen timing. Statt dem Cache 
invalidate hättest Du auch eine Warteschleife ausführen können.

> Eigentlich sollte das also am Cache vorbeigehen. Wobei dann aber wieder
> die Aussage von Broadcom entgegen steht.

Die Aussage von Broadcom ist lediglich, dass die Ergebnisse von 
Lesezugriffen auf zwei unterschiedliche Peripheriebausteine in 
umgekehrter Reihenfolge zurückgegeben werden können. Das hat ebenfalls 
nichts mit Deinem Problem zu tun.

Das doppelte Schreiben ist natürlich auch nicht die Lösung sondern 
verdeckt nur das ursächliche Problem. Was ist denn "base[CS]" überhaupt?

[heinz (Gast)]

>Was ist denn "base[CS]" überhaupt?
Im Prinzip das EOI für den Timerbaustein

>zwei unterschiedliche Peripheriebausteine
Das ist halt die Frage wie man das interpretiert
Sind damit auch zwei unterschiedliche Adressen gemeint, dann könnte
base[C1] = base[CLO] + 1000000;
in die Hosen gehen

Näturlich mach ich irgendwo irgendwas falsch, wenn nicht hätte Broadcom 
ein riesen Problem (was nicht ist). Das Problem ist nur was.

Ablauf sollte ff. sein
Ich habe eine freilaufenden Timer CLO
Ich habe 4 "compare register" C1 .. C4
sind CLO und Cx gleich gibt es einen Interupt
CS = 2 macht den timecompare wieder scharf

Das letzte steht so nicht in der Doku von Broadcom und wird im Internet 
etwas  diskutiert.

Was seh ich:
ohne D cache funktionierts wie es soll
mit I cache funktionierts

mit D cache kommt mein IRQ nach 1 Sekunde und sofort im Anschluss noch 
einer. Besser gesagt meine IRQ Routine wird sofort nochmal durchlaufen. 
Wobei mein Register CLO um 1000000 inkrementiert ist.
CLO ist read only

Was falsch sein kann:
Ich kontrolliere nicht ob der IRQ überhaupt vom Timer C1 ausgelöst wird
Meine Serviceroutine wird über den FIQ getriggert. Steht eigentlich 
nirgendwo das das geht.

Werde ich morgen probieren

Gruss
Heinz

[Sascha (Gast)]

Hallo,
nach beendigen der Interrupts FIQ oder IRQ muss man auch aufpassen, das 
der Interrupt Controller den Interrupt als Ausgeführt (Terminiert) 
sieht.
Wird an dieser stelle keine Memory Data Barriere und Instruction 
Barriere eingebaut kann es folgenden Effekt haben. Der Interrupt wird 
zwar beendet, durch den Schreibcache und durch die Pipline wird die 
Terminierung ausherhalb der ISR-Routine gemacht. Somit gilt der 
Interrupt als nicht beendet das Pending-Flag bleibt weiter aktiv, und 
die ISR-Routine wird sofort erneut wieder angesprungen.
Ist bei den ARM Controllern ist das je nach Hersteller mal etwas besser 
oder weniger gut gelöst.

Gruß Sascha

[Marcus H. (mharnisch)]

heinz schrieb:
>>Was ist denn "base[CS]" überhaupt?
> Im Prinzip das EOI für den Timerbaustein

Das kommt wahrscheinlich zu spät. Man sollte das immer ganz zu Anfang 
der ISR erledigen. Merke: Trotz Memory Barriers gibt es kein absolut 
narrensicheres Verfahren das garantiert, dass die Schreibzugriffe vor 
Ende der ISR durchgeführt wurden. Ein DSB (DMB reicht nicht!) vor 
Verlassen der ISR hilft.

>>zwei unterschiedliche Peripheriebausteine
> Das ist halt die Frage wie man das interpretiert

Das kann man nur mit Kenntnis der Busmatrix. Typischerweise können die 
Daten unterschiedlicher Slaves am AXI Bus out-of-order zurückgegeben 
werden.

> Sind damit auch zwei unterschiedliche Adressen gemeint, dann könnte
> base[C1] = base[CLO] + 1000000;
> in die Hosen gehen

Wieso? Ich sehe maximal zwei Lesezugriffe, deren Reihenfolge egal ist. 
Wahrscheinlich nur einer, da die Konstante vom Compiler als immediate 
erzeugt wird.

> ohne D cache funktionierts wie es soll

Klar, weil alles (z.B. POP) länger dauert und das Interrupt Clear daher 
ausreichend schnell ist.

[heinz (Gast)]

Hallo,
ich habe heute leider sehr wenig Zeit gehabt.

>Somit gilt der Interrupt als nicht beendet das Pending-Flag bleibt weiter >aktiv

sieht so aus wie wenn das so wäre. Deshalb das doppelte (manchmal) 
ausführen der ISR

Ich werde mal das "Basic pending register" anschauen.

>Man sollte das immer ganz zu Anfang der ISR erledigen
was dann halt zu rekursiven Aufrufen führen kann.

>weil alles (z.B. POP) länger dauert
Ich habe das eigentlich so verstanden, dass der Schreibvorgang noch im 
Cache ist und ich die ISR schon verlassen habe?

Wieso werden die Lese/Schreibzugriffe überhaupt gecached - diese 
Adressen liegen in einem Bereich der in der Translationtabelle als 
nonbuffered,noncachable ausgewiesen sind?

und Danke für die Mühe die Ihr euch macht

Gruss
Heinz

[Marcus H. (mharnisch)]

heinz schrieb:
> Wieso werden die Lese/Schreibzugriffe überhaupt gecached - diese
> Adressen liegen in einem Bereich der in der Translationtabelle als
> nonbuffered,noncachable ausgewiesen sind?

Device memory ist buffered, d.h. die CPU wird durch Schreibzugriffe auf 
langsame Peripherie nicht aufgehalten. Das Lesen vom Device wird nicht 
vom  Cache bedient, wohl aber die Stackzugriffe, die dann schneller 
beendet sind als das Interrupt Clear.

[heinz (Gast)]

ok,ich denk ich habe es kapiert.

Danke nochmal und noch eine Frage

Ich finde im Internet
http://www.airspayce.com/mikem/bcm2835/

// safe write to peripheral
void bcm2835_peri_write(volatile uint32_t* paddr, uint32_t value)
{
  if (debug)
    {
  printf("bcm2835_peri_write paddr %08X, value %08X\n", (unsigned) paddr, value);
    }
  else
    {
  // Make sure we don't rely on the first write, which may get
  // lost if the previous access was to a different peripheral.
  *paddr = value;
  *paddr = value;
    }
}

was bei mir
base[CS] = 2;
base[CS] = 2;
ist.

    88d0:  e59f2030   ldr  r2, [pc, #48]  ; 8908
    88d4:  e3a01002   mov  r1, #2
    88d8:  e7831002   str  r1, [r3, r2]
    88dc:  e7831002   str  r1, [r3, r2]

"zwingt" das den Prozessor den Store auszuführen, oder ist das Timing 
einfach so kritisch das der zusätzliche Store ausreicht

Mit einer DSB vor dem pop gibt es immer noch sporatisch doppelte 
Ausführung der ISR, während es mit dem doppelten Store selbst ohne DSB 
stabil läuft.

Gruss
Heinz

[Marcus H. (mharnisch)]

heinz schrieb:
>   // Make sure we don't rely on the first write, which may get
>   // lost if the previous access was to a different peripheral.
>   *paddr = value;
>   *paddr = value;

Das scheint eine Eigenart des SoC zu sein. Falls das Device an einem 
APB(us) hängt hinge eine mögliche Erklärung damit zusammen, dass dessen 
Busprotokoll (APBv2) keine Waitstates kennt. Das Slave Interface muss 
dann die Daten abnehmen und damit dem Prozessor das Ende des Buszyklus 
signalisieren, bevor sie im eigentlichen Register landen. Keine memory 
barrier kann in so einem Fall helfen. Daher meine frühere Bemerkung, 
dass es kein universelles, absolut sicheres Verfahren geben kann.
Es kann sich ganz schlicht auch um eine Schwäche der verwendeten 
Busmatrix handeln. Das weiß nur Broadcom. Solange es irgenwo 
dokumentiert ist kann man damit wohl ganz gut leben.

[heinz (Gast)]

Ok, damit kann ich leben,
Ich sag nochmal herzlich Danke an die, die mir geholfen haben

Gruss
Heinz