Kritisches Timing in einem ARM Linux Kernel-Treiber

Der ARM -Cache auf einer IMX25 (ARM926) ist 16K-Code, 16K Daten L1 mit einer 32-Byte-Länge oder acht Anweisungen. Mit dem DDR-SDRAM-Controller, der mit 133 MHz und einem 16-Bit-Bus läuft, beträgt die Übertragungsrate etwa 300 MB / s. Eine Cache-Füllung sollte nur etwa 100 nS, nicht 9 μs dauern; das ist etwa 100 mal zu lang.

Sie haben jedoch vier andere Probleme mit Linux.

1. TLB vermisst und ein Seitentisch geht.
2. Daten werden abgebrochen.
3. DMA beherrscht das Stehlen.
4. FIQ unterbricht.

Es ist unwahrscheinlich, dass der LCD-Master genug Bandbreite stiehlt, es sei denn, Sie haben ein riesiges Display. Ist Ihr Bildschirm größer als 1 / 4VGA? Wenn dies nicht der Fall ist, sind dies nur 10% der Speicherbandbreite, und dies wird mit dem Prozessor eine Pipeline bilden. Haben Sie entweder Ethernet oder USB aktiv? Diese Peripheriegeräte haben eine höhere Datenrate und könnten diese Art von Konflikten mit SDRAM verursachen.

All diese Probleme können möglicherweise vermieden werden, indem Sie Ihren Toggler-PC relativ schreiben und in den IRAM kopieren. Siehe: iram_alloc. c ; Diese Datei sollte für ältere Linux-Versionen portierbar sein. Der XBAR-Schalter ermöglicht das gleichzeitige Abrufen von SDRAM und IRAM. Der IRAM kann weiterhin ein Ziel anderer DMA -Master sein. Wenn Sie wirklich gedrückt werden, verschieben Sie den Code in die ETB Puffer, auf die kein anderer Master im System zugreifen kann.

Der TLB-Fehler kann tatsächlich ziemlich steil sein, da er möglicherweise mehrere single beat SDRAM-Zyklen ausführen muss; immer noch sollte dies unter 1uS sein. Sie haben keinen Code gepostet, daher ist es möglich, dass eine Variable und / oder andere einen Datenfehler verursachen, der nicht maskierbar ist.

Wenn Sie Treiber verwenden, die FIQ verwenden, können sie weiterhin ausgeführt werden, obwohl Sie die normalen IRQ Interrupts maskiert haben. Zum Beispiel verwendet der ALSA Treiber für dieses System normalerweise die FIQ .

Sowohl der ETB als auch der IRAM sind 32-Bit-Datenpfade und niedriger Wartezustand. Beide werden wahrscheinlich eine bessere Antwort geben als der DDR-SDRAM.

Wir haben eine Antwortzeit von weniger als einer Mikrosekunde erreicht, indem wir einen FIQ und IRAM verwenden, um GPIOs auf einem IMX258 mit einem anderen Protokoll durch Bit-Banging umzuschalten.

Eine mögliche Problemumgehung für das Problem, das Chris erwähnte (zusätzlich zu den Problemen mit dem Paging des Kernelmodul-Codes), ist die Verwendung eines PWM-Peripheriegeräts, wobei die Dauer des Impulses vorprogrammiert ist und das Timing in Hardware implementiert ist >

Fancy Prozessoren mit Caches sind nicht für harte Echtzeitarbeit geeignet. Die Ausführungszeit variiert, wenn Cache-Misses nicht deterministisch sind (und Designs, bei denen Cache-Misses vollständig deterministisch sind, sind nicht kompliziert genug, um einen ausgefallenen Prozessor zu rechtfertigen).

Sie können versuchen, die Speichercontrollerlatenz während kritischer Abschnitte zu vermeiden, indem Sie den kritischen Abschnitt so ausrichten, dass er die Cachezeilen nicht überspannt. Oder rufen Sie den Code ab, den Sie benötigen. Aber das wird nicht tragbar sein und einen Albtraum für die zukünftige Wartung schaffen. Und schützt immer noch nicht den Zugriff auf Memory-Mapped GPIO von Buskonflikten.