Outside the Walled Garden

Wie schon im letzen Jahr wollte ich auch diesmal wieder die LinuxCon und Embedded Linux Conference Europe besuchen — diesmal in Edinburgh. Das heimliche Hauptergeignis aber war der Kernel-Summit, der dieses Jahr ebenfalls dort stattfand. Im Vorfeld des eigentlichen Kernel-Summits fand dann noch der ARM-Mini-Summit statt, der die meisten ARM-Maintainer zusammenbringt und just zu diesem Workshop war auch ich eingeladen

Edinburgh

Da es unwarscheinlich ist, dass ich in nächster Zeit nochmal nach Edinburgh komme, habe ich — wie letztes Jahr — wieder ein paar Tage drumherum gelegt um mir die Stadt anzusehen. Ich hatte auch wahnsinniges Glück, dass sich das Wetter nicht an die Vorraussage von Regen, Regen und Regen gehalten hat, sondern über einen großen Teil der Zeit sogar die Sonne schien.

Das bekannste Bauwerk von Edinburgh ist natürlich die Burg, welche auf einem erloschenen Vulkan steht. Von dort führt dann die Royal Mile durch die Altstadt bis hin zum Palace of Holyroodhouse, der offiziellen Residenz der Königin in Schottland.

Ein paar meiner Eindrücke von Edinburgh gibts in meinem Fotoblog und einen deutlich ausführlicheren Reisebericht zu Schottland gibts bei Torsten, der mir immer alles nach- vor-machen muss.

ARM-Mini-Summit

In der ARM-Welt ist DeviceTree ja momentan das Thema mit der meisten Aufmerksamkeit und dies spiegelte sich natürlich auch in den Themen des Mini-Summit wieder. Ein Großteil der Diskussionen befasste sich also mit DeviceTree-Bindings, DeviceTree-Verifikation, ACPI vs. DeviceTree und einigen Device-*-Themen mehr.

Drumherum gab es dann noch Diskussionen um die Verwaltung des ARM-Trees, den Fortschritt der Konsolidierung der »Legacy«-Architekturen — zum Beispiel der S3C24XX-SoCs, die neue ARM64-Architektur und auch dem Common-Clock-Framework.

KS-Gruppenfoto mit mir in der obersten Reihe, aufgenommen von Thorsten Leemhuis

LinuxCon Europe

Die eigentliche LinuxCon überlagerte sich großflächig mit dem ARM-mini-summit und ist zudem momentan sehr Cloud-lastig, sodass mich die dort behandelten Themen nicht wirklich interessiert und ich sie mir deswegen gespart habe. Dadurch habe ich zwar zwei relativ interessante Podiumsdiskussionen verpasst, aber gerade beim Torvalds-Interview waren die Fragen dann, wie zu erwarten, sehr ähnlich zu vorherigen Interviews — also nicht der große Verlust.

Embedded Linux Conference Europe

Da der Kernel-Summit auch am Freitag Interessantes bot, hab ich von der ELCE auch nur den ersten Tag mitbekommen. An diesem Tag gab es aber auch einige sehr interessante Vorträge. Ein Beispiel war der Zustandsbericht zum Common-Display-Framework — das aber leider noch etwas in der Luft zu hängen scheint. Sehr low-levelig, aber nicht minder interessant war der Vortrag von Will Deacon über die ARM-Memory-Barrieren und wie sich diese auf Code-Ausführung im Prozessor auswirken.

Nächstes Jahr

2014 finden die LinuxCon und ELCE in Düsseldorf statt. Während dies die Anreise erleichtert, hätten sie sich aber doch einen touristisch etwas attraktiveren Ort aussuchen können.

Meinen Basteleien an dem Rockchip-Soc bringen mich abermals mit neuen Bereichen in Kontakt. Ein sehr wichtiger Bereich ist dabei SMP. SMP steht für »symmetric multi-processing« und erlaubt es dem z.B dem Linux-Kernel, laufende Prozesse dynamisch auf alle verfügbaren Prozessoren zu verteilen. Bisher hatte ich ja immer nur mit Ein-Kern-Prozessoren zu tun, sodass ich hier mal eben wieder Neuland betreten habe.

Theorie

Beim Systemstart ist dabei immer nur eine CPU aktiv, d.h. wenn der Linux-Kernel startet arbeitet dieser immer nur auf einem Prozessor. Um alle Kerne zu nutzen, müssen diese separat vom Kernel gebootet werden. Dies geschieht durch verschiedene Funktionen die in einem struct smp_operations zusammengefasst werden.

Die erste Funktion ist »smp_init_cpus«, die eigentlich die Anzahl der vorhandenen Prozessoren bzw. Kerne ermitteln soll. Auf neueren Devicetree-basierenden Plattformen ist dies jedoch nicht mehr nötig, da die Informationen über die verfügbaren CPUs aus dem Devicetree selbst bezogen werden können, weswegen die Funktion auf der Rockchip-Platform nicht nötig ist.

Danach folgt »smp_prepare_cpus«, dessen wichtigste Aufgabe es ist die Cache-Kohärenz zu aktivieren, da jeder Core seinen eigenen Cache besitzt, Inhalte für den gleichen Wert zwischen Caches aber nicht differieren dürfen. In Cortex-A9 Prozessoren, wie dem RK3066, ist dafür die sogenannte Snoop-Control-Unit zuständig, die sogenanntes Bus-Snooping nutzt um Cache-Änderungen zu verfolgen.

Die letzte Funktion ist dann »smp_boot_secondary«, deren Aufgabe es nun ist, die jeweilige CPU in ihrem Argument zu starten. Die Prozedur zum starten eines Kerns ist für jede Plattform unterschiedlich. Bei den Rockchip-SoCs können die Kerne über die PMU aktiviert und deaktiviert werden. Wenn ein Kern startet versucht er ein Programm im prozessoreigenen SRAM zu starten, dass die Initialisierung übernimmt. Deswegen muss dieses (Assembler-)Programm vor Aktivierung des Kerns in das SRAM kopiert werden.

Wenn das alles funktioniert, kann das gestartete System dann über 2 Kerne verfügen.

Ich will Ergebnisse sehen

Da der heutige Tag sehr erfolgreich war, gibt es in der /proc/cpuinfo meines Tablets nun folgendes zu sehen:

processor	: 0
model name	: ARMv7 Processor rev 0 (v7l)
BogoMIPS	: 1196.85
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc09
CPU revision	: 0

processor	: 1
model name	: ARMv7 Processor rev 0 (v7l)
BogoMIPS	: 1196.85
Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc09
CPU revision	: 0

Hardware	: Rockchip Cortex-A9 (Device Tree)
Revision	: 0000
Serial		: 0000000000000000

Die letzten Wochen war ich mit einem ganz besonderen neuen Spielzeug beschäftigt — einem Tablet basierend auf dem RK3066-SoC von Rockchip. Grundlage des RK3066 ist eine Dual-Core Cortex-A9 ARM-CPU die mit bis zu 1,6 GHz läuft und durch die üblichen Komponenten (I2C, SPI, etc) ergänzt wird.

Ist-Zustand

Rockchip-Geräte sind anscheinend recht weit verbreitet, da die SoCs recht günstig zu haben sind. Die Kernel-Quellen zu einigen dieser Geräte sind verfügbar, entsprechen aber leider dem Erwartungsbild für Hersteller-Kernel-Quellen — d.h. in keiner Weise mainline-Kernel-tauglich.

Um Rockchip-basierende Geräte hat sich auch eine kleine »Community« gebildet, die aber auch nur an diesen verfügbaren Kernelquellen herumbastelt. Im mainline-Kernel sind Rockchip-SoCs darum ein unbeschriebenes Blatt — genauso wie ich es mag.

Deshalb konnte ich während der letzten Wochen mal versuchen auch im Low-Level-Bereich der SoC-Unterstützung Erfahrungen zu sammeln.

Erste Patchserie

Wie es scheint hatten die Rockchip-Designer keine Lust alle Komponenten neu zu entwickeln, sondern waren für viele von diesen bei Anbietern von standardisierten Komponenten einkaufen. So kommen z.B. mindestens die seriellen Ports, Timer, USB-OTG, MMC- und SPI-Controller aus der Designware-Reihe von Synopsys.

Montag war es dann soweit und ich konnte die erste Patchserie and die entsprechenden Mailinglisten senden. Der größte Posten dabei war der Pinctrl-Treiber, der für die Verwaltung der Pins und GPIOs des Chips verantwortlich ist. Unerwarteterweise gab es keine sehr großen Kritiken, sondern eigentlich nur kleinere Verbesserungsvorschläge.

Es gab aber auch erweiterte Hausaufgaben. Im mainline-Kernel ist es nicht erlaubt, nur an seinen eigenen Sandkasten zu denken, und der Pinctrl-Treiber kam anscheinend genau zu dem Zeitpunkt, an dem eine Verallgemeinerung von oftmals genutzten Funktionen an der Zeit war. D.h. ich habe diese Aufgabe geerbt, um dann meinen Treiber mit diesen Neuerungen platzieren zu können.

Trotz dessen sollte 3.11 mit einem Quentchen Glück noch zu schaffen sein — sonst dann erst 3.12.

Am Freitag konnte ich ein weiteres Spielzeug in Empfang nehmen — PIXEL.

In der Selbstbeschreibung des Projektes auf Kickstarter ist PIXEL »An interactive LED based display for retro pixel art«. Der 20x20cm Rahmen besteht dabei aus einer Matrix von 32x32 LED-Pixeln, also 1024 in der Summe und einer Mikrokontroller-Platine zum Ansteuern der Pixel. Die Bilddaten selbst werden von einer Anwendung über Bluetooth übermittelt.

Nach einigen Startschwierigkeiten — der erste Bluetooth-Adapter wollte nicht mit meinem Telefon sprechen — funktioniert das ganze jetzt auch

Jetzt muss ich mir nur noch überlegen, was ich damit anstelle.

Nachdem die Erneuerung des Interrupt-Controllers ja nun abgeschlossen ist, folgt gleich das nächste Großprojekt — der DMA-Controller der S3C24XX-Prozessoren.

Was ist DMA

DMA steht für Direct Memory Access und soll helfen die Übertragung von Daten vom Arbeitsspeicher zu Geräten (und zurück) zu beschleunigen.

Der einfache Weg, Daten zwischen diesen auszutauschen nennt sich PIO — Programmed Input/Output. Dabei liest der Prozessor die zu übertragenden Daten häppchenweise aus dem Speicher und schreibt sie in spezielle Register des Gerätes. Gerade diese Häppchen-Arbeitsweise macht das ganze zum einen langsam und erfordert zum anderen auch eine ständige Beteiligung des Prozessors.

Hier setzt nun DMA an, indem es einen Kommunikationsweg zwischen Sender und Empfänger ohne Beteiligung des Prozessors bietet. Hier wird dem DMA-Controller nur noch mitgeteilt, welchen Speicherbereich er zu welchem Ziel übertragen soll. Nach dem Start der Übertragung hat der Prozessor mit dieser nichts mehr zu tun und kann andere Aufgaben erledigen. Nach dem Ende des Transfers wird er über einen Interrupt darüber benachrichtigt und kann dann an der entsprechenden Position weitermachen.

Aktueller Zustand

Wie bei fast allen anderen Subsystemen auch, gab es im ARM-Bereich auch bei den DMA-Controllern die Tendenz, dass jeder seine eigene Schnittstelle zwischen Gerätetreibern und DMA-Controllern kreierte — so ist der aktuelle DMA-Treiber der S3C24XX-Prozessoren in den Jahren 2003 bis 2006 entstanden — und seit dem auch nicht mehr großartig verändert worden.

In dieser Konstellation bieten natürlich nur Treiber DMA-Funktionalität, die speziell für diese Controller-Schnittstelle angepasst geschrieben wurden. Im ARM-Bereich ist dies oftmals möglich, da die Prozessoren meist spezielle Peripheriegeräte mitbringen die auch nur in diesen Prozessoren vorkommen. Schwierig wird es mit solchen privaten Schnittstellen dann, wenn sich wirklich mehrere Prozessoren dieselben Geräte teilen — so teilen sich die S3C24XX Prozessoren zum Beispiel einige wenige Geräte mit neueren Samsung-Prozessoren bis hin zum aktuellen Exynos.

DMAEngine

Seit 2006 hat sich aber auch das DMAEngine-Framework von Intel als die hardwareunabhängige Lösung für DMA-Transfers etabliert. Dort implementieren die Hardware-Treiber nicht mehr den gesamten Transfer sondern nur noch die wirklich hardwarespezifischen-Einstellungen des DMA-Controllers.

Interessanterweise gibt es zwar eine recht gute Dokumentation zur Nutzung der DMAEngine in Treibern, aber keine zum Schreiben von DMAEngine-Treibern. Es bleibt also beim Lesen von Code-Kommentaren um die Funktionsweise zusammen zu puzzeln.