T3-GEM-O1 geliştirme kartının birincil odak noktası Linux olmakla birlikte, üzerinde bulunan Texas AM67 mikroişlemcisinin barındırdığı R5 ve C7x çekirdeklerinin de gücünden faydalanılmaktadır. Bu bölümde R5 çekirdekleri için nasıl yazılım derleneceği, debug yapılacağı vb. konular irdelenecektir.
Bölüm bitiminde aşağıdaki konularda bilgi ve deneyim kazanacaksınız.
  • Texas AM67 MCU yazılımı derleyerek Gemstone Obsidyen üzerinde çalıştırmak
  • Geliştirme kartına ilk güç verildiğinde hangi aşamalarla sistemin başladığını öğrenmek

​
1. MCU Yazılım Geliştirme

MCU projelerini derleyebilmek için gerekli araçlar aşağıda listelenmiştir.
  1. Texas Instruments Processor SDK RTOS J722S
  2. Texas Instruments Sysconfig
  3. Texas Instruments Code Generation Tools C7000
  4. Texas Instruments Code Generation Tools ARM LLVM
Bunları Texas Instruments sitesinden tek tek indirip kurulumlarını gerçekleştirmek zahmetli olduğu için t3gemstone/examples reposunda gerekli tüm araçları indirip MCU projelerini derleyebilmek için altyapı oluşturulmuştur.

​
1.1. Git clone işlemi ile örnek projeleri indir

ubuntu@host:~$ git clone https://github.com/t3gemstone/examples.git
ubuntu@host:~$ cd examples

​
1.2. Derleme için gerekli araçları ve kütüphaneleri kur

ubuntu@host:examples$ ./setup.sh
ubuntu@host:examples$ devbox shell
ubuntu@host:examples$ task fetch-ti

​
1.3. Taslak proje oluştur

t3gemstone/examples reposunda yer alan mcu projesinde iki R5F gerçek zamanlı çekirdek ve iki C7x DSP çekirdeğinde çalışan örnek projeler bulunmaktadır. Bunlara benzer örnekler build/ti/ti-processor-sdk-rtos-j722s-evm-10_01_00_04/mcu_plus_sdk_j722s_10_01_00_22/examples dizininde yer almaktadır. Amacınıza uygun bir örnek proje bulup mcu proje dizinine kopyalamanız ve onun üzerinde geliştirme yapmanız tavsiye edilir. Her bir örnek projenin altında farklı çekirdekler için alt dizinler bulunmaktadır. Örneğin hello_world projesinde aşağıdaki dizinler mevcuttur.
  1. c75ss0-0_freertos
  2. c75ss1-0_freertos
  3. main-r5fss0-0_freertos
  4. mcu-r5fss0-0_freertos
Yazılacak kodlar bu 4 çekirdekten hangisinde çalıştırılmak isteniyorsa o dizinde geliştirme yapılmalı ve o dizindeki derlenmiş çıktılar kullanılmalıdır. Derlenecek MCU projeleri .env dosyasında MCU_TARGETS değişkeni olarak tanımlanmıştır. Derlemek istediğiniz projenin makefile dizininin mutlak veya göreli yolunu MCU_TARGETS değişkenine ekleyin. Aşağıda hello_world projesinin mcu-r5fss0-0_freertos çekirdeği için örnek gösterilmiştir. 
MCU_TARGETS="
ipc_rpmsg_echo_linux/j722s-evm/c75ss0-0_freertos/ti-c7000
ipc_rpmsg_echo_linux/j722s-evm/c75ss1-0_freertos/ti-c7000
ipc_rpmsg_echo_linux/j722s-evm/main-r5fss0-0_freertos/ti-arm-clang
ipc_rpmsg_echo_linux/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang
hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang
"

​
1.4. SysConfig ile çevre birimleri yapılandır

Projenin hangi çevre birimleri (GPIO, I2C, UART vb.) kullandığı ve bunların yapılandırması .syscfg dosyasında tanımlanmıştır. Yeni çevre birimler eklemek veya mevcut olanların Pin Mux ayarlarını değiştirmek için SysConfig GUI aracı kullanılır. Bir MCU projesinde SysConfig’i başlatmak için:
  • SYSCONFIG_TARGET değişkenini istenen proje olarak değiştirin.
    • Bu değişkeni .env dosyası içinde düzenleyebilir veya
    • task programına ortam değişkeni olarak iletebilirsiniz.
SYSCONFIG_TARGET=hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang task sysconfig
Değişikliklerinizi Ctrl + S kısayol tuşuyla kaydettikten sonra SysConfig arayüzünü kapatabilirsiniz.
Linux tarafından R5F ve C7x çekirdeklerine uzaktan yazılım yüklenebilmesi için remoteproc altyapısı kullanılmaktadır. Bir projenin derlenmiş .out dosyasının remoteproc ile yüklenebilmesi için SysConfig arayüzünden bazı ayarların yapılmış olması gerekmektedir. Yeni bir proje kopyalandıktan sonra aşağıdaki adımlar izlenmelidir.
  1. TI DRIVERS altında yer alan IPC sekmesi açılır.
  2. ADD butonuna tıklanır.
  3. Linux A53 IPC RP Message ayarının aktif olduğuna emin olunur.
  4. Ctrl + S kısayol tuşuyla .syscfg dosyası kaydedilip çıkılır.

​
1.5. Projeyi derle

ubuntu@host:examples$ PROJECT=mcu task clean build

​
1.6. Derlenmiş projeyi geliştirme kartına yükle

ubuntu@host:examples$ scp mcu/hello_world/j722s-evm/mcu-r5fss0-0_freertos/ti-arm-clang/hello_world.release.out gemstone@10.0.0.1:

​
1.7. Derlenmiş projeyi çalıştır

Remoteproc ile çekirdeklere yüklenecek .out dosyaları /lib/firmware dizini altına önceden tanımlı isimlerde kopyalanmalıdır. Her bir çekirdek için firmware ismi aşağıdaki tabloda verilmiştir.
CoreFirmware
mcu-r5fss0-0j722s-mcu-r5f0_0-fw
main-r5fss0-0j722s-main-r5f0_0-fw
c7xss0-0j722s-c71_0-fw
c7xss1-0j722s-c71_1-fw
Firmware isimlerine ve hangi çekirdeğin hangi remoteproc cihazına karşılık geldiğine head /sys/class/remoteproc/remoteproc*/firmware komutu ile erişilebilir. Her boot sonrasında çekirdekler farklı remoteproc cihazlarına karşılık gelebildiği için kontrol edilmesi gerekmektedir.
Yukarıdaki prosedür, uzak çekirdeklerin sorunsuz bir şekilde kapatılmasını ve yeniden başlatılmasını sağlar. Bazı durumlarda sorunsuz kapatma işlemi başarısız olabilir. Bu durumda şu adımları öneririz:
  1. Yeni firmware dosyalarını /lib/firmware dizinine yerleştirin.
  2. Kartı yeniden başlatın.
Sistem başlangıcında, remoteproc mekanizması firmware’leri ilgili çekirdeklere otomatik olarak yükleyecektir.Not: Bu yaklaşım özellikle şu durumlarda kullanışlıdır:
  • Çekirdek çökmeleri yaşandığında
  • IPC iletişimi kesildiğinde
  • Dinamik yükleme sırasında beklenmeyen davranışlar gözlemlendiğinde

​
2. Boot Diyagramı

Aşağıda belirtilen akış şeması Gemstone Obsidyen geliştirme kartı için olmakla birlikte bir çok ARM mimarili gömülü Linux geliştirme kartlarında benzer bir yapı bulunmaktadır.

​
2.1. ROM Bootloader (RBL)

Üreticiler tarafından çoğu zaman kaynak kodları verilmeden sadece derlenmiş program olarak dağıtılan RBL (Room Bootloader)‘in temel amacı; karta ilk enerji verildiğinde donanım sağlık kontrolleri ve ilklendirme vb. işlemleri yaparak, kaynak kodları değiştirilebilir olan SBL (Secondary Bootloader) isimli ikinci Bootloader’a geçiş yapmaktır. SBL’in nereden okunarak başlatılacağı ise RBL tarafından Bootmode switchlerinden tespit edilir.

​
2.2. Secondary Bootloader (SBL)

Secondary Boot Loader’un T3-GEM-O1 geliştirme kartlarındaki kullanım amacı U-Boot isimli daha gelişmiş Bootloader’ı başlatmak ve Gemstone Imager isimli uygulama aracılığıyla imajların eMMC’ye yazılmasını sağlamaktır. Linux Kernel içeren gömülü kartlarda çoğunlukla U-Boot tercih edilmektedir. SBL gibi ön yükleyiciler daha temel seviyede ilklendirme işlemleri yapabilirken, U-Boot çok daha gelişmiş özelliklere sahiptir. Örneğin U-Boot kendi Terminal/Konsol arayüzüne ve SBL’de mümkün olmayan bir çok sürücüye sahip olduğu için daha gelişmiş özelleştirmelere imkan sağlar.

​
2.3. U-Boot

SBL sonrası geliştirme kartının kontrolünü devralan U-Boot, Device Tree’de tanımlanmış olan konfigürasyonlara göre ilgili donanımların sürücülerini aktifleştirir ve ön tanımlı bir takım komutları çalıştırarak Linux Kernel, Initrd gibi bileşenleri RAM’e yükleyerek kontrolü Linux Kernel’e devreder.

​
2.3.1. U-Boot Konsol Alıştırmaları

Bu kısımda Gemstone geliştirme kartına TTL aracılığıyla bağlanılıp U-Boot konsol kullanımı gösterilmiştir. Aşağıda bulunan dokümanlara hızlıca göz gezdirebilirsiniz.

Todo: U-Boot TTL

​
2.4. Linux Kernel

Device Tree’de tanımlanan donanımların sürücülerini yükler. Ardından varsa initrd’yi/initramfs’i başlatır ve rootfs’te bulunan init programını çalıştırır.
U-Boot ve Linux kernelin device tree dosyaları birbirinden farklıdır. U-Boot’taki devicetreede genellikle sadece kernel ve initramfs’i çeşitli depolama aygıtlarından (MMC, SSD, SPI flash, …) RAM’e yüklemeye yetecek kadar donanım aktif edilir. Asıl donanım aktif etme işlemlerini kernel yapar.

​
2.5. Initial RAM Disk (Initrd)

Rootfs başlatılmadan önce çeşitli kernel modüllerini yükleme, disk şifresini çözme, yazılım güncellemesi yapma gibi ara işlemleri gerçekleştirmeyi sağlayan ve RAM üzerinde bulunan geçici dosya sistemidir.
Rootfs diskte şifreli olarak tutuluyorsa, kernel direkt olarak init programını başlatamaz. Öncelikle disk şifresinin initramfs tarafından çözülmesi gerekir.

​
2.6. Root Filesystem (Rootfs)

Initrd, işlemlerini bitirdikten sonra rootfs olarak adlandırılan; sistem ve kullanıcı programlarını, kütüphaneleri ve çeşitli konfigürasyon dosyalarını içeren dosya sistemini / dizinine bağlar. Ardından kernel, rootfs’te /init, /sbin/init ya da benzeri bir dizinde bulunan init programını çalıştırır. Bu program, bazı donanımların sürücülerini yükler (kernel modüllerini), sistem servislerini (ağ bağlantısı, saat senkronizasyonu, paket güncelleme ve bluetooth gibi servisleri) ve masaüstü ortamını başlatır (gnome, kde, xfce, …).

​
3. Son

Boot süreci hakkında bir kaç makale örneği aşağıda verilmiştir.