Důležité informace o správě paměti a latence

Článek
08/09/2023

Toto téma popisuje aspekty základního využití paměti a latence u aplikací 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 od společnosti MediaTek; Pokud otázky přetrvávají, můžete si vyžádat datový list MT3620 M4 od avnetu Azure.Sphere@avnet.come-mailem .

Rozložení paměti u jader v reálném čase

Následující tabulka shrnuje dostupnou paměť jader 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 pevně propojené paměti (TCM), která je mapována ve třech bankách po 64 kB od 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 paměti SYSRAM, který se mapuje od 0x22000000. Řadič DMA může také cílit na sysram, aby k němu periferní zařízení mohly přistupovat. Přístupy k SYSRAM z jádra v reálném čase jsou pomalejší než přístupy k TCM. Stejně jako u TCM nelze sysram sdílet s jinou aplikací.

Paměť flash typu XIP (Execute-in-place) se sdílí s aplikacemi vysoké úrovně. Každé jádro na adrese 0x10000000 je viditelné okno do mapování XIP flash. 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:

Načíst adresu (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 hlavička programu s těmito vlastnostmi v souboru ELF aplikace, bude okno XIP umístěné 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

Image RTApp musí být soubory ELF. Image ELF se zabalí do balíčku imagí Azure Sphere a nasadí se jako aplikace. Pro 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 určeného virtuální adresou v hlavičce programu.

Pomocí arm-none-eabi-readelf.exe -l malého písmena L, která je součástí sady nástrojů GNU Arm Embedded Toolchain, můžete zobrazit hlavičky programu pro vaši aplikaci. Sloupec virtuální adresy (VirtAddr), který se zobrazí v záhlaví, označuje cílovou adresu pro segment zatížení. Neznamená to, že procesor sám provádí jakýkoli 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 svázanou paměť (TCM). Zavaděč buď zkopíruje data z balíčku image do paměti RAM, nebo inicializuje TCM nulou podle potřeby.
Segment v 0x10000000 se mapuje na okno XIP pro jádro. Za běhu se přístupy k 0x10000000 + offset přeloží do <address-of-XIP-segment-in-flash> + offset , když 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ý zavaděč). Konkrétně nulou inicializuje data bss (block-started-by-symbol) a kopíruje inicializovaná, ale proměnlivá data z flashku jen pro čtení do paměti RAM podle hlaviček programu. Aplikace se pak spustí a spustí vlastní inicializační funkce. Ve většině případů se změny stávajících aplikací nevyžadují. Vynulování dat BSS v aplikaci je zbytečné, ale neškodné, protože zavaděč již vynuloval paměť.

Kopírování proměnlivých dat z flash do paměti RAM může za určitých okolností způsobit problémy v závislosti na tom, jak je soubor ELF rozložen. Zavaděč ELF zpracovává hlavičky programu postupně, aniž by změnil celkové 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 použít aritmetický ukazatel k vyhledání začátku datového segmentu. Pokud má ale soubor ELF jiné rozložení, aritmetika ukazatele nemá za následek správnou adresu, takže spouštěcí kód aplikace se nesmí pokoušet kopírovat oddíl dat. To může způsobit problémy, pokud aplikace nebo RTOS používá zřetězený zavaděč nebo potřebuje před vynulováním BSS nebo inicializací proměnlivých dat nastavit zásobník kanárek.

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 v XIP, a to aliasem CODE_REGION a RODATA_REGION na FLASH místo výchozího TCM:

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

Pokud chcete zjistit, jestli se kompilovaná aplikace spouští z TCM nebo XIP flash, použijte arm-none-eabi-readelf.exepříkaz , který je součástí sady nástrojů GNU Arm Embedded Toolchain. Spusťte ho v souboru .out, který je ve stejném adresáři jako balíček image, a zadejte -l příznak L (malými písmeny L), abyste zjistili, kam se kód a data jen pro čtení umístily. Kód a data jen pro čtení, která jsou v paměti flash, se načítají na adrese 0x10000000; kód a data v TCM se načítají 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 výkonu dvou, která je nejméně 128 bajtů a ne menší než velikost tabulky, jak je uvedeno v referenční příručce k architektuře ARMv7-M. Každé jádro I/O RT na mt3620 podporuje 100 externích přerušení. Proto včetně ukazatele zásobníku a 15 standardních výjimek obsahuje tabulka 116 4bajtů položek s 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, který je 0x100000. Pokud chcete zajistit správné zarovnání virtuální adresy tabulky, umístěte vektorovou tabulku do vyhrazeného oddílu a nastavte CODE_REGION na příslušnou adresu.

Postup ukazují ukázky MT3620 BareMetal v úložišti ukázek Azure Sphere. 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 latenci v reálném čase

RtApps a aplikace vysoké úrovně se snaží o přístup k flash paměti, i když spolu nekomunikují. V důsledku toho můžou aplikace RT, které běží z XIP Flash, narazit na vysokou a nepředvídatelnou latenci. Zápisy do blesku, například během aktualizace, můžou obsahovat špičky latence až několik set milisekund. V závislosti na požadavcích vaší aplikace to můžete spravovat několika způsoby:

Vložte veškerý kód a data do TCM. Kód, který běží z TCM, není ohrožený kolizemi o flash.
Rozdělte kód na kritické a nekritické části a nekritické kódy spusťte z flashe. Kód, který má požadavky v reálném čase, jako je časovač sledovacího zařízení, by se neměl spouštět, když k blesku přistupuje jiný kód. Cíle paměti popisují, jak cílit na XIP flash místo TCM.
Použít 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ě výpadku 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