Mereka yang mengikuti proyek kami mungkin telah memperhatikan bahwa folder e2k telah muncul di direktori dengan arsitektur, yang berisi dukungan untuk prosesor dalam negeri dengan
arsitektur Elbrus .
Serangkaian artikel tentang porting
Embox ke platform domestik tidak akan lengkap tanpa cerita tentang arsitektur ini.
Saya akan membuat beberapa komentar pada isi artikel. Pertama, proses penguasaan arsitektur ini oleh kami adalah pada tahap awal, kami berhasil meluncurkan Embox pada platform ini, tetapi kami belum mengimplementasikan banyak bagian yang diperlukan, yang akan dibahas dalam publikasi mendatang. Kedua, arsitektur ini kompleks, dan
deskripsi terperinci membutuhkan lebih banyak teks daripada format yang dibolehkan
satu artikel. Karena itu, kami sarankan untuk menggunakan artikel ini sebagai pengantar,
berisi informasi teknis minimum tentang arsitektur itu sendiri.
Mari kita mulai.
Objek Penelitian - Tata Letak Sistem Tertanam pada Elbrus
Karena kami terlibat dalam Embox (dan jika ada yang tidak sadar, itu difokuskan pada embedded system), kami terutama tertarik pada opsi bahwa MTsST sendiri diposisikan, termasuk untuk embedded system. Beralih ke MCST kami menemukan bahwa perusahaan tertarik menggunakan prosesor untuk sistem embedded. Salah satu solusi terbaru untuk segmen ini adalah
papan E4C-COM . Dalam proses berkomunikasi dengan MCST, menjadi jelas bahwa untuk porting dan menguasai arsitektur, Anda dapat menggunakan salah satu mesin yang tersedia, dan kami diberi komputer yang disebut
Temperament untuk penggunaan sementara. Secara umum, monocube tidak cukup seperti yang kita terbiasa dalam sistem embedded. Biasanya, sistem tertanam menggunakan komputer papan tunggal, chip - sistem pada chip atau bahkan mikrokontroler, tetapi monocube adalah komputer yang lengkap, tetapi karena telah diuji dalam “iklim dan mekanika”, masih dapat dianggap sebagai sistem tertanam.
Kompiler, bangun, isi gambar
Setelah menerima unit sistem, muncul pertanyaan secara alami - bagaimana cara mengisi gambar. MCST menggunakan BIOS-nya sendiri (pemuat boot sistem tingkat pertama). Secara default, OS Elbrus diinstal (mis. Debian dengan modifikasi). Kami tertarik untuk meluncurkan citra kami sendiri. Untungnya, loader MTST dapat menjalankan gambar melalui jaringan. Untuk melakukan ini, gunakan
protokol ATA over Ethernet .
Setelah kami dibantu untuk membuat dudukan dan meluncurkan gambar eksternal melalui jaringan, kami mulai mengembangkan gambar kami sendiri. Untuk melakukan ini, kami memerlukan kompiler. Kami tidak menemukan kompiler di domain publik, tetapi karena kami menandatangani NDA, kami diberi binari untuk Linux. Kompiler ternyata sangat kompatibel dengan gcc, dan kami tidak perlu mengubah apa pun, tentu saja, dengan pengecualian pada flag kompilasi, yang kami letakkan dalam file konfigurasi terpisah. Yang sangat mudah ditebak, karena Linux, walaupun dengan modifikasi, dirakit oleh kompiler ini.
Beberapa pertanyaan teknis
Mereka yang terlibat dalam kegiatan spesifik seperti porting OS ke platform tahu bahwa hal pertama yang harus dilakukan adalah menempatkan kode program dengan benar dalam memori. Yaitu, tulis skrip tautan (lds) dan terapkan kode mulai. Kami dengan cepat menemukan skrip tautan, tetapi ketika menerapkan kode awal, kami dihadapkan dengan sihir pertama, yang kami tidak sepenuhnya mengerti. Faktanya adalah bahwa Elbrus memiliki mode kompatibilitas x86 dan pada 0x00FF0000 ada kode yang saya hanya akan memberikan
tautan , karena kami meminjamnya dari contoh MCST. Skrip tautan berisi
.bootinfo : { _bootinfo_start = .; *(.x86_boot) . = _bootinfo_start + 0x10000; _bootinfo_end = .; } SECTION_REGION(bootinfo) .text : { _start = .; *(.e2k_entry);
Kode starter itu sendiri bahkan tidak ditulis dalam assembler, tetapi hanya dalam
C. Itu diletakkan di bagian yang terletak di 0x01000000, yang, omong-omong, sesuai dengan alamat awal mesin x86 biasa - di sana pada alamat ini terletak header
multiboot atau header lainnya.
Untuk memastikan kode awal dan alamat sudah benar, Anda perlu mendapatkan beberapa keluaran. Jika Anda dapat mencetak karakter apa pun, maka kemungkinan besar tidak akan ada masalah dengan output string. Dengan menggunakan output ini, sudah dimungkinkan untuk menggunakan printf () yang familier untuk debugging. Selain itu, sebagian besar platform memberikan kemampuan untuk menampilkan karakter dengan membuat entri sederhana dalam register tertentu (karena bootloader kemungkinan besar mengkonfigurasi UART sesuai kebutuhan).
Komputer kami menggunakan pengontrol port serial am85c30 (alias
z85c30 kami cukup cepat menemukan cara mencetak satu karakter, dan ini sudah cukup untuk printf kami berfungsi. Kami segera menghadapi masalah aneh - beberapa karakter yang dicetak oleh printf tampaknya digandakan, tetapi kadang-kadang campur aduk. Misalnya, ketika saya mencoba untuk output Halo, dunia! Ternyata seperti Hhelellloo ,, woworrlldd. Sekarang tampak jelas bahwa masalahnya adalah multi-core, tetapi pada awalnya kami menyodok pada driver itu sendiri. + (1891VM7YA) ( empat core DSP tidak masuk hitungan) dan bootloader mengaktifkan semua core prosesor. Akibatnya, agar tidak mengacaukan dengan multicore (SMP), semua core kecuali yang pertama dikirim ke loop tak terbatas. Untuk melakukan ini, kami memperkenalkan variabel untuk nomor prosesor dan menambahkannya menggunakan penambahan atom. Inti nol terus bekerja, sementara kernel lainnya berputar.
cpuid = __e2k_atomic32_add(1, &last_cpuid); if (cpuid > 1) { while(1); } memcpy((void*)0, &_t_entry, 0x1800); kernel_start();
Panggilan kernel_start () sudah menjadi transfer kontrol ke kode kami.
Kami juga meminjam penambahan atom, bagi kami itu terlihat seperti sihir. Tapi, seperti yang Anda tahu, itu berfungsi - jangan sentuh!
#define WMB_AFTER_ATOMIC ".word 0x00008001\n" \ ".word 0x30000084\n" #define __e2k_atomic32_add(__val, __addr) \ ({ \ int __rval; \ asm volatile ("\n1:" \ "\n\tldw,0 %[addr], %[rval], mas=0x7" \ "\n\tadds %[rval], %[val], %[rval]" \ "\n\t{"\ "\n\tstw,2 %[addr], %[rval], mas=0x2" \ "\n\tibranch 1b ? %%MLOCK" \ "\n\t}" \ WMB_AFTER_ATOMIC \ : [rval] "=&r" (__rval), [addr] "+m" (*(__addr)) \ : [val] "ir" (__val) \ : "memory"); \ __rval; \ })
Keajaiban lain yang harus saya pinjam adalah beberapa kode, yang diperlukan untuk semua core. Yaitu
static inline void e2k_wait_all(void) { _Pragma ("no_asm_inline") asm volatile ("wait \ttrap = %0, ma_c = %1, fl_c = %2, ld_c = %3, " "st_c = %4, all_e = %5, all_c = %6" : : "i" (0), "i" (1), "i" (1), "i" (0), "i" (0), "i" (1), "i" (1) : "memory"); }
Sebagai hasilnya, setelah menulis kode startup, kami tidak hanya menampilkan pesan menggunakan printk, tetapi juga mulai memuat modul, yang umumnya tidak terlalu sepele karena kompiler yang tidak cukup standar. Jadi sekali lagi saya perhatikan bahwa kompatibilitas kali ini dengan gcc sangat senang.
Langkah selanjutnya adalah memulai pengendali dan penghitung waktu interupsi, tetapi setelah berpikir bahwa kami harus menerapkan tidak hanya dukungan untuk perangkat ini, tetapi juga kode arsitektur untuk penangan interupsi, kami memutuskan bahwa kami dapat mulai dari pinggiran. Monocub memiliki bus PCIe, untuk programmer sepertinya PCI biasa. Kami terutama tertarik pada dua perangkat: pengontrol tampilan dan pengontrol jaringan.
Monocube menggunakan pengontrol grafis dari seri
sm750 . Ini adalah pengontrol grafis untuk aplikasi tertanam, memiliki dukungan onboard untuk grafis 2d. Chip disolder langsung ke motherboard, seperti yang saya mengerti. Sumber untuk driver untuk Linux dapat ditemukan di
sini .
Setelah driver ditemukan, sepertinya masalah kami sudah selesai, hanya tinggal mengimplementasikan controller untuk PCI. lebih tepatnya, baca / tulis operasi ruang konfigurasi PCI untuk mengetahui parameternya. Implementasi fungsi-fungsi ini harus dipinjam lagi. Akibatnya, membaca catatan turun ke makro suka
#define _E2K_READ_MAS(addr, mas, type, size_letter, chan_letter) \ ({ \ register type res; \ asm volatile ("ld" #size_letter "," #chan_letter " \t0x0, [%1] %2, %0" \ : "=r" (res) \ : "r" ((__e2k_ptr_t) (addr)), \ "i" (mas)); \ res; \ }) #define _E2K_WRITE_MAS(addr, val, mas, type, size_letter, chan_letter) \ ({ \ asm volatile ("st" #size_letter "," #chan_letter " \t0x0, [%0] %2, %1" \ : \ : "r" ((__e2k_ptr_t) (addr)), \ "r" ((type) (val)), \ "i" (mas) \ : "memory"); \ })
Ada beberapa pemahaman tentang apa yang terjadi. Elbrus memiliki beberapa ruang alamat alternatif, seperti, misalnya, dalam
arsitektur SPARC . Identifikasi dilakukan menggunakan pengidentifikasi ruang alamat. Artinya, perintah ld yang sama sampai ke alamat internal yang berbeda, juga menghasilkan operasi baca dengan panjang yang berbeda (8, 16, 32, 64 bit). Jika dalam SPARC ini adalah perintah lda / sta yang terpisah, maka di Elbrus karena parameternya, ini adalah perintah ld. Jendela
register dipinjam dari arsitektur SPARC. Saya akan menunda cerita yang lebih rinci untuk artikel selanjutnya.
Akibatnya, semuanya berubah dengan PCI. Kami bisa mendapatkan semua data yang diperlukan, mentransfer driver grafis ke diri kami sendiri, tetapi kemudian kami mengalami masalah berikut. Untuk menggambar di memori video, Anda harus menulis dua kali. Semuanya menunjuk ke cache. Untuk mengatasi masalah ini, perlu untuk berurusan dengan MMU, dan ini, seperti yang mereka katakan, tidak dapat diselesaikan dengan condachka, karena, pada prinsipnya, banyak masalah lain yang kami temui dan akan temui lebih dari satu kali selama pengembangan arsitektur ini.
Kami telah berkembang ke arah lain: gangguan dan panggilan sistem, tetapi kami juga akan membicarakan hal ini di artikel subseries berikutnya. Pada akhir artikel ini, saya hanya akan membawa output ke konsol (melalui port serial).
Kesimpulan
Seperti yang saya katakan di bagian pendahuluan, saya ingin fokus terutama bukan pada detail teknis, tetapi pada perasaan umum. Jadi, perasaan itu kontradiktif, meski tentu lebih positif. Di satu sisi, prosesor ada dan sangat menarik dalam hal fitur arsitektur. Berdasarkan prosesor ini, sistem komputer diproduksi, ada perangkat lunak dengan kualitas yang cukup tinggi. Seperti yang saya katakan, tidak ada keluhan tentang kompiler (sampai titik tertentu, yang akan saya jelaskan nanti), ada Linux penuh (OS "Elbrus"). Saya pribadi melihat bagaimana di ICST itu sendiri, pengembang dibuat langsung di desktop dengan arsitektur Elbrus.
Tetapi di sisi lain, saya tidak mengerti mengapa dengan kegigihan seperti itu mereka mencoba melakukan penggantian dangkal Intel x86 dari prosesor ini. Memang, tidak ada tempat di dunia yang mereka gunakan prosesor berdasarkan arsitektur
VLIW sebagai komputer pribadi universal. VLIW, karena fitur arsitekturnya, adalah “penghancur angka” yang keren, mereka membuat DSP di sana, mereka membuat server itanium, mereka membuat kartu grafis. Tidak, dengan excavator, tentu saja, Anda bisa menggali lubang untuk menanam pohon, tetapi apakah itu layak dilakukan.
Masalah utama yang menghambat pengembangan arsitektur, menurut saya, adalah sifat tertutup dari keseluruhan ekosistem. Ya, untuk mendapatkan deskripsi sistem perintah, Anda hanya perlu menandatangani NDA, tetapi ini tidak cukup. Arsitekturnya tidak dikenal dan sangat kompleks. Ya, saya selalu berpikir bahwa beberapa perangkat lunak dasar harus dikembangkan langsung dari produsen prosesor, baik, atau dalam kerja sama yang erat dengannya. Menurut prinsip ini, PC pada Elbrus memiliki paket perangkat lunak dengan
OS Elbrus . Tetapi masih terlalu naif untuk percaya bahwa satu perusahaan, bahkan yang besar, dapat memberikan dukungan kualitas untuk semua komponen: prosesor, kompiler, alat pengembangan dan debugging, perangkat lunak sistem (berbagai OS), perangkat lunak aplikasi, ... bahkan Intel tidak dapat melakukannya. Dunia telah lama bergerak menuju apa yang disebut kolaborasi atau pengembangan bersama.
Biarkan saya memberi Anda contoh masalah kompiler yang kami temukan. Driver port serial di beberapa titik berhenti menampilkan karakter, dan, pada pandangan pertama, tidak ada yang berubah. Ternyata kami menghapus fungsi debugging yang tidak digunakan, yang kami masukkan untuk memahami melalui disassembler cara meneruskan argumen ke fungsi di assembler. Artinya, jika fungsinya hadir, semuanya baik-baik saja, jika tidak, maka output menghilang. Pada awalnya mereka berdosa untuk penyelarasan, tetapi ternyata fungsinya dapat ditransfer ke akhir C-Schnick, sehingga semua karakter dari pengemudi berada di tempat yang sama seperti sebelumnya, tetapi masalahnya direproduksi. Meskipun masalah ini belum terpecahkan, kami terus menyelidiki untuk menunjukkan kepada pengembang kompiler dari MCST atau untuk memahami di mana kami membuat kesalahan.
Masalah di atas, menurut saya, bisa dihindari jika ada lebih banyak pengguna pihak ketiga. Minimal, masalah akan terungkap lebih awal, atau, orang hanya bisa google apa yang kami lakukan salah.
ICST juga menyadari masalah penutupan, karena proses pembukaan hal-hal yang tidak rahasia telah dimulai. Sebagai contoh, saya melihat Alt-Linux bekerja pada beberapa PC Elbrus di beberapa konferensi. Berikut adalah gambar tampilan dari salah satu konferensi tahun ini (maaf melihat buruk, itu gelap). Kami juga terhubung dengan pengembangan. Kami berharap bahwa kami akan berguna bagi ICST, karena, ternyata, beberapa hal penting dari arsitektur Elbrus tidak dapat didukung di Linux (atau biayanya sangat besar), misalnya, memori yang ditandai.
Poin penting lainnya ketika kami membahas masalah penutupan dengan pengembang MCST, mereka keberatan bahwa, misalnya, sumber kernel Linux terbuka untuk waktu yang lama, tetapi hanya kami dan pengembang Dolomant yang mengajukan pertanyaan dan menggunakannya entah bagaimana.
Selain itu, menurut informasi saya, MCST akan mengatur pendirian
dapat diakses dari jarak jauh. Di mana dimungkinkan untuk merakit dan menjalankan perangkat lunak pada PC dengan arsitektur Elbrus. Jika ada minat yang sama dan Anda ingin menggunakan dudukan, maka Anda harus menghubungi, misalnya, untuk saya: jelaskan bagaimana rencananya menggunakannya, berapa lama dan seterusnya, karena untuk berbagi dengan mengubah perangkat lunak, Anda perlu mengatur jadwal. Saya akan mentransfer data ke ICST atau saya akan menghubungkan mereka yang ingin dengan penyelenggara.
Tautan yang bermanfaat:
Alamat surat untuk pengguna adalah pengguna [at] mcst.ru
Penjelasan singkat tentang arsitektur ElbrusSumber emboxPS Kami akan menunjukkan kepada semua orang yang menginginkan apa yang kami dapatkan di festival IT
TechTrain pada 1-2 September.