Overwegingen voor geheugen en latentie beheren

Artikel
08/09/2023

In dit onderwerp worden basisoverwegingen voor geheugengebruik en latentie beschreven voor realtime-toepassingen die worden uitgevoerd op de MT3620-chip.

Opmerking

Zie de gepubliceerde MT3620-gegevensblad van MediaTek voor meer informatie over geheugenconfiguratie of DMA. als er nog vragen zijn, kunt u het 'MT3620 M4-gegevensblad' van Avnet aanvragen door een e-mail te sturen naar Azure.Sphere@avnet.com.

Geheugenindeling op de realtime kernen

De volgende tabel bevat een overzicht van het geheugen dat beschikbaar is voor de realtime kernen:

Geheugentype	Basisadres
TCM	0x00100000
XIP-flash	0x10000000
SYSRAM	0x22000000

Elke realtime kern heeft 192 kB aan nauw gekoppeld geheugen (TCM), dat is toegewezen in drie banken van 64 kB vanaf 0x00100000. TCM-toegang is snel, maar alleen de realtime kern heeft toegang tot het geheugen. TCM kan niet worden gedeeld met een toepassing op hoog niveau of met een realtime compatibele toepassing (RTApp) die op een andere kern wordt uitgevoerd.

Elke realtime kern heeft ook 64 KB AAN SYSRAM, dat wordt toegewezen vanaf 0x22000000. De DMA-controller kan zich ook richten op SYSRAM, zodat randapparatuur er toegang toe heeft. Toegang tot SYSRAM vanuit de realtime kern is langzamer dan toegang tot TCM. Net als bij TCM kan SYSRAM niet worden gedeeld met een andere toepassing.

XIP-flashgeheugen (Execute-in-place) wordt gedeeld met toepassingen op hoog niveau. Een venster in de XIP-toewijzing van de flitser is zichtbaar voor elke kern op het adres 0x10000000. Het besturingssysteem configureert de XIP-toewijzing voordat de toepassing wordt gestart als het ELF-bestand van de toepassing een segment bevat met de volgende eigenschappen:

Het laadadres (zoals opgegeven in de kolom VirtAddr van de programmakoptekst) is gelijk aan 0x10000000
Bestands offset en grootte (zoals opgegeven in de velden FileSiz en MemSiz in de Program Header) passen in het ELF-bestand van de toepassing

Als een programmakoptekst met deze eigenschappen aanwezig is in het ELF-bestand van de toepassing, wordt het XIP-venster zo geplaatst dat het segment zichtbaar is op 0x10000000. Het bestand mag niet meer dan één XIP-segment hebben en moet verwijzen naar 0x10000000; er kan geen ander adres worden opgegeven.

ELF-implementatie

RTApp-afbeeldingen moeten ELF-bestanden zijn. De ELF-installatiekopie wordt verpakt in een Azure Sphere-installatiekopiepakket en geïmplementeerd als een toepassing. Om de toepassing te laden, start het Azure Sphere-besturingssysteem een ELF-lader die wordt uitgevoerd op de realtime kern. Het laadprogramma verwerkt elk LOAD-segment in het ELF-bestand en laadt het in het type geheugen dat wordt aangegeven door het virtuele adres in de programmaheader.

Gebruik arm-none-eabi-readelf.exe -l (kleine letter L), dat deel uitmaakt van de GNU Arm Embedded Toolchain, om de programmaheaders voor uw toepassing weer te geven. De virtuele adreskolom (VirtAddr) die in de koptekst wordt weergegeven, geeft het doeladres voor het laadsegment aan. Dit betekent niet dat de verwerker zelf een extra vertaling uitvoert. Het Azure Sphere ELF-lader gebruikt het fysieke adres (PhysAddr) niet.

Bekijk dit voorbeeld:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000098 0x00100000 0x00100000 0x00000 0x00e78 RW  0x8
  LOAD           0x0000a0 0x10000000 0x10000000 0x03078 0x03078 RWE 0x10
  LOAD           0x003118 0x00100e78 0x10003078 0x000f0 0x000f0 RW  0x4

Het segment op 0x00100000 is gericht op nauw gekoppeld geheugen (TCM). Het loader kopieert gegevens uit het installatiekopiepakket naar het RAM-geheugen of initialiseert de TCM naar behoefte.
Het segment op 0x10000000 is toegewezen aan het XIP-venster voor de kern. Tijdens runtime worden toegangsrechten vertaald 0x10000000 + offset naar <address-of-XIP-segment-in-flash> + offset wanneer ze de realtime kern verlaten.
Het gegevenssegment op het virtuele adres 0x00100e78 is toegewezen aan TCM.

Overwegingen voor ELF-runtime

Het ELF-laadprogramma voert enkele taken uit die een onbewerkt binair (of geketend opstartlaadprogramma) bij het opstarten zou uitvoeren. Met name zero-initialiseert BSS-gegevens (block-started-by-symbol) en kopieert geïnitialiseerde maar veranderlijke gegevens van alleen-lezen flash naar RAM, volgens de programmaheaders. De toepassing wordt vervolgens gestart en voert zijn eigen initialisatiefuncties uit. In de meeste gevallen zijn wijzigingen in bestaande toepassingen niet vereist. Het nul maken van de BSS-gegevens in de toepassing is onnodig, maar onschadelijk, omdat het loader het geheugen al heeft nul gemaakt.

Het kopiëren van onveranderbare gegevens van Flash naar RAM kan in sommige omstandigheden tot problemen leiden, afhankelijk van hoe het ELF-bestand is ingedeeld. Het ELF-laadprogramma verwerkt de programmaheaders opeenvolgend, zonder de algehele indeling van de segmenten in het bestand te wijzigen. Vervolgens wordt niet alleen het XIP-segment zelf toegewezen aan 0x10000000, maar ook eventuele volgende segmenten op volgorde. Als de segmenten in het ELF-bestand in opeenvolgende volgorde staan zonder uitlijning of hiaten, kan opstartcode van het besturingssysteem gebruikmaken van aanwijzerberekeningen om het begin van het gegevenssegment te vinden. Als het ELF-bestand echter een andere indeling heeft, resulteert rekenkundige aanwijzer niet in het juiste adres, zodat de opstartcode van de toepassing niet mag proberen de gegevenssectie te kopiëren. Dit kan problemen veroorzaken als de toepassing of RTOS een geketende opstartlaadmachine gebruikt of een stack-kanarie moet instellen voordat BSS wordt uitgeschakeld of veranderlijke gegevens worden geïnitialiseerd.

Geheugendoelen

U kunt code targeten op TCM, XIP-flash of SYSRAM door het linker.ld-script voor uw toepassing te bewerken. De Azure Sphere-voorbeeldtoepassingen worden uitgevoerd vanuit TCM, maar in het linker.ld-scriptbestand voor elke toepassing wordt beschreven hoe u in plaats daarvan XIP-flash kunt gebruiken. Zoals in het volgende voorbeeld wordt weergegeven, kunt u een voorbeeld wijzigen om te worden uitgevoerd op XIP door CODE_REGION te aliasen en RODATA_REGION naar FLASH in plaats van de standaard-TCM:

REGION_ALIAS("CODE_REGION", FLASH);
REGION_ALIAS("RODATA_REGION", FLASH);

Om te bepalen of een gecompileerde toepassing wordt uitgevoerd vanuit TCM of XIP flash, gebruikt arm-none-eabi-readelf.exeu , die deel uitmaakt van de GNU Arm Embedded Toolchain. Voer het uit op het .out-bestand, dat zich in dezelfde map bevindt als het installatiekopieënpakket, en geef de -l vlag (kleine letter L) op om te zien waar de code en alleen-lezengegevens zijn geplaatst. Code en alleen-lezen gegevens die zich in flashgeheugen bevinden, worden geladen op adres 0x10000000; code en gegevens in TCM worden geladen in de TCM-regio.

In het volgende voorbeeld ziet u een toepassing die wordt uitgevoerd vanuit flashgeheugen.

arm-none-eabi-readelf.exe -l UART_RTApp_MT3620_BareMetal.out

Elf file type is EXEC (Executable file)
Entry point 0x10000000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00100000 0x00100000 0x00284 0x003c0 RW  0x4
  LOAD           0x000300 0x10000000 0x10000000 0x013b9 0x013b9 R E 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .data .bss
   01     .text .rodata

Locatie van vectortabel

Op ARMv7-M-apparaten moet de vectortabel worden uitgelijnd op een macht-van-twee-grens van ten minste 128 bytes en niet minder dan de grootte van de tabel, zoals vermeld in de ARMv7-M Architecture Reference Manual. Elke I/O RT-kern op de MT3620 ondersteunt 100 externe interrupts. Daarom bevat de tabel, inclusief de stackpointer en 15 standaarduitzonderingen, 116 vermeldingen van 4 bytes, voor een totale grootte van 464 bytes, wat wordt afgerond op 512 bytes.

Wanneer de code wordt uitgevoerd vanuit een XIP-flash, moet de vectortabel op 0x10000000 worden geplaatst en moet deze worden uitgelijnd op een grens van 32 bytes binnen het ELF-bestand. Wanneer de code niet wordt uitgevoerd vanuit XIP-flash, wordt de tabel meestal aan het begin van TCM0 geplaatst, wat 0x100000 is. In beide gevallen plaatst u de vectortabel in een toegewezen sectie en stelt u CODE_REGION in op het juiste adres om ervoor te zorgen dat het virtuele adres van de tabel correct is uitgelijnd.

De MT3620 BareMetal-voorbeelden in de opslagplaats Azure Sphere-voorbeelden laten zien hoe u dit doet. Met de declaratie van de vectortabel in main.c wordt het kenmerk ingesteld section op .vector_table. De linkerscriptaliassen CODE_REGION aan het begin van TCM of XIP en het kenmerk ALIGN stelt de uitlijning van de tekstsectie in het ELF-bestand als volgt in:

SECTIONS
{
    .text : ALIGN(32) {
        KEEP(*(.vector_table))
        *(.text)
    } >CODE_REGION
...
}

Overwegingen voor realtime en latentie

RTApps en toepassingen op hoog niveau strijden om toegang tot flashgeheugen, zelfs als ze niet met elkaar communiceren. Als gevolg hiervan kunnen RTApps die worden uitgevoerd vanaf XIP-flash te maken krijgen met een hoge en onvoorspelbare latentie. Schrijfbewerkingen naar flash, zoals tijdens een update, kunnen latentiepieken tot enkele honderden milliseconden met zich meebrengen. Afhankelijk van de vereisten van uw toepassing kunt u dit op verschillende manieren beheren:

Plaats alle code en gegevens in TCM. Code die wordt uitgevoerd vanuit TCM is niet kwetsbaar voor conflicten voor flash.
Splits code in kritieke en niet-kritieke secties en voer de niet-kritieke code uit vanaf Flash. Code met realtime-vereisten, zoals een watchdog-timer, hoeft niet te worden uitgevoerd wanneer andere code toegang heeft tot de flash. In geheugendoelen wordt beschreven hoe u XIP-flash gebruikt in plaats van TCM.
Cache gebruiken. Een toepassing kan de laagste 32 KB TCM gebruiken als XIP-cache. Deze benadering biedt geen harde realtime-garanties in het geval van een cachemissering, maar verbetert de typische prestaties zonder dat u alle code naar het RAM-geheugen hoeft te verplaatsen. Raadpleeg het mt3620 M4-gegevensblad voor informatie over de configuratie van de XIP-cache.

Share via