Suppose a device needs two cameras, two wired network connections, and a display. A supplier sends back a one-page RK3588 or RK3576 specification headed “6 TOPS, eight cores.” Neither number answers the first design question: can the particular core board and carrier board run those interfaces together? A SoC may expose a controller that the module does not bring to its connector, or the carrier may route a high-speed lane to a different peripheral. For a single-display controller with one Ethernet port and modest local inference, starting with RK3588 by default may buy capability the product cannot use.
The useful first pass is elimination, not a four-chip performance ladder. List the interfaces and software constraints that cannot be traded away. Use Rockchip's public SoC documentation to narrow the field. Then request evidence for the exact module revision and carrier design, and test sustained operation in the product enclosure. This article supports that documentation-stage shortlist. It is not a measured comparison of frame rate, power, temperature, unit price, or availability.
Start with interfaces that must operate at the same time
Write a simultaneous-use requirement, such as “two camera inputs + two physical Ethernet ports + NVMe storage + one touch display,” rather than four independent checkboxes. The camera path still has to coexist with display, video processing, storage, and network traffic at the required resolution and format. A controller on the SoC block diagram is not proof that the module exposes it; a signal on the module connector is not proof that the carrier provides a usable port. Extra NPU capacity cannot create a lane already assigned elsewhere.
The distinction is especially important for shared high-speed resources. Rockchip's RK3576 product page lists USB 3.0, PCIe 2.1, and SATA among combo interface options. Those labels should not be counted as independent ports in the same configuration. The RK3566 brief datasheet likewise describes shared high-speed resources. Ask the board supplier to map the exact target peripherals to pins and mux selections before freezing a design.
Software can eliminate a candidate even when the wiring works. “Boots Linux” is weaker than “the supplier's current BSP supports this camera sensor, display panel, network PHY, and NPU runtime together.” Record the module and carrier revisions, kernel branch, device tree, image version, driver ownership, and patch path. A boot demo proves only the first step. Products with field updates and component substitutions need a maintainable software combination, not an isolated demonstration.
The decision path separates documentation screening from product testing. Failure at either hardware gate ends the current board proposal; passing them only qualifies a module-and-carrier combination for a reproducible software check and sample test.
Where each SoC belongs on an initial shortlist
The following rows identify plausible evaluation tasks and the first board-level question for each chip. They do not rank four tested products under one workload.
| Candidate | Reason to evaluate it | First question for the module vendor |
|---|---|---|
| RK3588 | Multiple high-resolution vision inputs, complex displays, or substantial high-speed expansion | Which camera, display, PCIe/storage, and Ethernet paths are exposed concurrently, and how is the enclosure cooled? |
| RK3576 | A display-and-vision terminal with industrial connections | How are combo lanes assigned, are both network paths and CAN FD exposed on this board revision, and which BSP is supported? |
| RK3568 | A gateway, HMI, or lighter vision device that still needs networking and expansion | What do the module connector and carrier actually provide for Ethernet, PCIe/SATA, image support, and temperature range? |
| RK3566 | A single-screen or lighter edge-control device where limited expansion is acceptable | Are its exposed peripherals, shared lanes, memory, and runtime headroom sufficient for the target application? |
RK3588 and RK3576 share a headline NPU figure, not a system profile
The RK3588 product page describes four Cortex-A76 and four A55 cores, multiple camera inputs, high-resolution media capabilities, and a 6 TOPS NPU. Rockchip describes RK3576 with four A72 and four A53 cores, a 6 TOPS NPU, multiple display options, CAN FD, and two RGMII interfaces. Equal advertised NPU figures do not establish equal operator coverage, CPU preprocessing time, memory behavior, video throughput, or sustained performance.
For a product dominated by several camera streams, complex display output, and fast storage, include an RK3588 board in the test set. For a display-focused industrial terminal that also needs network and field-bus connections, an RK3576 board deserves evaluation. These are reasons to request pinout and BSP evidence, not promises about which finished device will perform better.
Do not transfer a carrier's connector list to every board using the same SoC. Firefly, for example, describes Core-3588JD4 together with the MB-JD4-RK3588 carrier in its AIO development board; HDMI, serial, camera, and other accessible connectors belong to that defined combination. Another RK3588 module can have a different board-to-board connector, power design, image, or manufacturing revision.
RK3568 and RK3566 need separate network and expansion checks
The RK3568 brief datasheet and RK3566 brief datasheet both describe quad-core A55 devices with media and edge-compute resources. That common ground puts them in the same early screening exercise, but does not make their boards interchangeable. If a gateway needs two independent wired networks plus high-speed storage and expansion, ask an RK3568 supplier for the exact port and lane map. If one physical network and modest peripherals meet the requirement, an RK3566 module may remain in scope. Neither conclusion establishes price or power savings; those need like-for-like quotations and measurements.
Firefly's Core-3568J and Core-3566JD4 documentation shows how a specific module is paired with a carrier to make a usable development system. It is a useful prompt for supplier questions, not a universal specification for all RK3568 or RK3566 boards. Readers assessing a narrower gateway workload can also see our RK3566 AIoT gateway selection boundaries.
Three pieces of evidence turn a chip shortlist into a board shortlist
Illustrative scene only. It is not a sample test or evidence that the pictured connectors support the proposed workload.
First, request an interface and concurrency map for the exact core-board revision. A pinout, board-to-board connector definition, carrier schematic, or supplier-signed interface matrix should show camera lanes, display outputs, PHYs, PCIe, SATA, USB, CAN, serial, and debug paths in one place. Mark mux alternatives explicitly. A design supported only by a SoC block diagram, without evidence that the board exposes the required combination, is not ready for board freeze.
Second, request a reproducible software set: module and carrier revisions, bootloader, kernel and device tree, Linux or Android image, NPU runtime, relevant camera and display drivers, and the supplier's update channel. Ask for a minimal image and test steps for the functions the product will actually ship. For “two cameras, local inference, and network upload,” a camera preview and an unrelated NPU demo are not an end-to-end validation. Acquisition, preprocessing, inference, output, and error recovery need to run in one versioned setup. This is a test plan, not a claim that we have tested these boards.
Third, define the sustained-operation boundary. Published operating-temperature ranges and heatsink recommendations do not predict temperature inside the final enclosure. At the intended ambient temperature, record frequency, power, dropped frames, restart behavior, and component temperatures while the actual peripherals run together. A gateway also needs tests for network loss, power loss, storage wear, and recovery. Until those records exist, the honest conclusion is “eligible for evaluation,” not “production-ready.”
This is a different decision from choosing a development board versus a module and carrier. Our guide to Rockchip dev boards, SoMs, and carrier boards covers ownership and purchasing stages. Here the choice is already a core-board route; the question is whether a particular implementation satisfies the product's simultaneous requirements.
Apply the evidence to the product, not to a chip hierarchy
For a multi-camera industrial vision device, give RK3588 and RK3576 board suppliers the same sensor, resolution, encoding, display, network, and storage workload. Compare their pinout and lane allocation first. Then run the same model and runtime version on candidate hardware inside a representative thermal setup. Decide whether RK3568 or RK3566 should leave the list based on the target chain, not a presumed market tier. Both six-TOPS labels leave end-to-end frame rate and cooling unresolved.
For a dual-network gateway with a local HMI, establish whether the networks must be physically independent and whether cellular, CAN, isolated serial, or maintainable storage is also required. RK3568 and RK3576 are reasonable documentation-stage candidates; a single-network, single-screen product may also retain RK3566. Require a board-specific PHY and connector map, then test the actual protocols and recovery behavior. CPU or NPU peaks are poor substitutes for wiring, power, and update evidence.
For a single-display controller, ask whether multiple video streams, fast storage, or complex inference are genuine requirements. If not, begin with specific RK3566 or RK3568 modules and add RK3576 or RK3588 only when an identified display, vision, or industrial interface exceeds their board-level resources. Do not infer lower price or power from the chip name. Quotations become comparable only after memory, storage, carrier, cooling, quantity, and support terms are held constant.
When none of the four is the right starting point
A product doing simple sensing and control, without Linux-class applications or media processing, may be better served by an MCU or a simpler platform. If the hard constraint is cellular certification, electrical isolation, deterministic control, or long-term supply, select around that system boundary first. Familiarity with Rockchip is not a reason to force one of these application processors into the design. Conversely, if a specific peripheral driver or NPU operator is mandatory and the available BSP cannot establish support, a generic “Linux supported” statement should not keep a board on the shortlist.
The useful output of this phase is a record of rejected candidates and why they failed, plus no more than two module-and-carrier combinations for sample testing. Attach each combination's interface map, software versions, power and cooling proposal, and the workload that must be measured. The next discussion can then be about a reproducible product configuration rather than an abstract claim that one chip is “stronger.”
Sources and scope
- Rockchip RK3588 product specifications
- Rockchip RK3576 product specifications
- Rockchip RK3568 brief datasheet
- Rockchip RK3566 brief datasheet
- Firefly Core-3588JD4, Core-3576JD4, Core-3568J, and Core-3566JD4
The conclusions above are limited to public SoC and board documentation. We have not examined the target module's complete connector definition, current BSP release notes, orderable part number, or a like-for-like workload measurement. The product scenarios are selection exercises, not results from a ZedIoT or customer deployment.