How to Add a Third Ethernet Interface with W5500 on the Forlinx OKMX9352-C?

Summary

The Forlinx OKMX9352-C already has two native Gigabit Ethernet ports, so adding a WIZnet W5500 is not about compensating for insufficient processing power. It is about providing another physical network connection when the existing interfaces already have assigned roles. Forlinx demonstrates an SPI-connected Linux network interface; the strongest potential applications are a dedicated maintenance connection or a separate, low-bandwidth equipment network.

What the Project Does

Forlinx Embedded develops ARM-based System-on-Modules, Single Board Computers, and industrial embedded computers using processors from vendors such as NXP, Texas Instruments, Rockchip, and Allwinner. Its products are aimed primarily at industrial and edge-computing applications, where carrier-board interfaces often need to be adapted to application-specific networking and I/O requirements.

The project uses the Forlinx OKMX9352-C platform based on the NXP i.MX93 processor. The SoC combines two Cortex-A55 application cores with a Cortex-M33 real-time core.
 

The platform already provides native Ethernet connectivity. This makes the W5500 example interesting because it demonstrates how another Ethernet interface can be added through SPI when a product needs an additional physically separate network connection.

The processor configuration and Ethernet configuration should be considered separately. Having more CPU cores does not create more Ethernet controllers or physical network ports.

A system using one native port for a factory network and the second native port for a machine network may therefore need another interface if a dedicated service or equipment connection is also required.

Where WIZnet Fits

The W5500 is connected to the i.MX93 through the LPSPI3 peripheral.

In the demonstrated configuration, the W5500 is controlled by Linux running on the Cortex-A55 side. There is no indication that the Cortex-M33 participates in the W5500 data path.

The architecture can be represented as:

i.MX9352 SoC
│
├─ Cortex-A55 cores running Linux
│    │
│    ├─ Native Ethernet MAC → PHY → Gigabit port 1
│    │
│    ├─ Native Ethernet MAC → PHY → Gigabit port 2
│    │
│    └─ LPSPI3 → W5500 → Additional Ethernet port
│
└─ Cortex-M33
     No demonstrated role in the W5500 connection

The W5500 provides its own Ethernet MAC and 10/100 Ethernet PHY. It therefore adds another Ethernet controller through SPI rather than attaching another PHY to one of the i.MX93 native Ethernet controllers.

Potential Use Case: Dedicated Maintenance Port

A practical industrial configuration could look like this:

In this architecture, a technician could connect a laptop directly to the W5500 port for configuration, diagnostics, firmware management, or log retrieval without disconnecting the production networks.

This is a potential architecture rather than an application explicitly demonstrated by Forlinx.

The additional port also does not automatically provide security isolation. Linux routing, firewall rules, service binding, and forwarding configuration would still determine whether traffic can move between networks.

Potential Use Case: Separate Equipment Network

Another possible use is connecting lower-bandwidth industrial devices such as PLCs, measurement equipment, scanners, or legacy Ethernet devices.

The data flow could be:

Industrial Device
        ↕
      W5500
        ↕
Linux Application
        ↕
Native Ethernet
        ↕
Factory Network

The W5500 interface could handle equipment communication while one of the native Ethernet ports handles upstream communication.

This is particularly reasonable when the additional network does not require Gigabit throughput.

When W5500 May Not Be Necessary

If one of the native Ethernet interfaces is unused, using the existing controller will normally be simpler.

Likewise, if the goal is only to connect more devices to the same Ethernet network, an Ethernet switch may be more appropriate.

Managed switches and VLANs can also provide logical traffic segmentation without adding another host Ethernet controller.

The W5500 becomes most interesting when the product specifically needs another independently controlled physical Ethernet interface and SPI is available.

Implementation Notes

The Linux implementation is important because it changes how the W5500 should be understood in this example.

The Linux WIZnet driver configures the controller in MACRAW mode:

u8 mode = S0_MR_MACRAW;

This configuration causes the W5500 to operate as a raw Ethernet interface.

Linux continues to handle the IP, TCP, and UDP networking stack. The W5500 transfers Ethernet frames between the physical network and the Linux driver.

Therefore, this example is not primarily demonstrating W5500 TCP/IP hardware offload.

Although the W5500 supports hardware TCP/IP sockets, that capability is not the main reason it is useful in this Linux configuration.

Its role here is primarily:

• Adding another Ethernet MAC
• Adding another Ethernet PHY
• Providing packet buffering
• Connecting the additional network interface through SPI

This also explains why using the W5500 still makes sense with a dual Cortex-A55 processor.

The processor does not need TCP/IP acceleration. The system needs another network interface.

Could the Cortex-M33 Control a W5500 Instead?

A different architecture could assign a W5500 to the Cortex-M33.

In such a design, the M33 could use a WIZnet socket API directly while Linux continues using the native Ethernet controllers.

For example:

Cortex-A55 / Linux
├─ Native Ethernet 1
└─ Native Ethernet 2

Cortex-M33 Firmware
└─ SPI → W5500 → Dedicated Ethernet

This could be useful for applications requiring a networking function that operates independently from the main Linux application.

However, this is not the architecture demonstrated in the Forlinx project.

Implementing it would require explicit peripheral ownership, firmware development, clock configuration, interrupt routing, and system-level reset planning.

Practical Tips / Pitfalls

• Use the native Gigabit ports for high-bandwidth traffic. The W5500 is better suited to auxiliary networking, maintenance, or equipment communication in this platform.
• Consider SPI bandwidth carefully. Forlinx configures the SPI interface at 15 MHz, which places a significant limit on achievable host-to-W5500 throughput.
• Do not assume 100 Mbps Ethernet means 100 Mbps application throughput. SPI transfer speed and protocol overhead can become the real bottleneck.
• Check voltage compatibility. Confirm that the i.MX93 SPI I/O voltage matches the W5500 module or add level translation where required.
• Design the network policy explicitly. A separate Ethernet connector does not automatically create a secure network boundary.
• Remember that Linux owns the interface in this implementation. If Linux stops operating, this W5500 connection does not automatically become an independent recovery interface.

FAQ

• Why use W5500 when the i.MX93 already has Ethernet?
  The primary reason is to add another physical Ethernet interface after the native ports have already been allocated. It is not primarily intended to reduce Cortex-A55 networking load in this Linux configuration.
   
• How does W5500 connect to the OKMX9352-C?
  The W5500 connects through the i.MX93 LPSPI3 peripheral using SPI signals such as SCLK, MOSI, MISO, and chip select, together with GPIO control signals where required.
   
• What role does W5500 play in this project?
  It creates an additional Linux Ethernet interface through SPI. This third interface can potentially be used for maintenance, equipment communication, diagnostics, or a separate network segment.
   
• Can beginners reproduce this project?
  The hardware connection itself is relatively straightforward, but the complete integration requires some embedded Linux experience. Developers should understand device trees, SPI configuration, kernel drivers, GPIOs, and basic Linux network configuration.
   
• How does W5500 compare with adding an Ethernet switch?
  An Ethernet switch expands the number of devices that can share an existing Ethernet controller. The W5500 instead gives Linux another independently controlled Ethernet controller through SPI. A switch is better when more ports are needed on the same network, while the W5500 is more relevant when another host-side network interface is required.