Two suppliers quote an “RK3588 compute module.” One sample boots on the supplier's development carrier; the other quote is cheaper. Can procurement rank the unit prices and place the order? Not yet. The offers may refer to different SoC variants, memory and storage options, connectors, hardware revisions, and software-support boundaries. A booting development kit does not establish that the target product's carrier board and peripherals work.
Before comparing price, make every offer identify one reproducible delivery combination: the exact module ordering configuration, the intended carrier and interface revision, and the software image or BSP that the supplier will deliver and support. This is an RFQ and acceptance problem for a team that has already chosen the compute-module route. If the team is still deciding between a development board, module, carrier board, or custom PCB, the earlier board-type comparison addresses that decision.
A SoC family name is not an orderable configuration
A Rockchip SoC datasheet describes capabilities at chip level. A particular module vendor decides which interfaces reach its connector, what memory and storage are fitted, and how power is designed. The carrier then determines the socket, supply, protection, and actual peripherals. “RK3588, 8GB, Linux” therefore does not uniquely identify the hardware and software that will arrive in a box.
The RFQ identity chain should connect a quoted SKU to the full module order code and configuration, module hardware revision, applicable pinout, target carrier revision, and software-image or BSP release. Procurement need not assess every high-speed signal itself. It does need hardware and software owners to approve the same versioned combination. Otherwise the buyer may compare prices, the hardware engineer may inspect a sample photograph, and the software engineer may test a public image without anyone noticing that these refer to different configurations.
Radxa provides a useful public example, not a rule about all Rockchip products. Its NX5 product page identifies an RK3588S-based module with a 260-pin SO-DIMM connector and distinguishes the module, IO board, and development kit. The NX5 downloads page lists V1.1 module design and pinout files, V1.4 IO-board design files, and system images separately. A shared “RK3588 series” label or a development-kit image cannot replace those versioned files.
Ask what “compatible” actually means
An RFQ line can request the complete order code, RAM/eMMC option, module revision, matching design-file revision, supported carrier revision, and image or BSP identifier. A missing field should remain pending evidence, with an owner and due point in the sample stage; it should not silently mean “same as the prototype.”
Compatibility also needs an object. Is the seller promising mechanical fit, matching pins and voltages, a boot on its reference carrier, or the product's camera, Ethernet, display, and update path on your carrier? Those are different claims. For an existing carrier, hardware should first check power, connector, critical pins, and lane assignments; software should then check the device tree, drivers, and boot medium. Where either conclusion depends on an undelivered proprietary document, the offer can remain a quotation candidate, but it is not yet an approved drop-in replacement.
A revision can change a circuit, not just a printed letter
Radxa's CM5 hardware revision history records changes involving eMMC/SDMMC routing in one revision and, in later entries, HDMI detection, Ethernet PHY configuration, fan circuitry, and I2C pin positions. This does not prove that every CM5 revision is incompatible, nor does it say anything universal about other vendors. It shows why a revision identifier can affect a project's carrier and software acceptance scope.
The CM5 downloads page lists CM5 V2.21 and CM5 IO V2.2 design resources separately, along with images for different board combinations. Its hardware-interface page explicitly warns against installing a CM5 on a CM3 IO board. Public files being available is not evidence that two similar-looking carriers are interchangeable. A proposed “same-family substitute” needs a review of the actual module, carrier, and image combination.
Here is one RFQ/acceptance record built from public CM5 information. The right-hand column remains blank until a supplier and project team provide it. This is not a supplier quote, approved configuration, or delivery commitment.
| Field in one versioned record | What public documentation establishes | What the order and sample must still establish |
|---|---|---|
| Quoted identity | CM5 is a product family; public pages do not identify a unique SKU for this RFQ | Quoted SKU, full order code, RAM/eMMC option, sample label, and quote validity |
| Module and interface baseline | The downloads page offers CM5 V2.21 schematics and pinout; revision history describes changes across versions | Actual sample revision, its matching pinout, and a check against the target carrier's connector and voltage design |
| Carrier baseline | CM5 IO V2.2 design files are published | Target-product carrier revision and schematic; the official IO-board files do not validate a different carrier |
| Software baseline | Download entries distinguish CM5/CM5 Lite and different carrier-image combinations | Exact delivered image release and hash, boot medium, BSP/driver support owner, and test result on the target carrier |
| Sample-to-batch handoff | Public pages contain no project purchase order, batch, or measurement | Batch and label traceability, approved sample ID, change-notice route, affected tests, and reviewer |
Use the same record ID for quotation, sample approval, and incoming-batch inspection. Radxa's revision history lists an I2C5/I2C7 pin-position swap under V2.2, while the downloads page provides a V2.21 pinout. If a delivered sample's revision differs from the project's approved revision, obtain the interface documents for the two actual revisions, compare them against the target carrier, and then check device-tree and peripheral behavior. Do not approve equivalence merely because the part is still called CM5. This is a trigger for review, not a claim that a particular customer received a changed batch or that a specific carrier will fail. PCN timing, permitted substitutions, and return responsibility must be agreed in the purchase terms, not inferred from a public revision page.
This flow covers first-batch intake only; sample approval is a separate, earlier decision. Only passed tests and records agreed for this project permit acceptance of this batch; that does not establish certification or long-term reliability.
RFQ, target-carrier sample, and first batch are three decisions
“The sample runs” is often recorded as if procurement were finished. A test proves only that the tested combination behaved under the tested conditions. It does not prove identical production batches, long-term availability, or operation in the product's thermal environment. Separate the decision points: the RFQ establishes comparability, the sample establishes behavior on the target system, and the first batch establishes that the delivered configuration remains the approved one.
Illustration only: no particular Rockchip module, customer shipment, or inspection result is represented.
| Decision point | Minimum record | What stays on hold if it is missing |
|---|---|---|
| Compare offers | Full module code, RAM/eMMC, revision, applicable pinout/design-file version, image/BSP identifier, and written commercial terms for the exact configuration | Like-for-like price ranking and substitute approval |
| Approve a sample | Label tied to the order identity; target-carrier test conditions and results for boot medium, key peripherals, recovery, and intended workload | Treating a supplier development kit's success as product acceptance |
| Receive the first batch | Batch/label match to the approved sample, traceable revision and flashing image, review of any declared changes | Automatic intake or shipment on a “same family” description |
These are proposed contract and test fields, not measurements performed for any model in this article. Workload, temperature range, vibration, EMC, radio, and regulatory tests depend on the target product and applicable standards. A supplier's public specification cannot establish a customer's batch yield or enclosure thermals. Without test records, the acceptance state is “to be tested,” not “passed.”
Test the route the product will actually use
If the product needs two cameras, the target-carrier test should cover the CSI lanes in use, device-tree configuration, driver behavior, and sustained capture. If remote updates are required, include flashing, interrupted updates, and a recovery entry. The list should follow the product's actual functions, not copy every feature from a chip marketing sheet. The purchase record can refer to an engineering-approved test ID and image hash, so later batches cannot be signed off with a vague “Linux works.”
Thermal claims need the same discipline. A module's published operating specification is not an enclosure test. Carrier power, airflow, heat spreader, and sustained workload change the operating conditions. For a high-load device, define how steady-state temperature, throttling, and recovery will be recorded in the intended enclosure. That is not a universal test-duration recipe; it is the evidence bridge between a purchase promise and the project's real use conditions.
The lower unit price may leave more work unpriced
One offer may include carrier adaptation, a maintained BSP, and support for diagnosing peripheral issues. Another may cover only a bare module and an image for the supplier's IO board. If these scopes are compared as one board price, the missing engineering cost appears after the order. Ask separately whether carrier design files are available, which BSP release is supported and for how long, who owns critical drivers, who reruns tests for a substitute, and who retains batch identifiers.
Lead time, MOQ, AVL, EOL, and PCN terms likewise require written confirmation for the exact orderable configuration. An “in stock” channel page or a family-level supply statement cannot prove the delivery date for your variant. If continuous supply matters and a seller will not define change notice and substitution review, record that as a commercial and quality risk. Do not expect engineers to absorb it later through an emergency carrier redesign.
Only after competing offers complete the same version record should the team compare price and delivery responsibility. An offer containing just SoC, RAM, and unit price is still useful for an initial inquiry; it is not a production purchase decision. If sample or batch inspection finds an unrecorded revision or image change, return to the appropriate hardware and software review point rather than asking procurement to declare equivalence.
For a joint review of module sourcing, carrier requirements, software images, and deliverables, start from the Rockchip compute-module and carrier-board sourcing page with your required interfaces, expected volume, and software environment. This article has no supplier quote, customer AVL, incoming-batch record, or target-board test result. It therefore recommends no particular supplier and makes no lead-time or reliability promise.