Zagadnienia dotyczące zarządzania pamięcią i opóźnieniami

Ważne

Jest to dokumentacja usługi Azure Sphere (starsza wersja). Usługa Azure Sphere (starsza wersja) zostanie wycofana 27 września 2027 r., a użytkownicy muszą przeprowadzić migrację do usługi Azure Sphere (zintegrowanej) do tej pory. Użyj selektora wersji znajdującego się powyżej spisu treści, aby wyświetlić dokumentację usługi Azure Sphere (zintegrowaną).

W tym temacie opisano podstawowe zagadnienia dotyczące użycia pamięci i opóźnień dla aplikacji w czasie rzeczywistym uruchamianych na mikroukładie MT3620.

Uwaga

Aby uzyskać więcej informacji na temat konfiguracji pamięci lub dmA, zobacz opublikowany arkusz danych MT3620 z mediaTek. Jeśli pytania pozostaną, możesz zażądać arkusza danych MT3620 M4 z firmy Avnet, wysyłając wiadomość e-mail na Azure.Sphere@avnet.comadres .

Układ pamięci na rdzeniach czasu rzeczywistego

W poniższej tabeli przedstawiono podsumowanie pamięci dostępnej na rdzeniach czasu rzeczywistego:

Typ pamięci	Adres podstawowy
TCM	0x00100000
Flash XIP	0x10000000
SYSRAM	0x22000000

Każdy rdzeń czasu rzeczywistego ma 192 KB ściśle powiązanej pamięci (TCM), która jest mapowana w trzech bankach 64 KB, począwszy od 0x00100000. Dostęp do TCM jest szybki, ale tylko rdzeń czasu rzeczywistego może uzyskać dostęp do pamięci. TCM nie może być współużytkowany z aplikacją wysokiego poziomu lub aplikacją z obsługą czasu rzeczywistego (RTApp), która działa na innym rdzeniu.

Każdy rdzeń czasu rzeczywistego ma również 64 KB pamięci SYSRAM, która jest mapowana począwszy od 0x22000000. Kontroler DMA może również kierować do pamięci SYSRAM, aby urządzenia peryferyjne mogły uzyskiwać do niego dostęp. Dostęp do usługi SYSRAM z rdzenia czasu rzeczywistego jest wolniejszy niż dostęp do usługi TCM. Podobnie jak w przypadku TCM, nie można udostępnić pamięci SYSRAM innej aplikacji.

Pamięć flash execute-in-place (XIP) jest udostępniana aplikacjom wysokiego poziomu. Okno do mapowania XIP flash jest widoczne dla każdego rdzenia pod adresem 0x10000000. System operacyjny konfiguruje mapowanie XIP przed uruchomieniem aplikacji, jeśli plik ELF aplikacji zawiera segment o następujących właściwościach:

• Adres ładowania (określony w kolumnie VirtAddr nagłówka programu) jest równy 0x10000000
• Przesunięcie i rozmiar pliku (jak określono w polach FileSiz i MemSiz w nagłówku programu) mieszczą się w pliku ELF aplikacji

Jeśli nagłówek programu z tymi właściwościami znajduje się w pliku ELF aplikacji, okno XIP zostanie umieszczone tak, aby segment był widoczny w 0x10000000. Plik może mieć nie więcej niż jeden segment XIP i musi wskazywać 0x10000000; nie może określić żadnego innego adresu.

Wdrażanie aplikacji ELF

Obrazy RTApp muszą być plikami ELF. Obraz ELF jest opakowany w pakiet obrazu usługi Azure Sphere i wdrożony jako aplikacja. Aby załadować aplikację, system operacyjny Azure Sphere uruchamia moduł ładujący ELF, który działa na rdzeniu czasu rzeczywistego. Moduł ładujący przetwarza każdy segment LOAD w pliku ELF i ładuje go do typu pamięci wskazanej przez adres wirtualny w nagłówku programu.

Użyj arm-none-eabi-readelf.exe -l (małe litery L), która jest częścią osadzonego łańcucha narzędzi GNU arm, aby wyświetlić nagłówki programu dla aplikacji. Kolumna adresu wirtualnego (VirtAddr) wyświetlana w nagłówku wskazuje adres docelowy segmentu obciążenia. Nie oznacza to, że sam procesor wykonuje dodatkowe tłumaczenie. Moduł ładujący ELF usługi Azure Sphere nie używa adresu fizycznego (PhysAddr).

Rozważ taki przykład:

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 w 0x00100000 jest przeznaczony dla ściśle powiązanej pamięci (TCM). Moduł ładujący kopiuje dane z pakietu obrazu do pamięci RAM lub zero inicjuje TCM zgodnie z potrzebami.

• Segment w 0x10000000 jest mapowany na okno XIP dla rdzenia. W czasie wykonywania dostępy do 0x10000000 + offset programu są tłumaczone na <address-of-XIP-segment-in-flash> + offset czas opuszczenia rdzenia czasu rzeczywistego.

• Segment danych pod adresem wirtualnym 0x00100e78 jest mapowany na TCM.

Zagadnienia dotyczące środowiska uruchomieniowego ELF

Moduł ładujący ELF wykonuje niektóre zadania wykonywane przez nieprzetworzony plik binarny (lub łańcuchowy moduł ładujący) podczas uruchamiania. W szczególności zero inicjuje dane block-started-by-symbol (BSS) i kopiuje zainicjowane, ale modyfikowalne dane z flash tylko do odczytu do pamięci RAM, zgodnie z nagłówkami programu. Następnie aplikacja uruchamia i uruchamia własne funkcje inicjowania. W większości przypadków zmiany istniejących aplikacji nie są wymagane. Zerowanie danych BSS w aplikacji jest niepotrzebne, ale nieszkodliwe, ponieważ moduł ładujący już zerował pamięć.

Kopiowanie danych modyfikowalnych z pamięci flash do pamięci RAM może w niektórych okolicznościach powodować problemy, w zależności od sposobu instalowania pliku ELF. Moduł ładujący ELF przetwarza nagłówki programu sekwencyjnie, nie zmieniając ogólnego układu segmentów w pliku. Następnie mapuje nie tylko sam segment XIP na 0x10000000, ale także wszystkie kolejne segmenty w kolejności. Jeśli segmenty w pliku ELF są w kolejności sekwencyjnej bez wyrównania lub przerw, kod uruchamiania systemu operacyjnego może użyć arytmetyki wskaźnika, aby znaleźć początek segmentu danych. Jeśli jednak plik ELF ma inny układ, arytmetyka wskaźnika nie powoduje poprawnego adresu, więc kod uruchamiania aplikacji nie może spróbować skopiować sekcji danych. Może to spowodować problemy, jeśli aplikacja lub RTOS używa łańcuchowego modułu ładującego rozruchu lub musi skonfigurować kanary stosu przed zerowaniem BSS lub inicjowaniem danych modyfikowalnych.

Miejsca docelowe pamięci

Kod docelowy można wykonać na stronie TCM, flash XIP lub SYSRAM, edytując skrypt linker.ld dla aplikacji. Przykładowe aplikacje usługi Azure Sphere są uruchamiane z poziomu narzędzia TCM, ale plik skryptu linker.ld dla każdej aplikacji opisuje sposób zamiast tego docelowy flash XIP. Jak pokazano w poniższym przykładzie, możesz zmienić przykład, aby był uruchamiany w środowisku XIP, aliasując CODE_REGION i RODATA_REGION na flash zamiast domyślnego TCM:

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

Aby określić, czy skompilowana aplikacja działa z pamięci flash TCM lub XIP, użyj elementu arm-none-eabi-readelf.exe, który jest częścią łańcucha narzędzi osadzonych arm GNU. Uruchom go w pliku out, który znajduje się w tym samym katalogu co pakiet obrazu, i określ flagę -l (małe litery L), aby zobaczyć, gdzie został umieszczony kod i dane tylko do odczytu. Kod i dane tylko do odczytu, które znajdują się w pamięci flash, są ładowane pod adresem 0x10000000; kod i dane w usłudze TCM są ładowane w regionie TCM.

W poniższym przykładzie pokazano aplikację uruchamianą z pamięci 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

Lokalizacja tabeli wektorowej

Na urządzeniach ARMv7-M tabela wektorów musi być wyrównana do granicy zasilania dwóch, która wynosi co najmniej 128 bajtów i nie mniej niż rozmiar tabeli, jak wspomniano w podręczniku architektury ARMv7-M. Każdy rdzeń we/wy RT w mt3620 obsługuje 100 przerwań zewnętrznych. W związku z tym, w tym wskaźnik stosu i 15 standardowych wyjątków, tabela zawiera 116 4-bajtowych wpisów, dla całkowitego rozmiaru 464 bajtów, który zaokrągla do 512 bajtów.

Gdy kod jest uruchamiany z pamięci flash XIP, tabela wektorów musi zostać umieszczona w 0x10000000 i musi być wyrównana do granicy 32-bajtowej w pliku ELF. Gdy kod nie jest uruchamiany z pamięci flash XIP, tabela jest zwykle umieszczana na początku TCM0, co jest 0x100000. W obu przypadkach, aby upewnić się, że adres wirtualny tabeli jest poprawnie wyrównany, umieść tabelę wektorów w dedykowanej sekcji i ustaw CODE_REGION na odpowiedni adres.

Przykłady mt3620 BareMetal w repozytorium Przykładów usługi Azure Sphere pokazują, jak to zrobić. Deklaracja tabeli wektorów w pliku main.c ustawia jego section atrybut na .vector_table. Aliasy skryptu konsolidatora CODE_REGION na początku TCM lub XIP, a atrybut ALIGN ustawia wyrównanie sekcji tekstowej w pliku ELF w następujący sposób:

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

Zagadnienia dotyczące czasu rzeczywistego i opóźnienia

Aplikacje RTApps i aplikacje wysokiego poziomu walczą o dostęp do pamięci flash, nawet jeśli nie komunikują się ze sobą. W związku z tym aplikacje RTApps uruchomione z pamięci flash XIP mogą napotkać duże i nieprzewidywalne opóźnienie. Zapisy w pamięci flash, takie jak podczas aktualizacji, mogą obejmować skoki opóźnień do kilkuset milisekund. W zależności od wymagań aplikacji można zarządzać tym na kilka sposobów:

• Umieść cały kod i dane w narzędziu TCM. Kod uruchamiany z TCM nie jest podatny na rywalizację o flash.

• Podziel kod na sekcje krytyczne i niekrytyczne, a następnie uruchom kod niekrytyczny z pamięci flash. Kod, który ma wymagania w czasie rzeczywistym, takie jak czasomierz watchdog, nie powinien być uruchamiany, gdy inny kod uzyskuje dostęp do flash. Cele pamięci opisują sposób kierowania flash XIP zamiast TCM.

• Użyj pamięci podręcznej. Aplikacja może używać najniższej 32 KB pamięci podręcznej TCM jako pamięci podręcznej XIP. Takie podejście nie zapewnia gwarancji czasu rzeczywistego w przypadku chybienia pamięci podręcznej, ale poprawia typową wydajność bez konieczności przenoszenia całego kodu do pamięci RAM. Aby uzyskać informacje o konfiguracji pamięci podręcznej XIP, zapoznaj się z arkuszem danych "MT3620 M4".