RK3568 Industrial Gateway: Dual-Ethernet Design and Validation

A gateway with two Ethernet sockets is not necessarily a gateway with two dependable network paths. For an RK3568 industrial gateway, the first design task is understanding how both ports reach the processor and what the software does between them.

RK3568 is a useful starting point because its two Ethernet MACs can support a native dual-port architecture when the board supplies the required external circuitry. That is a platform capability, not a promise that every RK3568 SBC implements two ports or qualifies them for an industrial environment.

This guide covers architecture and validation. It does not claim certified isolation, guaranteed forwarding throughput, or deterministic control performance for an unspecified board.

Define the boundary between the networks

Decide whether the product is a router, bridge, protocol converter, data concentrator, or application endpoint. These roles require different forwarding policies and failure behavior.

A machine-facing network and a management network often should remain separated. State which connections may cross that boundary, in which direction, and through which application or protocol. Avoid letting an early development bridge become the production security policy by accident.

Define what happens when either side is unavailable. Should measurements buffer locally, should commands be rejected, and how should the operator discover stale data? The answers affect RAM, storage, timestamps, and watchdog design.

Two ports do not make the system a safety controller. Keep safety functions and their required assurance within an appropriate architecture. Ordinary application Linux or Android networking should not be assigned deterministic safety behavior without the necessary system design and validation.

Follow each port from MAC to cable

A complete Ethernet port includes more than the processor MAC. Check the PHY, reference clock, reset sequencing, RGMII timing, magnetics, connector, protection, and board layout.

Ask whether both ports use native MAC paths. A USB Ethernet device can be suitable in some products, but it adds a controller, a shared bus, and another driver dependency. It should appear explicitly in the block diagram and acceptance tests.

RGMII timing deserves particular attention on a custom board. Delay settings must match the PHY configuration and PCB timing budget. Blindly copying a device-tree setting from another board can create a link that appears healthy while suffering errors under changing conditions.

The RK3566 vs RK3568 comparison explains why interface topology often matters more than CPU similarity. Confirm the schematic of the proposed board rather than inferring its connections from the SoC family.

Choose the operating system from the gateway role

Linux is a natural evaluation candidate for a headless gateway with routing, firewalling, service supervision, and industrial protocol libraries. Its usefulness still depends on the delivered kernel, drivers, distribution integration, and maintenance plan.

Android can fit a gateway that also provides a substantial local touchscreen interface. However, application permissions, network selection, background execution, and privileged configuration can require deeper platform integration than a desktop-style demonstration suggests.

Do not assume an Android application can freely configure both interfaces or control forwarding rules. Ask the BSP provider to demonstrate the required policy through the supported application interface and production security configuration.

For either operating system, decide who owns network configuration. Competing scripts, framework services, and application code can overwrite each other’s settings after boot or cable changes. One documented authority should manage persistent addresses, routes, DNS behavior, and recovery.

Measure forwarding with realistic traffic

A link negotiated at 1Gbps does not establish application throughput. Packet size, simultaneous directions, encryption, firewall rules, logging, and protocol conversion all affect the result.

Test small packets as well as large transfers. Packet processing can become CPU-limited before a bulk-transfer benchmark reveals a problem. Measure the workload with the intended rules and services enabled.

Include both ports concurrently and record CPU load, memory use, packet drops, errors, and application latency. If the gateway writes local history, run those writes during network tests rather than treating storage as a separate idle-system exercise.

A useful acceptance matrix covers normal operation, maximum expected load, reconnect events, and recovery after an update. Define the required result for each case before measuring; otherwise, a collection of attractive throughput numbers can replace an actual release decision.

Field interfaces need electrical boundaries

Many gateways combine Ethernet with CAN, RS485, digital inputs, or serial instruments. Identify the electrical interface behind every connector, including transceivers and isolation.

A UART header is not an RS485 port. A CAN controller is not a complete protected bus connection. Specify termination, biasing where needed, grounding strategy, cable assumptions, and behavior under plausible wiring errors.

The industrial interface guide helps separate protocol choice from the circuitry required to reach field equipment. Confirm support through the actual production driver and API.

Pay attention to timestamps. If readings from several buses are combined, define when each timestamp is created and how clock synchronization is maintained. Stale data should not become indistinguishable from a fresh measurement after a reconnect.

Design recovery as a normal operating path

Give both ports stable, documented identities. Verify how the image assigns interface names and MAC addresses, and what happens after a component or board revision. A configuration that binds the management network to whichever port appears first can reverse the intended boundary after an update. Factory testing should verify the physical label, configured role, and address on each port.

Gateways may run unattended for long periods. Provide a documented way to recover after a failed application release, corrupted configuration, or interrupted update.

A hardware watchdog should supervise useful progress rather than simply prove that a timer thread still runs. Tie service health to acquisition, forwarding, and communication where appropriate, while avoiding reboot loops during an external network outage.

Store data with a clear retention policy. Bound queues, rotate logs, and define what happens when storage reaches its limit. A full filesystem should produce a controlled degradation instead of preventing the next boot.

Power interruption testing belongs in the release plan. Use the intended storage and supply arrangement, preserve fault logs, and check that configuration remains valid. A clean restart command is not a substitute for testing an unexpected loss of input power.

Approve an evidence package for production

Request the exact board revision, PHY identification, BSP version, application build, enclosure configuration, and production-test scope. Keep these identifiers with the network and recovery logs.

Review update ownership before placing a volume order. The Android BSP checklist is useful even when Linux is chosen because source delivery, driver maintenance, and recovery responsibilities still need explicit owners.

RK3568 works well as a dual-Ethernet gateway candidate when its native connections reduce unnecessary bridging hardware and its software meets the routing or application requirements. That advantage becomes meaningful only after concurrent traffic, field interfaces, thermal conditions, and recovery have been validated together.

Technical basis: Rockchip RK3568 platform documentation and the proposed board’s schematic, PHY documentation, and BSP release notes. Industrial qualification and network performance remain properties of the tested complete system.