OSM Modules with i.MX 91 & i.MX 93: A Comparison of 13 Modules (2026)

Key takeaways

• The silicon barely separates these modules. Ten of the twelve OSM modules share the same envelope: i.MX 9x, a maximum of 2 GB LPDDR4/4X on every module that specifies it, a single 5 V supply, 30 × 30 mm. eMMC ceilings range from 16 to 256 GB, and one module doesn't state one at all. Choosing by datasheet line items means comparing near-identical products.
• The differences live in documentation, BSP, and lifecycle — and there they are substantial: only one vendor ships a complete BSP manual, only three document a carrier board, and only two name an availability date.
• OSM 1.2 is backward compatible with 1.1 (SGET, November 11, 2024). The compatibility risk isn't in the revision but in the implementation: one vendor populates only 202 of the 332 contacts, and several don't state their contact count at all.
• The Cyber Resilience Act shifts the selection criteria. Reporting obligations for actively exploited vulnerabilities apply from September 11, 2026, and the full requirements from December 11, 2027. Not one vendor in this comparison states a support period for security updates.
• The i.MX 93 is the default. The i.MX 91 is the same device minus display, camera, NPU, and real-time core — a deliberate omission, not a cheaper entry point.

Anyone building an industrial Linux device on a solder-down system-on-module today is no longer deciding on compute performance alone. From September 11, 2026, the EU Cyber Resilience Act's reporting obligations for actively exploited vulnerabilities take effect, and from December 11, 2027, the full requirements for products with digital elements (Regulation (EU) 2024/2847, European Commission, accessed July 26, 2026). A module that enters a design in 2026 therefore has to be supplied with security updates for years — and that is exactly what the datasheets are loudest in not saying.

That creates an uncomfortable tension. The hardware in these modules is largely interchangeable; what actually determines the product's service life doesn't appear in the specification table. This comparison therefore looks at seven axes: silicon, form factor and second sourcing, documentation depth, power consumption, software and BSP, long-term availability, and carrier design and thermals.

Basis: 32 vendor documents covering 13 modules from nine vendors — datasheets, user guides, design guides, schematics, and BSP manuals — were evaluated in full and compared line by line. Wherever a manufacturer doesn't publish a figure, this comparison says "not specified" rather than supplying an estimate. Details are in the Methodology and sources section at the end of the article.

The Technologies and expertise page summarizes which SoC platforms and interfaces Teleconnect uses in customer projects.

The 13 modules at a glance

Twelve of the 13 modules are OSM compliant; the TQ-Systems TQMa93xxLA is a proprietary LGA module (38 × 38 mm, 281 pads) and serves here as a yardstick for what OSM compliance is worth in practice.

All 13 modules run from a single 5 V supply (typically ± 5 %), and ten of the twelve OSM modules use the 30 × 30 mm Size-S footprint. The temperature range converges as well: wherever a vendor gives numbers at all, it is usually up to three grades — 0 to +70 °C (commercial), −25 to +85 °C (extended), and −40 to +85 °C (industrial), with the industrial variant available from practically every manufacturer. At the specification level, then, these modules are largely swappable for one another — which shifts the decision onto the soft factors.

A note on naming: several vendors market their Size-S module as "OSM-SF." That is not a separate size class but the fully populated variant of Size-S — more on this in the section on the OSM standard. The table therefore lists the size class throughout, not the marketing designation.

And that is where the gap opens up. The analysis below counts how many of the nine vendors publish a given piece of information at all. "Complete pinout" here means a contact list from which every signal can be mapped to a contact — not just a block diagram of the interfaces.

The bottom three bars are the real story: software and lifecycle documentation is the exception in this market, not the rule.

i.MX 91 or i.MX 93: which SoC?

The i.MX 93 is the default. Reach for the i.MX 91 only when you're certain you need neither display nor camera, NPU, nor real-time core — because those are precisely the blocks NXP removes, and nothing else.

Both SoCs share the EdgeLock secure enclave, two Gigabit Ethernet ports (one of them TSN capable), LPDDR4 with inline ECC, and the same Cortex-A55 architecture. The i.MX 91 is not a different platform but an i.MX 93 without the multimedia, ML, and real-time blocks and with lower clock speeds.

The Ethos-U65 in the i.MX 93 runs at up to 1 GHz and delivers 0.5 TOPS at 256 MAC operations per cycle (NXP, accessed July 26, 2026).

Two traps that catch people regularly

1. Neither SoC has a 3D GPU. That surprises everyone who thinks of the i.MX 93 as "the graphics one." It has a 2D PXP engine and nothing beyond that. Any 3D-rendered interface, any OpenGL ES load, and any GPU compute task rules out both SoCs — that calls for a different i.MX family.

2. The NPU is a part-number decision, not a family decision. Within the i.MX 93, only the -5x parts (i.MX 9352, 9351) carry the Ethos-U65. A module with an i.MX 9332 or 9331 is an i.MX 93 with no NPU whatsoever. Several vendors in this comparison don't state which orderable i.MX 93 part they populate. Anyone planning on-device inference must have the exact part number confirmed before designing the module in.

Typical use cases the manufacturers themselves cite: meters, charging infrastructure and HVAC control, smart home and Matter devices, VoIP intercom stations, and headless gateways.

If you're still undecided within the i.MX 9 line, base the decision on the four blocks above — display, camera, NPU, real-time core — and not on clock frequency.

What the OSM standard actually governs

OSM (Open Standard Module) defines solder-down, connectorless modules — the module is reflow-soldered directly onto the carrier board via an LGA contact array. That makes assembly fully machine-processable and removes stack height, connector BOM, and one mechanical failure mode.

The standard is maintained by SGET (Standardization Group for Embedded Technologies) and defines four size classes that build on one another:

The electrical constraints on the contact array are stated concisely: a single 5 V primary supply, at least 0.5 A per soldered contact, and a power budget that scales with the number of VCC_IN_5V contacts (1 / 5 / 9 / 17 for Size-0 / S / M / L). Voltage slew rates above 50 V/ms should be avoided. For this SoC family, the Size-S ceiling of 12.5 W is comfortable — the i.MX 93 modules land at roughly 2 W.

The "F" in designations like OSM-SF and OSM-LF stands for the fully populated variant of the size class: OSM-SF means Size-S with all 332 contacts, OSM-LF means Size-L with 662. Important: that describes the designation, not a verified commitment — how far a specific module actually populates the contacts is a separate question (see the finding on 202 of 332 contacts below).

The price of this construction is spelled out unmistakably in several of the documents reviewed: the module cannot be removed. TQ puts it, for its own LGA part, as removal being "non-trivial and not recommended." Rework, field replacement, and prototype iteration all become more laborious as a result — a point that tends to get lost when budgeting the development phase.

Is second sourcing via OSM realistic?

At the specification level, yes; at the implementation level, not yet. That distinction is the most important finding in this comparison, and it is frequently blurred.

The good news first: SGET published OSM specification 1.2 on November 11, 2024, together with Design Guide 1.1, and in doing so explicitly declared full compatibility with modules based on OSM 1.1. The changes are additive: a single-channel LVDS interface now on Size-S as well (previously reserved for Size-L), a second CSI interface on Size-M, and a second I2S interface on Size-0 (SGET, accessed July 26, 2026). In addition, the standard reserves up to 58 pins for future extensions so that these remain backward compatible (SGET, accessed July 26, 2026).

That defuses the revision question — even though vendors in the field point to different versions:

The bad news sits one level down. The standard guarantees a pinout — it does not guarantee that two manufacturers populate it identically. Three observations from the documents:

• Contact assignment differs. One vendor openly documents populating only 202 of the 332 contacts. Another doesn't state how many of the 662 contacts on its Size-L module are populated. Several publish no contact count at all.
• At least one manufacturer deliberately deviates. In a footnote to its own datasheet, one vendor notes that the CARRIER_STBY# signal on its i.MX 93 module is inverted relative to the OSM standard. Swapping this module for another means swapping the polarity of a control signal along with it.
• Contradictions within individual datasheets. One datasheet says "322 Pin" on page 1 and "332 Contacts" on page 2 — a transposed digit that gets expensive in a bill of materials.

Practical consequence: OSM meaningfully lowers qualification costs for standardized form factors (NXP, accessed July 26, 2026), but it does not replace a pin-by-pin comparison. Anyone counting on second sourcing as risk mitigation has to compare the specific candidates in pairs — not just read their compliance claims.

We support exactly that comparison and the qualification of a second source as part of our hardware development work.

Documentation quality: the underrated selection axis

The spread in documentation depth is wider than any technical difference between these modules — and it predicts more about how the project will go.

At one end stands F&S Elektronik: CAD libraries for Cadence and Altium, 3D STEP models, a carrier implementation guide, and a cooling solution. That material alone is enough to start a carrier design. The AN-OSM01 implementation guide is largely vendor-neutral and usable for any Size-S design. That applies to the design documents — the i.MX 93 module datasheet, conversely, leaves several core specifications open. Depth of support and completeness of the datasheet are two different things here.

Geniatech is the most completely documented vendor in the comparison without being the most detailed: module, carrier board, and a genuine Yocto BSP manual on a named NXP base. Advantech supplies a datasheet, user guide, development kit manual, schematic, IO-MUX table, and CE certificate.

At the other end is a vendor whose module documentation consists of marketing brochures with version numbers below 1.0 — there, most specification lines read "not specified," including the temperature range.

A second, often overlooked axis is document status. Three of the richest datasheets in the comparison are marked PRELIMINARY or DRAFT — and all three withhold power consumption. One of those datasheets went through four revisions in five months, two of them to correct substantive errors. For components on a new SoC family that is normal; it does mean, though, that the numbers are still moving.

Depth of documentation is not the same as maturity of documentation. Both deserve separate assessment.

Power consumption: who measures, who estimates, who stays silent

Only one vendor publishes measured power figures. Geniatech states 1.24 W at idle and 2.41 W under load, each with the underlying voltage and current draw. Everyone else supplies a range, a maximum value, a contradictory set of numbers — or nothing.

Two patterns deserve attention. First: for one module, three documents from the same manufacturer give three different power figures — 2.1 W, 2.14 W, and 4.82 W. Between the lowest and the highest lies a factor of roughly 2.3 — and with it the question of whether a passive cooling concept holds up. Second: a "TBA" in a PRELIMINARY datasheet is honest enough, but it doesn't help with thermal design.

For a battery-powered or fanless design, one vendor's measured figure is worth more than another's longer feature list. Where no figure exists, request it in writing before design release — including the load scenario it refers to.

Software and BSP: Yocto is the common denominator

Everyone can do Yocto Linux; the only differentiator is who documents it. Of nine vendors, exactly one supplies a complete BSP manual. For all the others, software support is a feature list that can't be assessed from the available documentation.

A dash in the Named versions column means: the vendor names an operating system but neither a kernel version nor a Yocto release, layer names, release cadence, or support duration.

Three positionings stand out:

Toradex sells the lifecycle along with the module. Torizon OS comes with OTA updates, fleet monitoring, and remote access via Torizon Cloud, and is explicitly marketed as easing CRA compliance; the i.MX 93 module is prepared for Torizon OS, Yocto is fully supported, and FreeRTOS, Zephyr, QNX, and Android are available on request (Toradex; independently confirmed at CNX Software, both accessed July 26, 2026).

Ezurio sells security as a software product. It is the only vendor in the comparison offering paid lifecycle services rather than just a BSP: secure boot provisioning, key and certificate generation, a signing service, vulnerability monitoring against the customer's SBOM with schedulable notifications, and remediation via updated BSP releases. A FIPS 140-3 Level 1 crypto module has been announced. For regulated products, that can outweigh the specification differences.

F&S sells training instead of documentation. Qt, LVGL, and secure boot workshops are a real offering for a team building its first Linux product — but they don't replace a published BSP.

The biggest open question: NPU software

Seven modules in the comparison can be fitted with an NPU — for five of them that depends on the specific part number, and Geniatech doesn't even name the accelerator (just "256 MACs/cycle"). Exactly one vendor names NXP eIQ, and not a single one documents the Ethos driver stack or a model conversion workflow. Anyone putting on-device inference at the center of the product faces the largest gap in the entire comparison here — and should close it before selecting a module, not after.

Integrating such a stack — from BSP adaptation through model conversion — falls under firmware development.

Long-term availability and the CRA: the real risk question

Two of the nine vendors name a dated end of availability. F&S guarantees availability through 2039. Toradex names availability through 2038 for OSM and Lino plus a guaranteed lifecycle of more than 15 years (Toradex; independently confirmed at CNX Software, both accessed July 26, 2026). In the documents reviewed, the remaining seven publish no longevity program, no EOL policy, and no availability date.

For an industrial product with a ten-year field life, that is a direct question to put to every vendor — in writing.

It gets sharper still on security updates. Not one vendor in the comparison states a support period for software. Where longevity statements exist, they concern hardware availability, not the supply of security updates. That collides with the Cyber Resilience Act timeline:

Sources: Regulation (EU) 2024/2847 — the two main deadlines are confirmed by the European Commission ("the main … obligations apply from 11 December 2027, with the reporting obligations applying from 11 September 2026"); the deadline for conformity assessment bodies and the classification of the transitional rules per White & Case. Both accessed July 26, 2026. Products lawfully placed on the market before December 11, 2027, are generally exempt — as long as they undergo no "substantial modification" afterward.

In practice this means: the obligation to handle vulnerabilities rests with the manufacturer of the end device, but the ability to do so depends on the module vendor's BSP. This is exactly where the EdgeLock secure enclave in both SoCs is relevant — it provides root of trust, key management, and secure boot as a hardware foundation. What it does not provide is a vendor who ships patches for years.

So every inquiry should include this: How long will you supply security updates for this BSP, and at what cadence?

How secure boot, SBOMs, and vulnerability management can be built into a product is covered under product security.

Carrier design and thermals

Because the module is soldered down and not removable, OSM moves risk forward — into carrier design and manufacturing. A footprint error, an inadequate thermal path, or a wrong reflow profile shows up late and is expensive by then.

The best material for this comes from F&S: carrier footprint and pad design, stencil and paste, standoffs, routing and impedances, signal grouping and power distribution — together with Cadence and Altium symbols, PCB footprints, and 3D STEP models. The guidelines are largely vendor-neutral.

Two details from the analysis that can disrupt planning:

• The design data package contains 3D models for the i.MX 8M Mini, 8M Plus, 8ULP, and i.MX 93 variants — but no model for the i.MX 91, even though the vendor sells an i.MX 91 module.
• A reflow profile document is provided as an image-only PDF with no text layer. That makes it unsearchable, impossible to check by machine, and awkward to handle in a manufacturing release process.

Anyone planning their own carrier board should request the design data package and the reflow profile before deciding on a module and check whether the variant they need is included.

Footprint, layer stackup, impedances, and the reflow process for such a carrier board fall under PCB design.

Recommendations by use case

Rule of thumb: choose based on what is most likely to stall your project — not on clock frequency.

• Your own carrier board from scratch → F&S Elektronik. No other vendor delivers CAD libraries, 3D models, an implementation guide, and a cooling solution together. Plus the longest dated availability (2039).
• Fastest path to a working prototype → Geniatech. Module, carrier, and a documented Yocto BSP on a named NXP base, plus actually measured power figures.
• Regulated or safety-critical product → Ezurio. Vulnerability monitoring against your own SBOM, remediation, signing service, planned FIPS 140-3. Unique in this comparison.
• OTA updates and CRA evidence at the center → Toradex. Torizon OS with cloud connectivity, availability through 2038, explicitly geared toward CRA compliance.
• Maximum I/O headroom → the two Size-L modules (45 × 45 mm, up to 662 contacts per the size class) from Advantech and iWave.
• Widest SoC variant selection on one footprint → TRIA, with six documented i.MX 93 and two i.MX 91 variants.

Two cautions on orderability: for one module, the ordering table contains only pre-production part numbers and not a single orderable i.MX 91 part, even though the family is marketed as such. For another, all seven order models are listed as "TBD." Both are design-in candidates, not purchasable parts — something to clarify before BOM release.

Public pricing is rare in this market segment. For the Toradex modules it is documented: $25.55 for the OSM iMX91 and $28.20 for the OSM iMX93 in volume (CNX Software, March 31, 2026). They give a sense of the order of magnitude; binding prices are quoted by vendors on a per-project basis.

Questions to ask every vendor

This list follows directly from the gaps in the documents reviewed. It can be used as an inquiry template:

1. Which exact i.MX part number do you populate? (Determines NPU, core count, and clock speed.)
2. How many of the 332 or 662 contacts are populated, and does any signal deviate from the OSM definition?
3. Which OSM revision is the module designed to — 1.1 or 1.2?
4. What is the power consumption at idle and full load, measured, with the load scenario specified?
5. How long will the module be available, and is there a written EOL policy?
6. How long will you supply security updates for the BSP, at what cadence, and how are they delivered?
7. Which Yocto and kernel version is the current base, and which NXP release distro underlies it?
8. Is there a BSP manual and a documented carrier board?
9. Does the design data package include the variant we need — including the 3D model and the reflow profile as a verifiable document?
10. If using the NPU: which Ethos-U driver stack is integrated, and is there a documented model conversion workflow?

Frequently asked questions

Are OSM modules from different manufacturers interchangeable?

At the specification level the foundation is there: OSM defines a uniform pinout, and SGET declares OSM 1.2 fully compatible with 1.1 modules. In practice that isn't enough. Manufacturers populate different numbers of contacts, several don't state their contact count, and at least one inverts a control signal relative to the standard. A pin-by-pin comparison of the specific candidates remains indispensable.

Is the i.MX 91 worth it over the i.MX 93?

Only if you're certain you need no display over DSI or LVDS, no camera, no NPU, and no Cortex-M33. The i.MX 91 keeps the EdgeLock secure enclave and TSN Ethernet — that's the reason to prefer it over a true low-end device. If you're unsure about any of those points, take the i.MX 93: four vendors offer both SoCs on the same Size-S footprint, which allows a later switch without a carrier respin.

Can I render a 3D interface on these modules?

No. Neither the i.MX 91 nor the i.MX 93 has a 3D GPU; the i.MX 93 has only a 2D PXP engine. OpenGL ES workloads or GPU compute require a different i.MX family. Two-dimensional user interfaces, for example with LVGL or Qt over the framebuffer, are common on the i.MX 93.

How much compute does the NPU really deliver?

The Arm Ethos-U65 in the i.MX 93 delivers 0.5 TOPS at up to 1 GHz. It sits only on the -5x parts, though (i.MX 9352, 9351). An i.MX 9332 or 9331 has no NPU. Since several vendors don't name the part number they populate, NPU availability has to be confirmed before selection.

Why is non-removability a cost factor?

A reflow-soldered module can't be swapped like a plug-in one. That affects three phases: prototype iteration slows down, rework in manufacturing requires equipment and process approval, and replacing the module alone in the field is practically impossible — in a service case, the whole assembly is replaced. Set against that are eliminated connector costs, lower stack height, and greater shock and vibration resistance.

Conclusion

The market for OSM modules based on the i.MX 91 and i.MX 93 is technically narrower than the number of vendors suggests. Thirteen modules, nine vendors — and at their core the same silicon with a maximum of 2 GB of RAM, on the same 30 × 30 mm for ten of the twelve OSM modules.

What remains are three questions no datasheet fully answers:

• Who documents in a way that lets you evaluate the module before buying? One vendor supplies a BSP manual; three supply a documented carrier board.
• Who commits to a date? Two of nine name an end of availability — 2038 and 2039.
• Who will supply you with security updates for as long as your product is in the field? In the documents reviewed, nobody answers that with a number. Given the CRA deadlines starting September 2026, that's the most expensive open question in the entire comparison.

Standardized form factors lower qualification costs — but only for those who ask the right questions before design release.

Use the question list from the "Questions to ask every vendor" section as an inquiry template for your shortlist. Ten questions, asked in writing, separate the vendors faster than any datasheet comparison. If you'd rather not handle the selection or the carrier design alone: talk to us about module selection.

You'll find more technical articles on the Teleconnect blog.

Methodology and sources

This comparison is based on the complete evaluation of 32 vendor documents covering 13 modules from nine vendors: datasheets, user guides, design and implementation guides, schematics, IO-MUX tables, BSP manuals, and certificates. Four rules guided the analysis:

1. "Not specified" is a result. Where a manufacturer doesn't publish a figure, that's what it says — instead of an estimate or a number from another source.
2. Contradictions are recorded, not smoothed over. Where two documents from the same manufacturer contradict each other, both readings are noted.
3. Document status is part of the finding. PRELIMINARY, DRAFT, and brochure status are captured as well.
4. Vendors are not named on critically assessed points. Positive findings are attributed by name; gaps are described categorically.

The OSM specification itself does not underlie this analysis; statements about the standard and revisions 1.1 and 1.2 come from SGET's public releases. External sources are linked in the text with their access date.

As of: July 26, 2026. Datasheets for this module generation change frequently — check the current revision with the manufacturer before making a design decision.