AM67A Development Board: What the T3 Gemstone O1 Exposes of the Silicon

If you want to work with a TI AM67A today, you start with a development board. Several exist: TI's own J722S EVM, the community BeagleY-AI, SOM-based carriers from module vendors, and the T3 Gemstone O1. This article uses the Gemstone O1 as a worked example to answer a question that applies to all of them and that no product page answers: how much of the SoC does the board actually expose, and which architectural decisions can you therefore validate on it? Sources are T3's own documentation, the 33-page schematic published on GitHub, and TI's AM67x datasheet. Spikedge has not independently benchmarked this board; the single performance figure quoted here is T3's own measurement and is labelled as such.

What the T3 Gemstone O1 is

The T3 Gemstone O1 (product code T3-GEM-O1) is an AM67A-based single board computer developed by the T3 Foundation and Baykar. It is the first board in the Gemstone line.

The timeline is worth stating, because "just launched" is misleading:

So the board had been in development for at least two years; the August 2026 announcement marks volume production rather than a first appearance.

On pricing, be careful: a figure of roughly 12,850 TRY (~275 USD) circulated in Turkish press on 24 August 2026, but it was phrased as a projected component-and-materials cost, not an announced list price. At the time of writing t3gemstone.org shows a pre-request form rather than a price or an ordering flow. Do not use that number as a verified price in a cost comparison.

Hardware summary:

• TI AM67A — 4× Cortex-A53 @ 1.4 GHz; the board documentation states 2× Cortex-R5F @ 800 MHz; 2× 2 TOPS deep learning accelerators; IMG BXS-4-64 GPU
• 4 GB LPDDR4 (x32) and 32 GB eMMC, both Longsys parts; microSD (SDR104); a 512 Kbit I²C EEPROM
• M.2 2280 slot for NVMe
• Two FPC connectors total (Molex 501951-2230, 22-pin 0.5 mm): either two 4-lane MIPI CSI, or one CSI plus one 4-lane MIPI DSI. Plus full-size HDMI
• Gigabit Ethernet via a TI DP83867 PHY; Wi-Fi 5 and Bluetooth 5.0 via an Fn-Link 6222B-SRC module
• 2× USB 3.0 Type-A, 1× USB 2.0 Type-A, 2× USB 2.0 Type-C
• 1× CAN-FD via a TI TCAN1462 transceiver
• 9-axis IMU (InvenSense ICM-20948), a barometric pressure sensor, a TI HDC2010 humidity/temperature sensor, a DS1340 RTC with battery connector
• 40-pin GPIO header whose default pinout matches the Raspberry Pi
• ARM Cortex 10-pin JTAG and a 3-pin UART debug connector
• Power over USB Type-C (5–9 V / 3 A, PD) or a DC connector (5–12 V / 5 A); TI TPS65219-Q1 PMIC
• PWM-controlled fan connector

Most of those part numbers appear nowhere in T3's written documentation; they were read from the published schematic.

What the board exposes of the silicon

This is the exercise worth doing for any development board: put the SoC's feature list beside the board's. The gap tells you who the board was designed for.

None of this makes the board deficient. It makes it a development board. Base feasibility decisions on the SoC datasheet and prototype plans on the board documentation.

The R5F count is not a contradiction, it is a counting choice. TI's datasheet lists three single-core R5Fs — one in the MCU domain, one in the main domain, one for device management. The board documentation counts two, most likely the two available to application firmware. We work through that distinction in our AM67A architecture deep dive.

Two constraints only the schematic reveals

The published schematic contains two engineering facts that appear in no marketing material.

The two USB 3.0 ports share bandwidth. The schematic shows a TI TUSB8041 four-port USB 3.0 hub. The board's two USB 3.0 Type-A ports are fanned out from the SoC's single USB 3.1 Gen1 port. If you plan to run two high-resolution USB cameras concurrently at full rate, that is a bottleneck candidate — and one to measure rather than assume.

The M.2 slot is fed by a single lane. The schematic shows one SERDES differential pair, and the AM67A provides PCIe Gen3 ×1 in any case. Everything in that slot runs at single-lane bandwidth. The slot is also singular: an NVMe SSD and an M.2-form AI accelerator cannot both be fitted.

A third constraint comes from the SoC and lands on the board: PCIe, USB 3.0 and SGMII share a total of two SERDES ports on the AM67A. This board spends that budget on M.2 and USB 3.0 and takes Ethernet over RGMII — the schematic shows a single DP83867 PHY.

Software: Yocto or Ubuntu?

Both, and the split matters.

• Kernel, U-Boot and firmware are built with Yocto (poky, meta-ti, meta-arm, meta-openembedded, meta-qt6 and T3's own meta-gemstone layer, on the scarthgap release).
• The root filesystem is not Yocto-built. It is produced with Debos/debootstrap, giving an Ubuntu 22.04 base with APT and systemd.

For a team that works in Yocto this is a familiar and reasonable combination: keep the hardware-adjacent layer reproducible, give userspace a familiar distribution. It is the right trade for a development board. It should be revisited on the way to production — a product with a ten-year service life usually wants a reproducible root filesystem too.

Three image types are published — Minimal, Kiosk and Desktop — across several distribution bases and both supported boards, so the published image count is considerably higher than three. Images are written with a desktop application called Gem Imager; there is no CLI.

The Edge AI path

The Edge AI stack does not ship in the image. It installs as a single package, after which two steps remain that are easy to miss: adding a device tree overlay to /boot/uEnv.txt and rebooting, then sourcing an environment file as root. Using the accelerator therefore requires enabling a device tree overlay by hand and having root.

What the package brings is TI's own Edge AI stack: TI's forks of TensorFlow Lite and ONNX Runtime, the TIDL runtime with its TFLite delegate and ONNX Runtime execution provider, Neo-AI DLR, GStreamer, and TI's edgeai-gst-apps reference applications. Models live under /opt/model_zoo with TI ModelZoo naming.

The workflow has three steps and the middle one is the important one: models are compiled on an x86 host, the compiler decides which layers land on the C7x/MMA, and the output is a set of artifacts. The board runs the artifacts. You do not compile on the board.

The underlying constraint comes from the SoC: TI's datasheet states that the C7x + MMA are reserved for TI-provided code, while TI's own MCU+ SDK documentation for the same silicon points the other way. Running your own trained model through the TI flow is documented and uncontroversial; writing custom C7x kernels is not resolved. We cover that contradiction in the architecture article.

The one published measurement, and how to read it

T3's AI documentation carries no performance figures. Its object-tracker-o1 repository does — measured by T3, not independently verified, and only meaningful with its conditions attached.

Model ssdLite-MobDet-DSP at 320×320 on the C7x/MMA via TIDL; 1920×1080 input, 1280×720 output, hardware H.264 encoding:

The lesson is not the size of the numbers. It is the gap between inference time and total time: 19.86 ms of inference inside 34.33 ms end to end. Nearly half the pipeline is spent outside the accelerator — capture, pre-processing, post-processing, tracking, encoding. A "4 TOPS" label says nothing about those 14 ms.

The same repository also measured the cost of doing tracking on the CPU. For a 720p frame with a 160×320 box, per-frame times ranged from single-digit milliseconds for the cheapest tracker to several hundred for the most expensive. That range makes the point concretely: a detection that finishes in 20 ms on the accelerator can be buried by the wrong tracker choice on the A53s.

For power and thermals there is no published figure for this board at all. The only independent reference comes from a different board on the same SoC: CNX Software's BeagleY-AI review measured 4.7–4.8 W idle and 5.5–5.8 W during 4K video playback at roughly 31 °C ambient, with temperatures of 42–45 °C after boot and 61 °C under ten minutes of full load (51 °C with a desk fan). Those are another board's numbers and do not transfer to the Gemstone O1; they only indicate the power band this SoC class operates in.

The R5F side

One detail stands out in the MCU-side documentation: the SDK and every example path are named j722s-evm. There is no AM67A-specific MCU SDK; development runs directly against TI's J722S product line.

Example projects are built on FreeRTOS with per-core directories. Firmware images are copied into /lib/firmware under fixed names and loaded by Linux at boot through remoteproc, or alternatively at the U-Boot stage — which is the right path when the real-time core must be up before Linux.

One warning in the documentation will be familiar to anyone who has worked in this architecture: the cores are not guaranteed to map to the same remoteproc device on every boot, so the mapping must be checked rather than assumed. Automation that skips this targets the wrong core intermittently.

Linux-to-R5F communication runs over RPMsg. T3 has also built a virtual Ethernet driver on top of RPMsg — an interesting approach for architectures that want socket-based communication between the real-time core and Linux. We cover the design decisions on that side in running Linux alongside Cortex-R5F on the AM67A.

NuttX and ArduPilot: how much does "supported" mean?

Both claims are true. Their scope differs sharply.

Apache NuttX. Board support really was merged upstream, and it first shipped in NuttX 13.0.0 (July 2026). NuttX runs on the main-domain Cortex-R5F, not on the A53s, and is loaded through remoteproc while Linux keeps running. But the upstream scope is narrow: a single configuration, UART console as the only supported peripheral, and an "experimental" label. SPI, I²C and PWM drivers live in T3's own fork. So "NuttX is supported" is accurate; "you can build a product on NuttX here" is not yet.

A small aside: T3's own documentation page still says there is no official NuttX support, while its changelog announces the merge. The documentation is behind its own achievement.

ArduPilot. More mature. Board support merged in October 2025 and reached a stable release with Copter 4.7.0. The role matters: the T3 Gemstone O1 is listed as a Linux-based autopilot, not a companion computer.

And the documentation's own recommendation shows the cost of that architecture: two A53 cores are isolated for ArduPilot via a kernel boot parameter. On a design where Edge AI and flight control share the board, that halves the CPU budget — plan accordingly. (That inference is ours; the documentation does not spell it out.)

PX4 is not upstream; it lives in T3's fork, on the R5F under NuttX. ROS 2 is not officially documented at all — one passing mention across the documentation set. A community ROS 2 Humble package exists, and its README records a real friction point: the standard ROS 2 installation steps do not work directly because of an APT configuration conflict in the image. That is the kind of detail that breaks the "it's Ubuntu, everything installs" assumption, and it belongs on the schedule of any robotics project starting here.

The most honest sentence in the documentation

The most valuable technical statement written about this board is in T3's own documentation:

"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."

The same page continues: because TI has not released a stable MCU SDK or complete documentation for this model, development proceeds by reference to the Jacinto product line. The concrete example given is that network boot mode is listed for the AM67A but ships with neither documentation nor sample code.

Read that as a maturity indicator, not a defect list. A board vendor publishing this warning in its own documentation is being straight with you. For a system architect the meaning is specific: integration risk on this platform is real and belongs in the schedule. A feature appearing in a datasheet does not mean it arrives with a working driver.

Open hardware?

Partly, and the nuance matters. The full 33-page schematic is on GitHub — not a given at this price point, and a genuine plus. But the PCB layout, Gerbers, bill of materials and mechanical drawings are not published, and the repository carries no license file. You can read and understand the schematic; you cannot derive and manufacture the design.

Software licensing is mixed rather than uniform. T3's license page describes its projects as mostly Apache 2.0; the repository data shows a more varied picture, with a minority carrying Apache-2.0, several under GPL variants and a substantial number with no recognised license file. Forks carry their upstream licenses. Every component going into a commercial product needs its license checked individually.

Physical dimensions, mounting hole positions and weight are not published in text; the hardware design page reads "under construction" at the time of writing. T3's own Fritzing part suggests a footprint close to a Raspberry Pi Model B, but that is a measurement from a drawing asset, not a specification. For that reason the correct statement about the 40-pin header is that its default pinout matches the Raspberry Pi — mechanical HAT compatibility cannot be claimed from the documentation.

One instructive inconsistency: the part number of the on-board barometric pressure sensor conflicts between sources — the schematic and repository name one part, the documentation site another. The weight of evidence sits with the schematic, but that is an inference. In a critical design this is resolved by looking at the board or asking the vendor, not by guessing, which is why no part name is given here.

What you cannot validate on a development board

The board answers these well: does my model compile, does my pipeline come up, is the R5F partitioning sensible, is the software stack portable.

It does not answer these, and assuming it does is expensive:

1. Thermal behaviour. The board's cooling is not your enclosure. The AM67A's rated lifetime depends directly on the junction temperature profile.
2. Power integrity. The board's PMIC and power tree are a reference, not a validation.
3. EMC and ESD. An open development board behaves nothing like a sealed product.
4. Vibration and connector retention. FPC camera connectors and an M.2 slot need separate design work on a moving platform.
5. Secure boot. On the AM67A, security features depend on the part-number variant, and the full order code of the chip on this board is not published. If secure boot is in scope, the correct variant must be selected separately in the production design.
6. OTA and field maintenance. Two firmware domains — Linux and R5F — must be updated together.
7. Supply and lifetime. The relationship between board revision and the SoC order code is not documented.

Not published at the time of writing

An honest technical article needs a list of unknowns. For the T3 Gemstone O1, these are not officially published:

• Typical and maximum power consumption
• Physical dimensions, weight and mounting hole positions
• Operating temperature range
• The full order code of the AM67A fitted (and therefore its speed grade and security variant)
• The M.2 slot's officially declared PCIe generation and lane count
• Maximum HDMI resolution and refresh rate
• The LPDDR4 operating speed
• Any performance, power or thermal figure measured by an independent third party

Each of these is a gap to close before a product decision. None of them is a fault; they are simply information that has not been published yet.

Summary

The T3 Gemstone O1 is a well-considered development board that makes the AM67A accessible: the schematic is open, the documentation is bilingual and candid, the software path rests on TI's official Edge AI stack, and there is genuine upstream footprint in NuttX and ArduPilot.

It is also not a production platform, and it is not presented as one. It brings out two of the silicon's four cameras, one of four CAN channels and one of two Ethernet ports; power and thermal data are not published. Those are the natural consequences of being a development board. The problem is only making an architectural decision without knowing the difference.

If you are prototyping here with production in mind, answer two questions early: does your target model pass TIDL compilation, and can your real camera, network and CAN topology be validated on this board? If both answers are no, the right move is not to persist with the board but to start the carrier design sooner. We plan that transition in an embedded architecture audit.

Sources

1. T3 Gemstone — O1 board introduction and specifications — https://docs.t3gemstone.org/en/boards/o1/introduction
2. T3 Gemstone — TI AM67A page, including the note on TI documentation gaps — https://docs.t3gemstone.org/en/boards/o1/tiam67
3. T3 Gemstone — Edge AI ecosystem, installation and examples — https://docs.t3gemstone.org/en/boards/o1/ai/ecosystem
4. T3 Gemstone — Hardware repository and full 33-page schematic — https://github.com/t3gemstone/hardware
5. T3 Gemstone — object-tracker-o1 repository (T3's own measurements) — 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 — T3 Gemstone O1 board support — 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 October 2024 (same SoC, different board; power and thermal measurements) — https://www.cnx-software.com/2024/10/13/beagley-ai-review-sbc-debian-12-tensorflow-lite-ai-demos/

Documents accessed 5 September 2026. The board and its software stack are under active development; version, price and support status can change quickly.