Mengelola pertimbangan memori dan latensi

Artikel
08/09/2023

Topik ini menjelaskan pertimbangan penggunaan memori dasar dan latensi untuk aplikasi real-time yang berjalan pada chip MT3620.

Catatan

Untuk detail selengkapnya tentang konfigurasi memori atau DMA, lihat Lembar Data MT3620 yang diterbitkan dari MediaTek; jika masih ada pertanyaan, Anda dapat meminta "Lembar Data MT3620 M4" dari Avnet melalui email Azure.Sphere@avnet.com.

Tata letak memori pada inti real-time

Tabel berikut ini merangkum memori yang tersedia pada inti real-time:

Tipe memori	Alamat Dasar
TCM	0x00100000
Lampu kilat XIP	0x10000000
SYSRAM	0x22000000

Setiap inti real-time memiliki 192 KB memori berpasangan erat (TCM), yang dipetakan di tiga bank berukuran 64 KB mulai dari 0x00100000. Akses TCM cepat, tetapi hanya inti real-time yang dapat mengakses memori. TCM tidak dapat dibagikan dengan aplikasi tingkat tinggi atau dengan aplikasi berkemampuan real-time (RTApp) yang berjalan pada inti yang berbeda.

Setiap inti real-time juga memiliki 64 KB SYSRAM, yang dipetakan mulai dari 0x22000000. Pengontrol DMA juga dapat menargetkan SYSRAM, sehingga periferal dapat mengaksesnya. Akses ke SYSRAM dari inti real-time lebih lambat daripada akses ke TCM. Seperti TCM, SYSRAM tidak dapat dibagikan dengan aplikasi lain.

Memori flash execute-in-place (XIP) dibagikan dengan aplikasi tingkat tinggi. Jendela ke dalam pemetaan XIP lampu kilat dapat dilihat oleh setiap inti di alamat 0x10000000. OS mengonfigurasi pemetaan XIP sebelum memulai aplikasi jika file ELF aplikasi berisi segmen yang memiliki properti berikut:

Memuat alamat (seperti yang ditentukan dalam kolom VirtAddr header Program) sama dengan 0x10000000
Offset dan ukuran file (seperti yang ditentukan dalam bidang FileSiz dan MemSiz di Header Program) pas dalam file ELF aplikasi

Jika header program dengan properti ini ada dalam file ELF aplikasi, jendela XIP akan diposisikan sehingga segmen terlihat 0x10000000. File dapat memiliki tidak lebih dari satu segmen XIP, dan harus mengarah ke 0x10000000; tidak dapat menentukan alamat lain.

Penyebaran ELF

Gambar RTApp harus berupa file ELF. Gambar ELF dibungkus dalam paket gambar Azure Sphere dan digunakan sebagai aplikasi. Untuk memuat aplikasi, Azure Sphere OS memulai pemuat ELF yang berjalan pada inti real-time. Loader memproses setiap segmen LOAD dalam file ELF dan memuatnya ke tipe memori yang ditunjukkan oleh alamat virtual di header program.

Gunakan arm-none-eabi-readelf.exe -l (huruf kecil L), yang merupakan bagian dari Toolchain GNU Arm Embedded, untuk menampilkan header program untuk aplikasi Anda. Kolom alamat virtual (VirtAddr) yang muncul di header menunjukkan alamat tujuan untuk segmen muat. Ini tidak berarti bahwa prosesor itu sendiri melakukan terjemahan tambahan. Loader ELF Azure Sphere tidak menggunakan alamat fisik (PhysAddr).

Pertimbangkan contoh ini:

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

Segmen di 0x00100000 ditargetkan pada memori yang digabungkan erat (TCM). Loader menyalin data dari paket gambar ke DALAM RAM atau menginisialisasi TCM nol sesuai kebutuhan.
Segmen di 0x10000000 dipetakan ke jendela XIP untuk inti. Pada waktu proses, akses ke 0x10000000 + offset diterjemahkan ketika <address-of-XIP-segment-in-flash> + offset mereka meninggalkan inti real-time.
Segmen data di alamat virtual 0x00100e78 dipetakan ke TCM.

Pertimbangan runtime ELF

Loader ELF melakukan beberapa tugas yang akan dijalankan biner mentah (atau bootloader berantai) pada saat start-up. Secara khusus, ini menginisialisasi data block-started-by-symbol (BSS) dan menyalin data yang diinisialisasi namun dapat diubah dari lampu kilat baca-saja ke DALAM RAM, menurut header program. Aplikasi kemudian memulai dan menjalankan fungsi inisialisasinya sendiri. Biasanya, perubahan pada aplikasi yang sudah ada tidak diperlukan. Nol data BSS dalam aplikasi tidak diperlukan tetapi tidak berbahaya, karena loader telah nol memori.

Menyalin data yang dapat diubah dari flash ke RAM mungkin dalam beberapa situasi mengakibatkan masalah, tergantung pada bagaimana file ELF ditata. Loader ELF memproses header program secara berurutan, tanpa mengubah tata letak keseluruhan segmen dalam file. Kemudian memetakan tidak hanya segmen XIP itu sendiri untuk 0x10000000, tetapi juga segmen berikutnya secara berurutan. Jika segmen dalam file ELF berada dalam urutan berurutan tanpa perataan atau kesenjangan, kode startup OS dapat menggunakan aritmetika penunjuk untuk menemukan awal segmen data. Namun, jika file ELF memiliki tata letak yang berbeda, aritmetika penunjuk tidak menghasilkan alamat yang benar, sehingga kode startup aplikasi tidak boleh mencoba menyalin bagian data. Hal ini dapat menyebabkan masalah jika aplikasi atau RTOS menggunakan bootloader berantai atau perlu menyiapkan canary stack sebelum nol BSS atau menginisialisasi data yang dapat dinonaktifkan.

Target memori

Anda dapat menargetkan kode di TCM, XIP flash, atau SYSRAM dengan mengedit skrip linker.ld untuk aplikasi Anda. Aplikasi sampel Azure Sphere dijalankan dari TCM, tetapi file skrip linker.ld untuk setiap aplikasi menjelaskan cara menargetkan XIP flash sebagai gantinya. Seperti yang diperlihatkan contoh berikut, Anda bisa mengubah sampel untuk dijalankan di XIP dengan aliasing CODE_REGION dan RODATA_REGION menjadi FLASH, bukan TCM default:

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

Untuk menentukan apakah aplikasi terkompilasi berjalan dari TCM atau XIP flash, gunakan arm-none-eabi-readelf.exe, yang merupakan bagian dari Toolchain GNU Arm Embedded. Jalankan di file .out, yang berada di direktori yang sama dengan paket gambar, dan tentukan -l bendera (huruf kecil L) untuk melihat di mana kode dan data baca-saja telah ditempatkan. Kode dan data baca-saja yang ada di memori flash dimuat di alamat 0x10000000; kode dan data dalam TCM dimuat di kawasan TCM.

Contoh berikut ini memperlihatkan aplikasi yang berjalan dari memori 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

Lokasi tabel vektor

Pada perangkat ARMv7-M, tabel vektor harus diratakan pada batas daya dua yang setidaknya 128 byte dan tidak kurang dari ukuran tabel, seperti yang tercantum dalam Panduan Referensi Arsitektur ARMv7-M. Setiap inti I/O RT di MT3620 mendukung 100 interupsi eksternal. Oleh karena itu, termasuk penunjuk tumpukan dan 15 pengecualian standar, tabel memiliki 116 entri 4-byte, untuk ukuran total 464 byte, yang membulatkan hingga 512 byte.

Ketika kode dijalankan dari XIP flash, tabel vektor harus diletakkan di 0x10000000 dan harus diratakan pada batas 32-byte dalam file ELF. Ketika kode tidak dijalankan dari XIP flash, tabel biasanya ditempatkan di awal TCM0, yang 0x100000. Dalam kedua kasus tersebut, untuk memastikan bahwa alamat virtual tabel diratakan dengan benar, letakkan tabel vektor di bagian khusus dan atur CODE_REGION ke alamat yang sesuai.

Sampel MT3620 BareMetal di repository Azure Sphere Samples memperlihatkan cara melakukan hal ini. Deklarasi tabel vektor di main.c mengatur atributnya section ke .vector_table. Alias skrip linker CODE_REGION ke awal TCM atau XIP, dan atribut ALIGN mengatur perataan bagian teks dalam file ELF sebagai berikut:

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

Pertimbangan real-time dan latensi

RTApps dan aplikasi tingkat tinggi bersaing untuk akses ke memori flash, bahkan jika mereka tidak berkomunikasi satu sama lain. Hasilnya, RTApps yang berjalan dari XIP flash mungkin mengalami latensi tinggi dan tak terduga. Menulis untuk berkedip, seperti selama pembaruan, mungkin melibatkan lonjakan latensi hingga beberapa ratus milidetik. Tergantung pada persyaratan aplikasi, Anda dapat mengelolanya dengan beberapa cara:

Masukkan semua kode dan data dalam TCM. Kode yang berjalan dari TCM tidak rentan terhadap konten untuk flash.
Pisahkan kode menjadi bagian penting dan non-kritis, dan jalankan kode non-kritis dari flash. Kode yang memiliki persyaratan real-time, seperti timer pengawas, tidak harus dijalankan ketika kode lain mengakses flash. Target memori menjelaskan cara menargetkan lampu kilat XIP, bukan TCM.
Gunakan cache. Aplikasi dapat menggunakan TCM 32KB terendah sebagai singgahan XIP. Pendekatan ini tidak memberikan jaminan real-time yang sulit jika terjadi cache miss, tetapi meningkatkan kinerja umum tanpa mengharuskan Anda memindahkan semua kode ke DALAM RAM. Lihat "Lembar Data MT3620 M4" untuk informasi tentang konfigurasi cache XIP.

Bagikan melalui