Memory Management - Nepetalactone/LightOS GitHub Wiki

Externe Links

Übertragungstabellen

  • Virtuell vs. physisch
  • Berechtigungen
  • Ermöglichen caching und buffering

TLB (Translation Lookaside Buffer)

TLB gibt es pro Speicherschnittstelle sowie Caches Speicher für Pagetable Überlegungen: Werden Daten und Instruktionen separat abgespeichert Einträge im TLB: C und B bits; Berechtigung // Swapping

Wird kein Cache verwendet, dann wird die physische Adresse für den Speicherzugriff verwendet

Übersetzungsprozess

Sections (1MB groß) --> für große zusammenhängende Speicherbereiche sinnvoll Pages (1KB, 4KB oder 64KB groß)

Hirarchie

  • First Level Tables --> sections
  • Second Level Tables --> large, small and [tiny] pages

#Fetch Modes

  • Section based --> nur First Level fetch
  • Page based --> First- und Second Level fetch TLB Base Register (CP 15 Reg2) hält den First Level Table in den Bits [31:14] // siehe ARM 3.3.1

Zugriffsschutz

// siehe ARM 3.4 AP (Access Permission), S(ystem) und R(OM) bit

Domains

Domains sind Kollektionen von Sektionen / Pages. Davon gibt es maximal 16 Stück. Rollen

  • Manager (kontrolliert Clients(s))
  • Clients z. B. für einfache Prozessverwaltung mit bis zu 16 Prozessen

Ausnahmen (Interrupts, Exceptions)

  • Prefetch Abort Exception bei MMU Fault oder Externem Abbruch (Informationen zum Fehler gib es im FAR und FSR)

Memory Protection Unit

  • kein virtual to physical mapping
  • einfacher als MMU an sich
  • keine Übersetzungstabellen

Protection Regions

  • können überlappen (höchster Schutz wird genommen)

Enablen: gleich wie MMU // siehe ARM 4.1.3

Zugriffsreihenfolge

Wenn eine Adresse nicht in einer geschützten Region liegt, dann wird der Speicherzugriff abgebrochen.

Cache

  • L2 Cache wird vollkommen in der HW gemanagete
  • Daten-Cache wird von der HW indiziert

Konfigurationsauswahl

Welche Konfiguration verwenden wir für LightOS?

  • Demand-Paging einfacher!
  • Regions (Sections) -- um nicht ganzen Speicher in Pagetable haben zu müssen (in kleinem Programm)
  • 4k pages
  • ca. 1-2GB virt. Speicher nutzen
  • Alignment (fine -> 4k, coarse -> 1k)
  • kein Fast Context Switch (besser ASID)

Fixe Übersetzung

  • Kernel
  • PageTables
  • I/O
  • Scheduler
  • lock bit, um Einträge im TLB zu belassen!!!

Kontextswitch

  • Pointer auf Pagetable
  • Pagetable einrichten
  • L1 Pagetable entry in register auf Prozess anpassen
  • ASID wird automatisch im TLB mit abgelegt CP15, c13 ASID eintragen nG=0 // not Global (nur für Prozess) möglicherweise zwei verschiedene Einträge mit selber Adresse (jedoch unterschiedliche ASID)
  • TTBR0: Prozess-spezifisch
  • TTBR1: für OS und IO (memory mapped) belassen
  • TTBCR N-Bit für Trennung TTBR0/TTBR1 (Slide 55, Speicher_Virtuell_Arm_1) N darf Wert von 0-7 (von 32 bit Addressraum) annehmen; d. h. bei N= 7 2^25 Bytes für Prozess-­‐spezifischen Bereich

Beispiel os aus "arm-system-developers-guide"

Kapitel 11

fixe Regionen für OS Code etc.

  1. kernel
  2. shared memory (shared libraries, Übergangsroutinen von privileged 2 user mode)
  3. table
  4. peripheral (kein caching etc.)
  5. interrupts (vector table und stack)

Virtuelle Memory Maps für jeden Task

  1. text
  2. data
  3. stack of task (ACHTUNG: muss beim Kontext Switch angepasst werden)

Physischen Speicherbereich auswählen

Page Tables definieren

Structs für PageTable und RegionData definieren

Initialize the MMU

Context Switch testen

Turn the MMU on

http://www.embedded-bits.co.uk/2011/mmucode/

  1. System Mode enable
  2. System Control Processor ==> Bit0 von Register 1 (0 = reset; 1 = on)
  3. CP15 Register müssenkonfiguriert bzw. programmiert werden (ACHTUNG: Code, der die MMU steuert, muss virtuell und physisch im selben Speicherbereich liegen.) // siehe ARM 3.7

ToDo -- nach Einlagern Page Table updaten (wo, valid,..)