AM67A'da Linux + Cortex-R5F: Gerçek Zamanlı Kontrolü Ayırmak

Heterojen bir SoC'de asıl mühendislik işi, çekirdek seçmek değil sınır çizmektir. TI AM67A'da Linux dört Cortex-A53 çekirdeğinde koşar; ayrı alanlara yerleştirilmiş Cortex-R5F çekirdekleri ise farklı bir zamanlama sözleşmesi sunar. Bu yazı, iki tarafın arasına çizilecek sınırın nereden geçmesi gerektiğini, köprünün (remoteproc ve rpmsg) nasıl kurulduğunu ve bu mimaride en sık yapılan altı hatayı ele alıyor. Amaç bir kurulum rehberi değil; bölüşüm kararını doğru vermek. Yazıda Spikedge tarafından yapılmış bir AM67A ölçümü yer almaz; ölçülmesi gerekenler ayrı bir bölümde listelenmiştir.

Önce yanlış soruyu eleyelim

"Linux gerçek zamanlı mıdır?" sorusu, bu tartışmayı her seferinde yanlış yere götürür. Doğru soru şudur: görevinizin kaçırılan bir teslim tarihinde ne olur?

Üç ayrı sözleşme vardır ve üçü aynı şey değildir:

• Ortalama hızlı olmak. Standart bir Linux zamanlayıcısı bunu iyi yapar. Verim odaklı işlerde yeterlidir.
• Genellikle zamanında olmak. PREEMPT_RT, CPU izolasyonu, IRQ affinity ve öncelik ayarlarıyla Linux buraya taşınabilir. Bu gerçek bir mühendislik işidir ve ölçümle doğrulanır. Yaklaşımı PREEMPT_RT çekirdek yapılandırması rehberimizde anlatıyoruz.
• Her zaman zamanında olmak. Kaçırılan tek bir döngünün fiziksel bir sonucu varsa — eksen kayması, güvenlik zinciri, yanma riski — kanıt yükü değişir. Burada ihtiyacınız olan şey ortalama değil, en kötü durumdur ve en kötü durumu ancak üzerinde başka hiçbir şeyin koşmadığı bir alanda savunabilirsiniz.

AM67A'daki R5F alanının varlık nedeni üçüncü kategoridir. R5F, A53'ten hızlı olduğu için değil, öngörülebilir olduğu için vardır: kendi TCM'i (sıkı bağlı bellek), kendi kesme denetleyicisi, kendi saat alanı ve — MCU alanındaki çekirdek için — kendi 512 KB SRAM'i. Sayfa hatası yok, sayfa değiştirme yok, başka bir kullanıcı alanı işlemiyle rekabet yok.

Buradaki nüans önemlidir: R5F "hard real-time garantisi" satmaz. Determinizmi mümkün kılan bir donanım zemini sunar. Garantiyi kuran şey sizin tasarımınızdır — kesme öncelikleri, en kötü durum çalışma süresi analizi, kilitlenmeyen veri yapıları ve ölçüm.

AM67A'da alanlar nasıl bölünmüş?

AM67A dört ayrı işlem alanı taşır: Cortex-A53 uygulama alanı, karışmama (FFI) niyetiyle konumlandırılmış MCU alanı ve bir R5F çekirdeği, ana alandaki bir R5F, ve cihaz yönetimi için ayrılmış bir R5F. Bunların ayrıntılı dökümünü ve datasheet'in bu çekirdekleri iki farklı sözlükle adlandırmasından doğan karışıklığı TI AM67A SoC mimarisi yazımızda ele aldık.

Bu yazı açısından asıl soru şudur: bu üç R5F'ten hangisi sizin?

Datasheet bu soruyu cevaplamaz; okuyucuyu Software Build Sheet belgesine yönlendirir. Cevabı SDK tarafında aramak gerekiyor ve orada net:

Yani üç çekirdekten ikisi size açıktır, üçüncüsü sistemi ayakta tutan TI firmware'ini çalıştırır ve uygulama kodu için planlanmaz. Linux tarafındaki remoteproc örnekleri de bu iki R5F'i (ve iki C7x'i) uzak işlemci olarak listeler.

Bir noktayı da kapatalım: bu çekirdeklerde lockstep yoktur. Teknik referans kılavuzu üç R5F alt sisteminin her biri için "desteklenmeyen özellikler" başlığı altında lockstep'i açıkça sayar. "FFI" (freedom from interference) bir yalıtım kavramıdır; iki çekirdeğin aynı komutu birlikte yürütüp sonucu karşılaştırması anlamına gelmez. Donanımdan gelen çift yürütme garantisi bekleyen bir tasarım, bu parçada o garantiyi bulamaz.

Bölüşüm planını yapmadan önce cevaplanması gereken ilk soru budur; sonradan öğrenmenin bedeli mimarinin yeniden kurulmasıdır.

Hangi görev nereye? Dört soruluk eleme

Görevleri tek tek şu dört sorudan geçirin. Sıra önemlidir; ilk "evet" cevabı kararı verir.

1. Kaçırılan bir teslim tarihinin fiziksel bir sonucu var mı? Motor komutu, güvenlik kilidi, tetikleyici zamanlama, senkron örnekleme. Cevap evetse görev R5F alanına gider. Tartışma burada biter.

2. Görev mikrosaniye mertebesinde bir kesmeye mi bağlı? Enkoder darbesi, yakalama girişi (eCAP), harici tetik. AM67A'da eCAP, eQEP ve ePWM modülleri üçer adettir; bu çevre birimlerini kullanan bir döngünün Linux kullanıcı alanından sürülmesi, kazanacağınızdan fazlasını jitter olarak geri verir. R5F.

3. Görev zengin bir kütüphaneye mi ihtiyaç duyuyor? TLS yığını, veritabanı, ROS 2, dosya sistemi, ağ protokolü, model çalışma zamanı. Cevap evetse A53. Bu kütüphaneleri R5F'e taşımak teknik olarak mümkün olabilir ama bakım maliyeti neredeyse her zaman kazancı aşar.

4. Görev veri hacmi büyük ama teslim tarihi yumuşak mı? Video, kayıt, telemetri, model çıkarımı. A53 ve hızlandırıcılar. Bu işleri R5F'e vermek onun asıl işini bozar.

Kalan gri bölge — "önemli ama fiziksel sonucu yok" — genellikle A53'e aittir. Bir görevi R5F'e taşımanın bir maliyeti vardır: iki ayrı derleme hattı, iki ayrı hata ayıklama ortamı, iki ayrı yaşam döngüsü ve aralarında bir protokol. Bu maliyet ancak birinci veya ikinci sorunun cevabı "evet" olduğunda haklı çıkar.

Spikedge görüşü: Bölüşüm hatalarının çoğu R5F'i az kullanmaktan değil, fazla kullanmaktan doğar. R5F tarafına konan her ek görev, en kötü durum analizinin kapsamını genişletir ve o çekirdeğin varlık sebebini aşındırır. R5F'i bir "ikinci CPU" değil, tek işi olan bir cihaz gibi tasarlayın.

İki alan arasındaki köprü: remoteproc ve rpmsg

Linux tarafında uzak işlemciler iki katmanla yönetilir.

remoteproc, uzak çekirdeğin yaşam döngüsünü yönetir: firmware imajını belleğe yerleştirmek, çekirdeği resetten çıkarmak, durdurmak, çökme durumunda kurtarmak. Firmware ELF'inin içindeki resource table, çekirdeğin hangi bellek bölgelerine (carveout) ihtiyaç duyduğunu, hangi vring'leri kullanacağını ve trace tamponunun nerede olduğunu Linux'a bildirir. Bu tablo, iki tarafın bellek haritası üzerinde anlaştığı yerdir; sessiz hataların büyük kısmı burada doğar.

rpmsg, remoteproc'un kurduğu virtio kanalları üzerinde mesajlaşma sağlar. Paylaşımlı bellekteki halka tamponlarını ve bir posta kutusu (mailbox) kesmesini kullanır: bir taraf mesajı yazar, kapı zilini çalar, diğer taraf uyanır.

Bu ayrımı bilmek pratikte şu işe yarar: rpmsg her iş için doğru araç değildir. Kontrol komutları, durum bildirimi, parametre güncellemesi ve hata raporu için doğru soyutlamadır — kanal isimlendirmesi, akış kontrolü ve bağlantı yönetimi hazır gelir. Ama döngü başına birkaç yüz bayt taşıyan, mikrosaniye bütçesi olan bir veri yolu için rpmsg'nin kopyalama ve kuyruk semantiği gereksiz yüktür.

Yaygın ve sağlıklı desen ikisini birden kullanmaktır:

Paylaşımlı bellek: asıl tasarım kararı burada

Paylaşımlı belleği "iki tarafın da eriştiği bir dizi" olarak düşünmek, bu mimarideki en pahalı basitleştirmedir. Üç ayrı konu var.

Önbellek tutarlılığı. A53 tarafı belleği önbellekli görür; R5F tarafı kendi görüşüne sahiptir. Aynı bölgeyi iki taraf da önbellekli okuyup yazarsa, veri "bazen" yanlış olur — ve bu tür hatalar test ortamında değil, sahada yük altında ortaya çıkar. İki savunulabilir yol vardır: bölgeyi bir tarafta önbelleksiz haritalamak (basit, yavaş) veya her erişimde açık önbellek bakımı yapmak (hızlı, disiplin ister). Ortası yoktur.

Yırtılma (torn read). İki 32 bit alan iki ayrı yazma ile güncelleniyorsa, okuyan taraf birini eski birini yeni görebilir. Kilit kullanmadan bunu çözmenin standart yolu seqlock benzeri bir sayaç desenidir: yazar başlarken sayacı tek yapar, bitirince çift; okuyucu sayacı önce ve sonra okur, değişmişse tekrar dener. Bir diğer yol çift tamponlamadır: yazar pasif tamponu doldurur, sonra tek bir atomik indeks yazımıyla takas eder.

Sahiplik. Her paylaşımlı alanın tek bir yazarı olmalıdır. İki tarafın da yazdığı bir alan, er ya da geç bir kilit gerektirir; bir kilit ise R5F tarafında sınırsız bekleme demektir ve en kötü durum analizinizi çöpe atar. Sahiplik tek yönlü olacak biçimde iki ayrı alan kullanın.

Altı anti-pattern

Bu mimaride tekrar tekrar karşılaşılan hatalar, sırasıyla en pahalıdan başlayarak.

1. R5F'i ikinci bir uygulama işlemcisi sanmak. Belirti: R5F firmware'i büyümeye başlar, içine kayıt, ağ, dosya erişimi girer. Sonuç: en kötü durum çalışma süresi artık hesaplanamaz. R5F'in işi tek ve sınırlı olmalıdır.

2. Kritik yolu rpmsg üzerine kurmak. Belirti: kontrol döngüsü her iterasyonda Linux'tan mesaj bekler. Sonuç: döngünün en kötü durumu Linux'un en kötü durumuna eşitlenir; R5F'i kullanmanın anlamı kaybolur. Kritik döngü, Linux tamamen durduğunda bile güvenli biçimde çalışmaya devam edebilmelidir.

3. Sınırı işleve göre değil, kodun mevcut yerine göre çizmek. Belirti: "bu fonksiyon zaten C ile yazılmıştı, R5F'e taşıyalım." Sonuç: gerçek zamanlı alan, alakasız kodla dolar. Sınır, teslim tarihi sözleşmesine göre çizilir.

4. Başlatma sırasını varsaymak. Belirti: R5F firmware'i Linux'un bir yapıyı hazırlamış olmasını bekler ya da tersi. Sonuç: soğuk açılışta çalışan sistem, sıcak resette veya remoteproc yeniden başlatmasında kilitlenir. İki taraf da karşı taraf yokken tanımlı bir durumda beklemelidir; el sıkışma açık olmalıdır.

5. Linux çöktüğünde ne olacağını tasarlamamak. Belirti: A53 tarafı yeniden başlatılınca R5F'in paylaşımlı bellekteki durumu geçersizleşir, ama kimse bunu fark etmez. Sonuç: eski setpoint ile çalışmaya devam eden bir aktüatör. Her paylaşımlı yapıda bir tazelik göstergesi (sayaç veya zaman damgası) ve R5F tarafında bir zaman aşımı davranışı olmalıdır.

6. Ölçmeden "deterministik" demek. Belirti: mimari doğru kurulmuştur, kimse gecikme dağılımına bakmamıştır. Sonuç: ortalama iyi, kuyruk kötü. Bu mimaride önemli olan ortalama değil, p99 ve en kötü durumdur; ikisini gösteren tek şey ölçümdür.

Gecikme bütçesini kurmak

Bir kontrol döngüsünde "gecikme" tek bir sayı değildir. Bütçeyi parçalarına ayırmadan iyileştirme yapılamaz:

1. Kaynak olayı — enkoder darbesi, tetik, zamanlayıcı taşması.
2. Kesme gecikmesi — olaydan kesme servis rutininin ilk komutuna kadar.
3. Servis süresi — okuma, hesap, yazma.
4. Aktüatöre çıkış — çevre birimi üzerinden fiziksel çıkış.
5. (Varsa) alanlar arası aktarım — R5F ile A53 arasındaki köprü.

İlk dört adım R5F alanında kalırsa bütçe küçük ve dar dağılımlıdır. Beşinci adım kritik yola girdiği anda bütçe, Linux tarafının en kötü durumunu içerir. Mimarinin bütün amacı, beşinci adımı kritik yolun dışında tutmaktır.

Bu ayrımı bir tabloya oturtmak, tartışmayı somutlaştırır:

Ne ölçülür, nasıl ölçülür?

Bu mimaride yayımlanmaya değer her sayı, üç şeyle birlikte anlam kazanır: hangi kurulumda, hangi yöntemle, kim ölçtü. Üçünden biri eksikse sayı yayımlanmaz. Kendi ölçüm disiplinimizi somut bir örnekle EtherCAT ölçüm metodolojisi yazısında anlatıyoruz; aynı disiplini bir R5F alanı için kurmak isterseniz asgari küme şudur:

• R5F kesme gecikmesi. Harici bir tetiğe karşı GPIO darbesi, osiloskopla, en az bir gece boyunca. Ortalama değil histogram. Yöntemi STM32'de IRQ gecikmesi ölçümü rehberimizde ayrıntılandırıyoruz; ölçüm mantığı işlemciden bağımsızdır.
• Döngü kaçırma sayacı. Firmware içinde, dışarıdan okunabilir bir sayaç. Sıfırdan farklı her değer bir bulgudur.
• Alanlar arası gidiş-dönüş. Her iki uçta senkronize zaman damgası; boşta ve tam yük altında ayrı ayrı.
• Yük altında bozulma. A53 tarafında AI çıkarımı, NVMe yazma ve ağ trafiği aynı anda koşarken yukarıdaki üç ölçümün nasıl değiştiği. Boştaki sayı hiçbir şey anlatmaz.
• Soğuk açılıştan kontrolün hazır olmasına kadar süre. R5F firmware'inin ne zaman ayağa kalktığı, Linux'un hazır olmasından bağımsız olarak ölçülmeli.
• Kurtarma davranışı. remoteproc ile R5F'i çalışırken durdurup yeniden başlatın. Sistem tanımlı bir duruma mı düşüyor, yoksa belirsiz bir duruma mı?

Bu mimariyi ne zaman kurmamalı?

Alanlar arası bölüşüm ücretsiz değildir. Şu durumlarda tek alanda kalmak daha doğru bir karardır:

• Sıkı zamanlı görev yoksa. Yumuşak teslim tarihleri PREEMPT_RT ile karşılanabiliyorsa, ikinci bir derleme hattı ve protokol katmanı taşımanın karşılığı yoktur.
• Ekipte firmware sahipliği yoksa. R5F tarafı ayrı bir araç zinciri, ayrı bir hata ayıklama yöntemi ve ayrı bir sürüm yaşam döngüsü demektir. Sahipsiz bir firmware, sahipsiz bir riski taşır.
• Kritik görev zaten ayrı bir MCU'da ise. Var olan ve doğrulanmış bir harici denetleyiciyi SoC içine taşımak, kazanç değil yeniden doğrulama maliyeti üretir. Bu göç ancak kart maliyeti, gecikme veya senkronizasyon adına somut bir kazanç varsa yapılır.
• Ürün ömrü boyunca iki firmware'i birlikte güncelleyemeyecekseniz. İki alanın sürümleri birbirine bağlıdır; OTA planı bu bağı taşıyamıyorsa mimari sahada dağılır. Güvenli boot ve OTA yaşam döngüsü planı, bölüşüm kararıyla aynı anda yapılmalıdır.

Sonuç

AM67A'da Linux ve R5F'i birlikte kullanmanın değeri, iki işlemciye sahip olmaktan değil, iki farklı zamanlama sözleşmesini aynı kartta barındırabilmekten gelir. Bu değeri korumanın yolu sınırı disiplinli çizmektir: kritik yol R5F alanında kapanır, Linux tarafı yardımcıdır, köprü kritik yolun dışındadır ve her paylaşımlı yapının tek bir sahibi vardır.

Geri kalanı ölçümdür. Bu mimaride "deterministik" kelimesi, arkasında bir histogram olmadığı sürece bir iddia değildir.

Kendi platformunuzda bu bölüşümü kurmayı değerlendiriyorsanız, iş yükü haritasını ve ölçüm planını birlikte çıkarmak en hızlı yoldur: hard real-time ve RTOS yetkinliğimiz tam olarak bu iki soruyla başlar; kapsamı birlikte belirlemek için gömülü sistem mimari denetimi planlayabilirsiniz.

Kaynaklar

1. Texas Instruments — AM67x Processors datasheet, SPRSPA3B, Mart 2024, Haziran 2026 revizyonu — https://www.ti.com/lit/ds/symlink/am67a.pdf
2. Texas Instruments — PROCESSOR-SDK-AM67A — https://www.ti.com/tool/PROCESSOR-SDK-AM67A
3. Linux çekirdek dokümantasyonu — Remoteproc Framework — https://docs.kernel.org/staging/remoteproc.html
4. Linux çekirdek dokümantasyonu — RPMsg Messaging Framework — https://docs.kernel.org/staging/rpmsg.html

Kaynaklara erişim tarihi: 5 Eylül 2026. SDK ve çekirdek belgeleri sürüm alır; hangi çekirdeğin uygulamaya açık olduğu gibi sorular her zaman kullandığınız SDK sürümünün belgesinden doğrulanmalıdır.