Computer on Modules

Der Softwaresupport macht letztlich den Unterschied

Seite: 2/3

Firmen zum Thema

Viele OEMs werden deshalb dankbar sein, wenn sie diese Aufgabe an einen externen Dienstleister auslagern können. Schließlich müssen sich OEM verstärkt auf die eigenen Kernkompetenzen konzentrieren, um die Forderungen nach immer kürzeren Markteinführungszeiten erfüllen zu können. So ist die dedizierte OS-Konfiguration ein gutes Aufgabenfeld für den Hardwarelieferanten. Dafür gibt es mehrere Gründe, die im erforderlichen dedizierten Zuschnitt des OS und Bootloaders begründet liegen.

Dedizierte Betriebssystem-Anpassung nötig

Damit man nämlich überhaupt an den Punkt kommen kann, das Betriebssystem auf die dedizierten Applikationsanforderungen „einzudampfen“, muss es für die gewählte ARM-Plattform erst einmal lauffähig gemacht werden. Und hier sind bei Modulen auch immer das Carrierboard und seine dedizierten Interfaces von Bedeutung. In der generischen x86-Welt beispielsweise ist für nahezu jede Hardware ein passender Treiber bereits verfügbar und häufig auch schon im Betriebssystem integriert.

Bildergalerie
Bildergalerie mit 6 Bildern

Bei der ARM-Technologie ist es jedoch nicht so, dass man die Treiber einfach herunterladen und dazu installieren kann. Je nach Betriebssystem kann es nämlich bis hin zu spezifischen Kernel-Konfigurationen reichen, um die individuellen Features ansprechen zu können. Dies ist zwar auch bei x86er Systemen je nach Lösung gefragt, ist aber eher die Ausnahme denn die Regel.

Modulspezifisches OS direkt vom Hersteller

Durch Standards wie die SMARC-Module, die für alle ARM-SoCs ein einheitliches standardisiertes Schnittstellenangebot über den Konnektor definieren, wird für OEMs jedoch zumindest sichergestellt, dass alle vom jeweiligen Modul ausgeführten I/Os unterstützt werden. Und genau in diesem Punkt unterscheiden sich offene Standards also signifikant von proprietären Modulfamilien.

Ein durchaus relevanter Unterschied. Denn ein Modul-Standard kann auch I/Os als Mindestanforderung unterstützen, die ein ARM-SoC von Haus aus nicht mitbringt. Beispiele hierfür sind bei SMARC-Modulen mit i.MX6-Freescale-Prozessor ein optionaler PCI Express Hub, um die PCI Express Lane des Prozessors auf drei zu erweitern oder der auf Nvidia-Tegra-3-SMARC-Modulen integrierte Gigabit Ethernet Controller.

Insofern sind auf einem Modul neben dem ARM-SoC auch weitere Komponenten enthalten, die ebenfalls Treibersupport benötigen. Man könnte also auch sagen, dass OEMs damit ein Module-BSP benötigen und nicht nur ein Prozessor-BSP. Darüber hinaus gilt es, in der eigentlichen Applikation aber auch noch weitere wichtige Peripheriekomponenten einzubinden: Hier ist der Support für verschiedene LVDS-Panels oder für verbreitete WiFi-Devices zu nennen. Einige dieser Komponenten müssen zudem auch schon im Bootloader verankert werden, der den Betriebssystem-Kernel lädt.

Neues Terrain: Bootloader statt BIOS

Damit kommt auch dem Bootloader bei ARM-basierten Designs ebenfalls eine entscheidende Rolle zu. Wo x86-Technologie auf ein BIOS setzt, erfolgt bei ARM-Prozessoren die Initialisierung einzelner Komponenten – wie beispielsweise RAM, (Flash-)Speichermedien und Displays sowie kundenspezifisches I/O – über einen Bootloader.

(ID:37541330)