Správa důležitých aspektů paměti a latence

Článek
09/27/2024

Důležité

Toto je dokumentace k Azure Sphere (starší verze). Azure Sphere (starší verze) se vyřazuje 27. září 2027 a uživatelé musí do této doby migrovat do Azure Sphere (integrované). K zobrazení dokumentace k Azure Sphere (integrované) použijte selektor verzí umístěný nad obsahem.

Toto téma popisuje základní aspekty využití paměti a latence pro aplikace v reálném čase, které běží na čipu MT3620.

Poznámka:

Další podrobnosti o konfiguraci paměti nebo DMA najdete v publikovaném datovém listu MT3620 z MediaTek. Pokud dotazy zůstanou, můžete požádat o datový list MT3620 M4 z Avnet e-mailem Azure.Sphere@avnet.com.

Rozložení paměti na jádrech v reálném čase

Následující tabulka shrnuje paměť dostupnou v jádrech v reálném čase:

Typ paměti	Základní adresa
TCM	0x00100000
XIP flash	0x10000000
SYSRAM	0x22000000

Každé jádro v reálném čase má 192 kB úzce propojené paměti (TCM), která je mapována ve třech bankách 64 kB počínaje 0x00100000. Přístupy TCM jsou rychlé, ale k paměti má přístup pouze jádro v reálném čase. TCM nelze sdílet s aplikací vysoké úrovně nebo s aplikací podporující v reálném čase (RTApp), která běží na jiném jádru.

Každé jádro v reálném čase má také 64 kB SYSRAM, který je mapován od 0x22000000. Řadič DMA může také cílit na SYSRAM, aby k němu mohly přistupovat periferní zařízení. Přístupy k SYSRAM z jádra v reálném čase jsou pomalejší než přístup k TCM. Stejně jako u TCM nelze sysRAM sdílet s jinou aplikací.

S aplikacemi vysoké úrovně se sdílí místní flash paměť (XIP). Okno do mapování XIP blesku je viditelné pro každé jádro na adrese 0x10000000. Operační systém nakonfiguruje mapování XIP před spuštěním aplikace, pokud soubor ELF aplikace obsahuje segment, který má následující vlastnosti:

Load address (jak je uvedeno ve sloupci VirtAddr hlavičky programu) se rovná 0x10000000
Posun a velikost souboru (jak je uvedeno v polích FileSiz a MemSiz v hlavičce programu) se vejdou do souboru ELF aplikace.

Pokud je v souboru ELF aplikace k dispozici hlavička programu s těmito vlastnostmi, okno XIP se umístí tak, aby segment byl viditelný na 0x10000000. Soubor nemůže mít více než jeden segment XIP a musí odkazovat na 0x10000000; nemůže zadat žádnou jinou adresu.

Nasazení ELF

Obrázky RTApp musí být soubory ELF. Image ELF se zabalí do balíčku image Azure Sphere a nasadí se jako aplikace. K načtení aplikace spustí operační systém Azure Sphere zavaděč ELF, který běží na jádru v reálném čase. Zavaděč zpracuje každý segment LOAD v souboru ELF a načte ho do typu paměti označené virtuální adresou v hlavičce programu.

K zobrazení hlaviček programu pro vaši aplikaci použijte arm-none-eabi-readelf.exe -l (malá písmena L), která je součástí sady NÁSTROJŮ GNU Arm Embedded Toolchain. Sloupec virtuální adresy (VirtAddr), který se zobrazí v hlavičce, označuje cílovou adresu segmentu načítání. Neznamená to, že samotný procesor provádí žádný další překlad. Zavaděč ELF Azure Sphere nepoužívá fyzickou adresu (PhysAddr).

Podívejte se na tento příklad:

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

Segment v 0x00100000 je zaměřen na úzce propojené paměti (TCM). Zavaděč buď zkopíruje data z balíčku image do paměti RAM, nebo podle potřeby inicializuje TCM.
Segment v 0x10000000 se mapuje na okno XIP pro jádro. V době běhu se přístupy 0x10000000 + offset přeloží do okamžiku, kdy <address-of-XIP-segment-in-flash> + offset opustí jádro v reálném čase.
Datový segment na virtuální adrese 0x00100e78 se mapuje na TCM.

Důležité informace o modulu runtime ELF

Zavaděč ELF provádí některé úlohy, které by při spuštění prováděl nezpracovaný binární (nebo zřetězený bootloader). Konkrétně nula inicializuje blok-started-by-symbol (BSS) data a kopíruje inicializovaná, ale proměnlivá data z jen pro čtení flash do paměti RAM podle hlaviček programu. Aplikace pak spustí a spustí vlastní inicializační funkce. Ve většině případů se změny stávajících aplikací nevyžadují. Nulová hodnota dat BSS v aplikaci je zbytečná, ale neškodná, protože zavaděč již vynuloval paměť.

Kopírování proměnlivých dat z blesku do paměti RAM může v některých případech vést k problémům v závislosti na tom, jak je soubor ELF rozložen. Zavaděč ELF zpracovává hlavičky programu postupně beze změny celkového rozložení segmentů v souboru. Pak mapuje nejen samotný segment XIP na 0x10000000, ale také všechny následné segmenty v pořadí. Pokud jsou segmenty v souboru ELF v sekvenčním pořadí bez zarovnání nebo mezer, spouštěcí kód operačního systému může k nalezení začátku datového segmentu použít aritmetický ukazatel. Pokud má soubor ELF jiné rozložení, ale aritmetika ukazatele nemá za následek správnou adresu, takže spouštěcí kód aplikace se nesmí pokusit zkopírovat datový oddíl. To může způsobit problémy v případě, že aplikace nebo RTOS používá zřetězený bootloader nebo potřebuje nastavit kanárku zásobníku před nulací BSS nebo inicializací proměnlivých dat.

Cíle paměti

Kód můžete cílit na TCM, XIP flash nebo SYSRAM úpravou skriptu linker.ld pro vaši aplikaci. Ukázkové aplikace Azure Sphere běží z TCM, ale soubor skriptu linker.ld pro každou aplikaci popisuje, jak místo toho cílit na XIP flash. Jak ukazuje následující příklad, můžete změnit ukázku tak, aby běžela na XIP, a to aliasy CODE_REGION a RODATA_REGION na FLASH místo výchozího TCM:

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

Chcete-li zjistit, zda kompilovaná aplikace běží z TCM nebo XIP flash, použijte arm-none-eabi-readelf.exe, který je součástí GNU Arm Embedded Toolchain. Spusťte ho v souboru .out, který je ve stejném adresáři jako balíček image, a zadejte příznak (malými písmeny L) a zjistěte -l , kde se kód a data jen pro čtení umístila. Kód a data jen pro čtení, která jsou v paměti flash, se načtou na adrese 0x10000000; kód a data v TCM jsou načteny v oblasti TCM.

Následující příklad ukazuje aplikaci, která běží z paměti flash.

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

Umístění vektorové tabulky

Na zařízeních ARMv7-M musí být vektorová tabulka zarovnaná na hranici napájení dvou, která je alespoň 128 bajtů a ne menší než velikost tabulky, jak je uvedeno v referenční příručce k architektuře ARMv7-M. Každé V/V jádro mt3620 podporuje 100 externích přerušení. Proto zahrnuje ukazatel zásobníku a 15 standardních výjimek, tabulka obsahuje 116 4 bajtových položek pro celkovou velikost 464 bajtů, což zaokrouhlí až na 512 bajtů.

Při spuštění kódu z XIP flash musí být vektorová tabulka umístěna na 0x10000000 a musí být zarovnaná na hranici 32 bajtů v souboru ELF. Pokud se kód nespustí z XIP flash, tabulka se obvykle umístí na začátek TCM0, což je 0x100000. V obou případech zajistěte, aby byla virtuální adresa tabulky správně zarovnaná, vložte vektorovou tabulku do vyhrazeného oddílu a nastavte CODE_REGION na příslušnou adresu.

Ukázky MT3620 BareMetal v úložišti ukázek Azure Sphere ukazují, jak to udělat. Deklarace vektorové tabulky v main.c nastaví její section atribut na .vector_table. Aliasy skriptu linkeru CODE_REGION na začátek TCM nebo XIP a atribut ALIGN nastaví zarovnání textového oddílu v souboru ELF následujícím způsobem:

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

Důležité informace o latenci a čase v reálném čase

Aplikace RTApps a aplikace vysoké úrovně se snaží získat přístup k paměti flash, i když spolu nekomunikují. V důsledku toho se rtApps, které běží z XIP flash, můžou setkat s vysokou a nepředvídatelnou latencí. Zápisy do blesku, například během aktualizace, můžou zahrnovat špičky latence až do několika stovek milisekund. V závislosti na požadavcích vaší aplikace můžete tuto správu spravovat několika způsoby:

Vložte veškerý kód a data do TCM. Kód, který se spouští z TCM, není zranitelný vůči kolizím pro flash.
Rozdělte kód na kritické a nekritické části a spusťte nekritické kódy z flashu. Kód, který má požadavky v reálném čase, jako je časovač sledovacího zařízení, by neměl být spuštěn, když k blesku přistupuje jiný kód. Cíle paměti popisují, jak cílit na XIP flash místo TCM.
Použijte mezipaměť. Aplikace může jako mezipaměť XIP použít nejnižší 32 kB TCM. Tento přístup neposkytuje pevné záruky v reálném čase v případě chybějící mezipaměti, ale zlepšuje typický výkon, aniž byste museli přesunout veškerý kód do paměti RAM. Informace o konfiguraci mezipaměti XIP najdete v datovém listu MT3620 M4.

Sdílet prostřednictvím