AM67A-Entwicklungsboard: Was das T3 Gemstone O1 vom SoC herausführt

Wer heute mit einem TI AM67A arbeiten will, beginnt mit einem Entwicklungsboard. Mehrere stehen zur Wahl: TIs eigenes J722S EVM, das BeagleY-AI aus der Community, SOM-basierte Trägerplatinen von Modulherstellern — und das T3 Gemstone O1. Dieser Artikel nimmt das Gemstone O1 als Beispiel für eine Frage, die für alle gilt und die keine Produktseite beantwortet: Wie viel vom SoC führt das Board tatsächlich heraus, und welche Architekturentscheidungen lassen sich darauf folglich absichern? Grundlage sind die Dokumentation von T3, der auf GitHub veröffentlichte 33-seitige Schaltplan und das AM67x-Datenblatt von TI. Für diesen Artikel wurden von Spikedge keine eigenen Messungen an diesem Board durchgeführt; die einzige genannte Leistungszahl stammt von T3 selbst und ist entsprechend gekennzeichnet.

Was das T3 Gemstone O1 ist

Das T3 Gemstone O1 (Produktcode T3-GEM-O1) ist ein Einplatinenrechner auf Basis des AM67A, entwickelt von der T3-Stiftung und Baykar. Es ist das erste Board der Gemstone-Reihe.

Der zeitliche Ablauf gehört dazu, denn „gerade erschienen" trifft es nicht:

Das Board war also mindestens zwei Jahre in Entwicklung; die Ankündigung im August 2026 markiert den Serienanlauf, nicht das erste Auftreten.

Beim Preis ist Vorsicht geboten: In der türkischen Presse kursierte am 24. August 2026 eine Zahl von rund 12.850 TRY (etwa 275 USD), formuliert allerdings als voraussichtliche Bauteil- und Materialkosten, nicht als angekündigter Listenpreis. Auf t3gemstone.org steht zum Redaktionszeitpunkt ein Vorab-Anfrageformular statt eines Preises oder eines Bestellvorgangs. Diese Zahl sollte in einer Kostenrechnung nicht als belastbarer Preis verwendet werden.

Die Hardware in Kürze:

• TI AM67A — 4× Cortex-A53 mit 1,4 GHz; die Board-Dokumentation nennt 2× Cortex-R5F mit 800 MHz; 2× 2 TOPS Deep-Learning-Beschleuniger; GPU IMG BXS-4-64
• 4 GB LPDDR4 (x32) und 32 GB eMMC, beide von Longsys; microSD (SDR104); ein 512-Kbit-I²C-EEPROM
• M.2-2280-Steckplatz für NVMe
• Zwei FPC-Steckverbinder insgesamt (Molex 501951-2230, 22-polig, 0,5 mm): entweder zwei MIPI-CSI mit je vier Lanes oder ein CSI plus ein MIPI DSI mit vier Lanes. Dazu HDMI in voller Baugröße
• Gigabit Ethernet über einen TI DP83867 PHY; Wi-Fi 5 und Bluetooth 5.0 über ein Fn-Link-6222B-SRC-Modul
• 2× USB 3.0 Typ A, 1× USB 2.0 Typ A, 2× USB 2.0 Typ C
• 1× CAN-FD über einen TI-TCAN1462-Transceiver
• 9-Achsen-IMU (InvenSense ICM-20948), ein barometrischer Drucksensor, ein Feuchte-/Temperatursensor TI HDC2010, eine RTC DS1340 mit Batterieanschluss
• 40-poliger GPIO-Header, dessen Standardbelegung der des Raspberry Pi entspricht
• JTAG (ARM Cortex, 10-polig) und ein 3-poliger UART-Debug-Anschluss
• Versorgung über USB Typ C (5–9 V / 3 A, PD) oder DC-Buchse (5–12 V / 5 A); PMIC TI TPS65219-Q1
• PWM-geregelter Lüfteranschluss

Die meisten dieser Bauteilnummern stehen in keiner schriftlichen Dokumentation von T3; sie wurden aus dem veröffentlichten Schaltplan gelesen.

Was das Board vom SoC herausführt

Diese Gegenüberstellung lohnt sich bei jedem Entwicklungsboard: die Merkmalsliste des SoC neben die des Boards legen. Die Differenz sagt, für wen das Board entworfen wurde.

Nichts davon macht das Board mangelhaft. Es macht es zu einem Entwicklungsboard. Machbarkeitsentscheidungen gehören ans SoC-Datenblatt, die Prototypenplanung an die Board-Dokumentation.

Die Zahl der R5F-Kerne ist kein Widerspruch, sondern eine Zählweise. Das TI-Datenblatt führt drei einzelne R5F-Kerne — einen in der MCU-Domäne, einen in der MAIN-Domäne, einen für das Gerätemanagement. Die Board-Dokumentation zählt zwei, vermutlich die beiden, die der Anwendungsfirmware zur Verfügung stehen. Diese Unterscheidung behandeln wir in unserer AM67A-Architekturanalyse.

Zwei Randbedingungen, die nur der Schaltplan zeigt

Die beiden USB-3.0-Anschlüsse teilen sich die Bandbreite. Im Schaltplan sitzt ein TI TUSB8041, ein Vierport-USB-3.0-Hub. Die beiden USB-3.0-Buchsen des Boards werden aus dem einen USB-3.1-Gen1-Port des SoC aufgefächert. Wer zwei hochauflösende USB-Kameras gleichzeitig mit voller Rate betreiben will, hat hier einen Engpasskandidaten — einen, den man messen und nicht annehmen sollte.

Der M.2-Steckplatz wird mit einer Lane bedient. Der Schaltplan zeigt ein einzelnes SERDES-Paar, und der AM67A bietet ohnehin PCIe Gen3 ×1. Alles in diesem Steckplatz läuft mit der Bandbreite einer Lane. Der Steckplatz ist zudem der einzige: NVMe-SSD und ein KI-Beschleuniger im M.2-Format lassen sich nicht gleichzeitig bestücken.

Eine dritte Randbedingung kommt aus dem SoC und wirkt auf das Board: PCIe, USB 3.0 und SGMII teilen sich beim AM67A insgesamt zwei SERDES-Ports. Dieses Board verwendet das Budget für M.2 und USB 3.0 und führt Ethernet über RGMII — im Schaltplan steht ein einzelner DP83867 PHY.

Software: Yocto oder Ubuntu?

Beides, und die Aufteilung ist relevant.

• Kernel, U-Boot und Firmware entstehen mit Yocto (poky, meta-ti, meta-arm, meta-openembedded, meta-qt6 und T3s eigener Layer meta-gemstone, auf dem Scarthgap-Stand).
• Das Root-Dateisystem wird nicht mit Yocto gebaut, sondern mit Debos/debootstrap. Ergebnis ist eine Ubuntu-22.04-Basis mit APT und systemd.

Für ein Team, das mit Yocto arbeitet, ist das eine vertraute und sinnvolle Kombination: die hardwarenahe Schicht reproduzierbar halten, dem Userspace eine gewohnte Distribution geben. Für ein Entwicklungsboard ist das die richtige Abwägung. Auf dem Weg in die Serie gehört sie erneut geprüft — bei einem Produkt mit zehnjähriger Einsatzdauer soll üblicherweise auch das Root-Dateisystem reproduzierbar sein.

Veröffentlicht werden drei Image-Typen — Minimal, Kiosk und Desktop — über mehrere Distributionsbasen und beide unterstützten Boards hinweg, sodass die Zahl der tatsächlich bereitgestellten Images deutlich höher liegt als drei. Geschrieben werden sie mit einer Desktop-Anwendung namens Gem Imager; ein Kommandozeilenwerkzeug gibt es nicht.

Der Edge-AI-Pfad

Der Edge-AI-Stack ist im Image nicht enthalten. Er wird mit einem einzelnen Paket installiert, danach folgen zwei leicht zu übersehende Schritte: ein Device-Tree-Overlay in /boot/uEnv.txt eintragen und neu starten, anschließend eine Umgebungsdatei als root einlesen. Die Nutzung des Beschleunigers setzt also das manuelle Aktivieren eines Device-Tree-Overlays und Root-Rechte voraus.

Das Paket bringt den Edge-AI-Stack von TI mit: TIs Forks von TensorFlow Lite und ONNX Runtime, die TIDL-Laufzeitumgebung mit TFLite-Delegate und ONNX-Runtime-Execution-Provider, Neo-AI DLR, GStreamer sowie TIs Referenzanwendungen edgeai-gst-apps. Die Modelle liegen unter /opt/model_zoo in der ModelZoo-Nomenklatur von TI.

Der Ablauf hat drei Schritte, und der mittlere ist der entscheidende: Modelle werden auf einem x86-Host übersetzt, dabei entscheidet der Compiler, welche Schichten auf C7x/MMA landen, und heraus kommen Artefakte. Das Board führt die Artefakte aus. Übersetzt wird nicht auf dem Board.

Die zugrunde liegende Einschränkung stammt aus dem SoC: Das TI-Datenblatt hält fest, C7x und MMA seien für von TI bereitgestellten Code reserviert, während TIs eigene MCU+-SDK-Dokumentation zum selben Silizium in eine andere Richtung weist. Ein eigenes trainiertes Modell über die TI-Kette auszuführen, ist dokumentiert und unstrittig; eigene C7x-Kernel zu schreiben, ist ungeklärt. Diesen Widerspruch behandeln wir im Architekturartikel.

Die eine veröffentlichte Messung — und wie sie zu lesen ist

Die AI-Dokumentation von T3 enthält keine Leistungszahlen. Das Repository object-tracker-o1 schon — gemessen von T3, nicht unabhängig überprüft und nur mit den zugehörigen Randbedingungen aussagekräftig.

Modell ssdLite-MobDet-DSP mit 320×320 auf C7x/MMA über TIDL; Eingang 1920×1080, Ausgang 1280×720, H.264-Codierung in Hardware:

Die Lehre liegt nicht in der Größe der Zahlen, sondern im Abstand zwischen Inferenzzeit und Gesamtzeit: 19,86 ms Inferenz innerhalb von 34,33 ms Ende-zu-Ende. Knapp die Hälfte der Kette liegt außerhalb des Beschleunigers — Erfassung, Vor- und Nachverarbeitung, Tracking, Codierung. Die Angabe „4 TOPS" sagt über diese 14 ms nichts aus.

Dasselbe Repository hat auch gemessen, was Tracking auf der CPU kostet. Für ein 720p-Bild mit einem 160×320-Fenster reichten die Zeiten je Bild von wenigen Millisekunden beim günstigsten Verfahren bis zu mehreren hundert beim aufwendigsten. Damit wird der Punkt greifbar: Eine Detektion, die auf dem Beschleuniger in 20 ms fertig ist, kann durch die falsche Tracker-Wahl auf den A53-Kernen vollständig verdeckt werden.

Zu Leistungsaufnahme und Temperatur gibt es für dieses Board überhaupt keine veröffentlichte Angabe. Die einzige unabhängige Referenz stammt von einem anderen Board mit demselben SoC: Die BeagleY-AI-Untersuchung von CNX Software ergab 4,7–4,8 W im Leerlauf und 5,5–5,8 W bei 4K-Videowiedergabe bei rund 31 °C Umgebungstemperatur, mit 42–45 °C nach dem Start und 61 °C nach zehn Minuten Volllast (51 °C mit Tischventilator). Das sind die Werte eines anderen Boards und nicht auf das Gemstone O1 übertragbar; sie zeigen lediglich, in welchem Leistungsband diese SoC-Klasse arbeitet.

Die R5F-Seite

Ein Detail der MCU-Dokumentation fällt auf: Das SDK und sämtliche Beispielpfade heißen j722s-evm. Ein AM67A-spezifisches MCU-SDK gibt es nicht; entwickelt wird direkt gegen die J722S-Produktlinie von TI.

Die Beispielprojekte setzen auf FreeRTOS mit getrennten Verzeichnissen je Kern. Firmware-Images werden unter festen Namen nach /lib/firmware kopiert und beim Start von Linux über remoteproc geladen — alternativ bereits in der U-Boot-Phase, was der richtige Weg ist, wenn der Echtzeitkern vor Linux verfügbar sein muss.

Ein Hinweis in der Dokumentation wird jedem vertraut vorkommen, der in dieser Architektur gearbeitet hat: Die Zuordnung der Kerne zu den remoteproc-Geräten ist nicht bei jedem Start garantiert und muss geprüft statt angenommen werden. Automatisierung, die diesen Schritt auslässt, adressiert sporadisch den falschen Kern.

Die Kommunikation zwischen Linux und R5F läuft über RPMsg. T3 hat darauf zusätzlich einen virtuellen Ethernet-Treiber aufgesetzt — ein interessanter Ansatz für Architekturen, die socketbasierte Kommunikation zwischen Echtzeitkern und Linux wünschen. Die Entwurfsentscheidungen dieser Seite behandeln wir in Linux und Cortex-R5F auf dem AM67A.

NuttX und ArduPilot: Wie viel heißt „unterstützt"?

Beide Aussagen stimmen. Ihr Umfang unterscheidet sich deutlich.

Apache NuttX. Die Board-Unterstützung wurde tatsächlich upstream übernommen und erschien erstmals in NuttX 13.0.0 (Juli 2026). NuttX läuft auf dem Cortex-R5F der MAIN-Domäne, nicht auf den A53-Kernen, und wird über remoteproc geladen, während Linux weiterläuft. Der Umfang upstream ist allerdings schmal: eine einzige Konfiguration, als einzige unterstützte Peripherie die UART-Konsole und die Kennzeichnung „experimental". Treiber für SPI, I²C und PWM liegen in T3s eigenem Fork. „NuttX wird unterstützt" ist damit zutreffend; „darauf lässt sich ein Produkt aufbauen" noch nicht.

Eine Randbemerkung: T3s eigene Dokumentationsseite sagt weiterhin, es gebe keine offizielle NuttX-Unterstützung, während das eigene Änderungsprotokoll die Übernahme meldet. Die Dokumentation hinkt dem eigenen Ergebnis hinterher.

ArduPilot. Hier ist der Stand reifer. Die Board-Unterstützung wurde im Oktober 2025 übernommen und erreichte mit Copter 4.7.0 einen stabilen Stand. Entscheidend ist die Rolle: Das T3 Gemstone O1 ist als Linux-basierter Autopilot gelistet, nicht als Companion Computer.

Und die Empfehlung der Dokumentation zeigt den Preis dieser Architektur: Zwei A53-Kerne werden über einen Kernel-Boot-Parameter für ArduPilot isoliert. Bei einem Entwurf, in dem Edge AI und Flugregelung dasselbe Board teilen, halbiert das das CPU-Budget — das gehört in die Planung. (Diese Schlussfolgerung stammt von uns; die Dokumentation formuliert sie nicht aus.)

PX4 ist nicht upstream, sondern liegt in T3s Fork, auf dem R5F unter NuttX. ROS 2 ist offiziell überhaupt nicht dokumentiert — im gesamten Dokumentationsbestand findet sich eine beiläufige Erwähnung. Ein Community-Paket für ROS 2 Humble existiert, und dessen README hält einen realen Stolperstein fest: Die üblichen ROS-2-Installationsschritte funktionieren wegen einer APT-Konfiguration im Image nicht unmittelbar. Genau solche Details brechen die Annahme „es ist ja Ubuntu, es installiert sich alles" — und gehören in den Zeitplan jedes Robotikprojekts, das hier startet.

Der ehrlichste Satz der Dokumentation

Die wertvollste technische Aussage über dieses Board steht in T3s eigener Dokumentation:

„Some of the capabilities and features listed for AM67A on the manufacturer's website are not yet available. Due to insufficient documentation and support, users must research and solve these limitations through trial and error."

Dieselbe Seite führt aus: Da TI für dieses Modell weder ein stabiles MCU-SDK noch vollständige Dokumentation veröffentlicht hat, orientiert sich die Entwicklung an der Jacinto-Produktlinie. Als konkretes Beispiel wird genannt, dass der Netzwerk-Bootmodus für den AM67A gelistet ist, aber weder Dokumentation noch Beispielcode mitbringt.

Das ist als Reifegradanzeige zu lesen, nicht als Mängelliste. Ein Boardhersteller, der eine solche Warnung in die eigene Dokumentation schreibt, geht offen mit seinen Anwendern um. Für die Systemarchitektur bedeutet es etwas Konkretes: Das Integrationsrisiko auf dieser Plattform ist real und gehört in den Zeitplan. Dass eine Funktion im Datenblatt steht, heißt nicht, dass sie mit einem funktionierenden Treiber ankommt.

Offene Hardware?

Teilweise, und die Abstufung zählt. Der vollständige, 33-seitige Schaltplan liegt auf GitHub — in dieser Preisklasse nicht selbstverständlich und ein echter Pluspunkt. Layout, Gerber-Daten, Stückliste und mechanische Zeichnungen sind jedoch nicht veröffentlicht, und das Repository enthält keine Lizenzdatei. Sie können den Schaltplan lesen und verstehen; ableiten und fertigen können Sie den Entwurf nicht.

Auch die Softwarelizenzen sind nicht einheitlich. Die Lizenzseite von T3 beschreibt die eigenen Projekte überwiegend als Apache 2.0; die Repository-Daten zeigen ein gemischteres Bild, mit einer Minderheit unter Apache-2.0, mehreren unter GPL-Varianten und einer erheblichen Zahl ohne erkennbare Lizenzdatei. Forks tragen die Lizenz ihres Ursprungs. Für jedes Bauteil einer kommerziellen Lösung ist die Lizenz einzeln zu prüfen.

Abmessungen, Lage der Befestigungsbohrungen und Gewicht sind schriftlich nicht veröffentlicht; die Seite zum Hardwareentwurf trägt zum Redaktionszeitpunkt den Hinweis „under construction". T3s eigenes Fritzing-Bauteil legt einen Umriss nahe Raspberry Pi Model B nahe, doch das ist eine Messung an einer Zeichnung, keine Spezifikation. Deshalb lautet die zutreffende Aussage zum 40-poligen Header: Die Standardbelegung entspricht der des Raspberry Pi — eine mechanische HAT-Kompatibilität lässt sich aus der Dokumentation nicht ableiten.

Eine lehrreiche Unstimmigkeit: Die Bauteilnummer des barometrischen Drucksensors widerspricht sich zwischen den Quellen — Schaltplan und Repository nennen ein Bauteil, die Dokumentationsseite ein anderes. Das Gewicht der Belege liegt beim Schaltplan, doch das ist eine Schlussfolgerung. In einem kritischen Entwurf klärt man das am Board oder beim Hersteller, nicht durch Raten; deshalb steht hier kein Bauteilname.

Was sich auf einem Entwicklungsboard nicht absichern lässt

Gut beantwortet das Board diese Fragen: Lässt sich mein Modell übersetzen, läuft meine Verarbeitungskette, ist die R5F-Aufteilung sinnvoll, ist der Software-Stack portierbar.

Diese Fragen beantwortet es nicht, und sie für beantwortet zu halten, ist teuer:

1. Thermisches Verhalten. Die Kühlung des Boards ist nicht Ihr Gehäuse. Die zugesicherte Lebensdauer des AM67A hängt direkt vom Profil der Sperrschichttemperatur ab.
2. Spannungsversorgung. PMIC und Versorgungsbaum des Boards sind eine Referenz, keine Validierung.
3. EMV und ESD. Ein offenes Entwicklungsboard verhält sich völlig anders als ein geschlossenes Gerät.
4. Vibration und Steckverbinderhalt. FPC-Kameraanschlüsse und ein M.2-Steckplatz erfordern auf einer bewegten Plattform eigene Konstruktionsarbeit.
5. Secure Boot. Beim AM67A hängen die Sicherheitsmerkmale von der Teilenummernvariante ab, und der vollständige Bestellcode des verbauten Bausteins ist nicht veröffentlicht.
6. OTA und Instandhaltung im Feld. Zwei Firmware-Domänen — Linux und R5F — müssen gemeinsam aktualisiert werden.
7. Beschaffung und Lebensdauer. Der Zusammenhang zwischen Board-Revision und Bestellcode des SoC ist nicht dokumentiert.

Zum Redaktionszeitpunkt nicht veröffentlicht

Ein ehrlicher Fachartikel braucht auch eine Liste des Unbekannten. Für das T3 Gemstone O1 fehlen offizielle Angaben zu:

• typischer und maximaler Leistungsaufnahme,
• Abmessungen, Gewicht und Lage der Befestigungsbohrungen,
• Betriebstemperaturbereich,
• vollständigem Bestellcode des verbauten AM67A (und damit Geschwindigkeitsklasse und Sicherheitsvariante),
• offiziell erklärter PCIe-Generation und Lane-Zahl des M.2-Steckplatzes,
• maximaler HDMI-Auflösung und Bildwiederholrate,
• Betriebsgeschwindigkeit des LPDDR4,
• jeglicher von unabhängiger Seite gemessener Leistungs-, Verbrauchs- oder Temperaturangabe.

Jeder dieser Punkte ist eine Lücke, die vor einer Produktentscheidung zu schließen ist. Keiner davon ist ein Mangel; es sind schlicht noch nicht veröffentlichte Angaben.

Fazit

Das T3 Gemstone O1 ist ein durchdachtes Entwicklungsboard, das den AM67A zugänglich macht: offener Schaltplan, zweisprachige und offene Dokumentation, ein Software-Pfad auf dem offiziellen Edge-AI-Stack von TI und echte Spuren upstream bei NuttX und ArduPilot.

Es ist zugleich keine Serienplattform und wird auch nicht als solche dargestellt. Es führt zwei der vier Kameraeingänge des Siliziums heraus, einen von vier CAN-Kanälen und einen von zwei Ethernet-Ports; Angaben zu Verbrauch und Temperatur fehlen. Das sind die natürlichen Folgen davon, ein Entwicklungsboard zu sein. Zum Problem wird es erst, wenn eine Architekturentscheidung ohne Kenntnis dieser Differenz fällt.

Wer hier prototypisiert und die Serie im Blick hat, sollte zwei Fragen früh beantworten: Übersteht das Zielmodell die TIDL-Übersetzung, und lässt sich die reale Kamera-, Netzwerk- und CAN-Topologie auf diesem Board absichern? Lautet beides Nein, ist der richtige Schritt nicht, am Board festzuhalten, sondern die Trägerplatine früher zu beginnen. Diesen Übergang planen wir in einem Architektur-Audit.

Quellen

1. T3 Gemstone — Vorstellung und technische Daten des O1 — https://docs.t3gemstone.org/en/boards/o1/introduction
2. T3 Gemstone — TI-AM67A-Seite, mit dem Hinweis auf die Dokumentationslücken bei TI — https://docs.t3gemstone.org/en/boards/o1/tiam67
3. T3 Gemstone — Edge-AI-Ökosystem, Installation und Beispiele — https://docs.t3gemstone.org/en/boards/o1/ai/ecosystem
4. T3 Gemstone — Hardware-Repository und vollständiger 33-seitiger Schaltplan — https://github.com/t3gemstone/hardware
5. T3 Gemstone — Repository object-tracker-o1 (Messungen von T3 selbst) — https://github.com/t3gemstone/object-tracker-o1
6. Texas Instruments — AM67x Processors datasheet, SPRSPA3B — https://www.ti.com/lit/ds/symlink/am67a.pdf
7. Apache NuttX — Board-Unterstützung T3 Gemstone O1 — https://nuttx.apache.org/docs/latest/platforms/arm/am67/boards/t3-gem-o1/index.html
8. ArduPilot — T3 Gemstone O1 Overview — https://ardupilot.org/copter/docs/common-t3-gem-o1-overview.html
9. CNX Software — BeagleY-AI SBC review, 13. Oktober 2024 (gleicher SoC, anderes Board; Messungen zu Verbrauch und Temperatur) — https://www.cnx-software.com/2024/10/13/beagley-ai-review-sbc-debian-12-tensorflow-lite-ai-demos/

Zugriff auf die Quellen am 5. September 2026. Board und Software-Stack werden aktiv weiterentwickelt; Version, Preis und Unterstützungsstand können sich rasch ändern.