메모리 및 대기 시간 고려 사항 관리

아티클
08/09/2023

이 항목에서는 MT3620 칩에서 실행되는 실시간 애플리케이션에 대한 기본 메모리 사용 및 대기 시간 고려 사항에 대해 설명합니다.

참고

메모리 구성 또는 DMA에 대한 자세한 내용은 MediaTek에서 게시된 MT3620 데이터시트를 참조하세요. 질문이 남아 있는 경우 으로 이메일을 보내 Avnet에서 "MT3620 M4 데이터시트"를 Azure.Sphere@avnet.com요청할 수 있습니다.

실시간 코어의 메모리 레이아웃

다음 표에서는 실시간 코어에서 사용할 수 있는 메모리를 요약합니다.

메모리 유형	기본 주소
Tcm	0x00100000
XIP 플래시	0x10000000
SYSRAM	0x22000000

각 실시간 코어에는 192KB의 TCM(긴밀하게 결합된 메모리)이 있으며, 이 메모리는 0x00100000 시작하는 64KB의 3개의 뱅크에 매핑됩니다. TCM 액세스는 빠르지만 실시간 코어만 메모리에 액세스할 수 있습니다. TCM은 상위 수준 애플리케이션 또는 다른 코어에서 실행되는 RTApp(실시간 지원 애플리케이션)과 공유할 수 없습니다.

각 실시간 코어에는 0x22000000 시작하여 매핑되는 64KB의 SYSRAM도 있습니다. DMA 컨트롤러는 주변 장치가 액세스할 수 있도록 SYSRAM을 대상으로 할 수도 있습니다. 실시간 코어에서 SYSRAM에 대한 액세스는 TCM에 대한 액세스보다 느립니다. TCM과 마찬가지로 SYSRAM은 다른 애플리케이션과 공유할 수 없습니다.

XIP(실행 위치) 플래시 메모리는 상위 수준 애플리케이션과 공유됩니다. 플래시의 XIP 매핑에 대한 창은 주소 0x10000000 각 코어에 표시됩니다. OS는 애플리케이션의 ELF 파일에 다음 속성이 있는 세그먼트가 포함된 경우 애플리케이션을 시작하기 전에 XIP 매핑을 구성합니다.

로드 주소(프로그램 헤더의 VirtAddr 열에 지정된 대로)는 0x10000000
파일 오프셋 및 크기(프로그램 헤더의 FileSiz 및 MemSiz 필드에 지정된 대로)는 애플리케이션의 ELF 파일에 맞습니다.

이러한 속성이 있는 프로그램 헤더가 애플리케이션의 ELF 파일에 있으면 세그먼트가 0x10000000 표시되도록 XIP 창이 배치됩니다. 파일에는 둘 이상의 XIP 세그먼트가 있을 수 있으며 0x10000000 가리킵니다. 다른 주소를 지정할 수 없습니다.

ELF 배포

RTApp 이미지는 ELF 파일이어야 합니다. ELF 이미지는 Azure Sphere 이미지 패키지에 래핑되고 애플리케이션으로 배포됩니다. 애플리케이션을 로드하기 위해 Azure Sphere OS는 실시간 코어에서 실행되는 ELF 로더를 시작합니다. 로더는 ELF 파일의 각 LOAD 세그먼트를 처리하고 프로그램 헤더의 가상 주소로 표시된 메모리 형식으로 로드합니다.

GNU Arm Embedded Toolchain의 일부인 (소문자 L)을 사용하여 arm-none-eabi-readelf.exe -l 애플리케이션에 대한 프로그램 헤더를 표시합니다. 헤더에 표시되는 가상 주소 열(VirtAddr)은 부하 세그먼트의 대상 주소를 나타냅니다. 프로세서 자체가 추가 번역을 수행한다는 의미는 아닙니다. Azure Sphere ELF 로더는 물리적 주소(PhysAddr)를 사용하지 않습니다.

다음 예제를 고려해 보세요.

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

0x00100000 세그먼트는 TCM(긴밀하게 결합된 메모리)을 대상으로 합니다. 로더는 이미지 패키지의 데이터를 RAM에 복사하거나 필요에 따라 TCM을 0으로 초기화합니다.
0x10000000 세그먼트는 코어의 XIP 창에 매핑됩니다. 런타임에 에 대한 0x10000000 + offset 액세스는 실시간 코어를 <address-of-XIP-segment-in-flash> + offset 떠날 때 로 변환됩니다.
가상 주소 0x00100e78 데이터 세그먼트가 TCM에 매핑됩니다.

ELF 런타임 고려 사항

ELF 로더는 시작 시 원시 이진(또는 연결된 부팅 로더)이 수행하는 일부 작업을 수행합니다. 특히 프로그램 헤더에 따라 BSS(블록 시작 기호) 데이터를 0으로 초기화하고 초기화되었지만 변경 가능한 데이터를 읽기 전용 플래시에서 RAM으로 복사합니다. 그런 다음, 애플리케이션은 자체 초기화 함수를 시작하고 실행합니다. 대부분의 경우 기존 애플리케이션에 대한 변경이 필요하지 않습니다. 로더가 이미 메모리를 0으로 설정했기 때문에 애플리케이션에서 BSS 데이터를 0으로 설정하면 불필요하지만 무해합니다.

변경 가능한 데이터를 플래시에서 RAM으로 복사하면 ELF 파일이 배치되는 방식에 따라 문제가 발생할 수 있습니다. ELF 로더는 파일에서 세그먼트의 전체 레이아웃을 변경하지 않고 프로그램 헤더를 순차적으로 처리합니다. 그런 다음 XIP 세그먼트 자체뿐만 아니라 0x10000000 후속 세그먼트도 순서대로 매핑합니다. ELF 파일의 세그먼트가 정렬 또는 간격 없이 순차적으로 표시되는 경우 OS 시작 코드는 포인터 산술 연산을 사용하여 데이터 세그먼트의 시작을 찾을 수 있습니다. 그러나 ELF 파일에 다른 레이아웃이 있는 경우 포인터 산술 연산으로 인해 올바른 주소가 생성되지 않으므로 애플리케이션 시작 코드에서 데이터 섹션을 복사하지 않아야 합니다. 이로 인해 애플리케이션 또는 RTOS가 연결된 부팅 로더를 사용하거나 BSS를 0으로 설정하거나 변경 가능한 데이터를 초기화하기 전에 스택 카나리아를 설정해야 하는 경우 문제가 발생할 수 있습니다.

메모리 대상

애플리케이션에 대한 linker.ld 스크립트를 편집하여 TCM, XIP 플래시 또는 SYSRAM에서 코드를 대상으로 지정할 수 있습니다. Azure Sphere 샘플 애플리케이션은 TCM에서 실행되지만 각 애플리케이션에 대한 linker.ld 스크립트 파일은 XIP 플래시를 대상으로 지정하는 방법을 설명합니다. 다음 예제와 같이 기본 TCM 대신 CODE_REGION 별칭을 지정하고 RODATA_REGION FLASH로 변경하여 XIP에서 실행되도록 샘플을 변경할 수 있습니다.

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

컴파일된 애플리케이션이 TCM 또는 XIP 플래시에서 실행되는지 확인하려면 GNU Arm Embedded Toolchain의 일부인 를 사용합니다 arm-none-eabi-readelf.exe. 이미지 패키지와 동일한 디렉터리에 있는 .out 파일에서 실행하고(소문자 L) 플래그를 지정 -l 하여 코드 및 읽기 전용 데이터가 배치된 위치를 확인합니다. 플래시 메모리에 있는 코드 및 읽기 전용 데이터는 주소 0x10000000 로드됩니다. TCM의 코드 및 데이터는 TCM 지역에 로드됩니다.

다음 예제에서는 플래시 메모리에서 실행되는 애플리케이션을 보여줍니다.

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

벡터 테이블 위치

ARMv7-M 디바이스에서 ARMv7-M 아키텍처 참조 설명서에 설명된 대로 벡터 테이블은 최소 128바이트이고 테이블 크기보다 작은 두 개의 전원 경계에 맞춰야 합니다. MT3620의 각 I/O RT 코어는 100개의 외부 인터럽트를 지원합니다. 따라서 스택 포인터와 15개의 표준 예외를 포함하여 테이블에는 116개의 4바이트 항목이 있으며 총 크기는 464바이트이며 최대 512바이트까지 반올림됩니다.

XIP 플래시에서 코드를 실행하는 경우 벡터 테이블은 0x10000000 배치되어야 하며 ELF 파일 내의 32 바이트 경계에 맞춰야 합니다. XIP 플래시에서 코드를 실행하지 않으면 테이블은 일반적으로 0x100000 TCM0의 시작 부분에 배치됩니다. 두 경우 모두 테이블의 가상 주소가 올바르게 정렬되었는지 확인하려면 전용 섹션에 벡터 테이블을 배치하고 CODE_REGION 적절한 주소로 설정합니다.

Azure Sphere 샘플 리포지토리의 MT3620 BareMetal 샘플은 이 작업을 수행하는 방법을 보여줍니다. 기본.c에서 벡터 테이블의 선언은 해당 section 특성을 로 .vector_table설정합니다. 링커 스크립트 별칭은 TCM 또는 XIP의 시작 부분에 CODE_REGION ALIGN 특성은 다음과 같이 ELF 파일 내에서 텍스트 섹션의 맞춤을 설정합니다.

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

실시간 및 대기 시간 고려 사항

RTApps 및 상위 수준 애플리케이션은 서로 통신하지 않더라도 플래시 메모리에 대한 액세스를 위해 경쟁합니다. 따라서 XIP 플래시에서 실행되는 RTApps는 높고 예측할 수 없는 대기 시간이 발생할 수 있습니다. 업데이트 중과 같이 플래시에 대한 쓰기에는 최대 수백 밀리초의 대기 시간 급증이 포함될 수 있습니다. 애플리케이션의 요구 사항에 따라 다음과 같은 여러 가지 방법으로 이를 관리할 수 있습니다.

모든 코드와 데이터를 TCM에 넣습니다. TCM에서 실행되는 코드는 플래시 경합에 취약하지 않습니다.
코드를 중요 및 중요하지 않은 섹션으로 분할하고 플래시에서 중요하지 않은 코드를 실행합니다. Watchdog 타이머와 같은 실시간 요구 사항이 있는 코드는 다른 코드가 플래시에 액세스할 때 실행할 필요가 없습니다. 메모리 대상은 TCM 대신 XIP 플래시를 대상으로 지정하는 방법을 설명합니다.
캐시를 사용합니다. 애플리케이션은 가장 낮은 32KB의 TCM을 XIP 캐시로 사용할 수 있습니다. 이 방법은 캐시 누락 시 하드 실시간 보장을 제공하지 않지만 모든 코드를 RAM으로 이동할 필요 없이 일반적인 성능을 향상시킵니다. XIP 캐시 구성에 대한 자세한 내용은 "MT3620 M4 데이터시트"를 참조하세요.

다음을 통해 공유