SPI to Ethernet Communication on Forlinx OK-MX9352-C Board: W5500 Driver Setup & Debug Guide

This article takes Forlinx Embedded’s OK-MX9352-C development board as an example to elaborate on how to adapt the network port module through the SPI interface to achieve Ethernet communication. The W5500 module, a high-performance SPI to 100Mbps Ethernet chip with up to 80Mbps data rate, suits embedded network needs.

Modules used:

Hardware Connection

Wiring between W5500 and OK-MX9352-C is in the table below.

Among them, SCS is the chip-select signal, MISO is the master-in slave-out data line, MOSI is the master-out slave-in data line, SCLK is the clock signal, INT is the interrupt signal, and RST is the reset signal.

Software Configuration and Driver Debugging

1. Compilation Drive

First, add the relevant options to the kernel configuration

> Device Drivers      > Network device support          > Ethernet driver support             ......             [*]   WIZnet devicesWIZnet W5100 Ethernet support                                                                                 			< >     WIZnet W5300 Ethernet support            WIZnet interface mode (Select interface mode in runtime)  --->WIZnet W5100/W5200/W5500 Ethernet support for SPI mode            ......

2. Devie Tree Modification

Add the relevant configuration of W5500 under SPI3 node.

&lpspi3 {    fsl,spi-num-chipselects =;    pinctrl-names = "default", "sleep";    pinctrl-0 = <&pinctrl_lpspi3>;    pinctrl-1 = <&pinctrl_lpspi3>;    cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;    status = "okay";        ethernet: w5500@0 {        compatible = "wiznet,w5500";        reg =;        status = "okay";        pinctrl-names = "default";        pinctrl-0 = <&pinctrl_w5500>;        interrupt-parent = <&gpio2>;        interrupts =;        spi-max-frequency =;    };
};

Multiplexed SPI

 pinctrl_lpspi3: lpspi3grp {        fsl,pins = < MX93_PAD_GPIO_IO08__GPIO2_IO08 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe >;    };    pinctrl_w5500: w5500grp {        fsl,pins = < MX93_PAD_GPIO_IO04__GPIO2_IO04 0x31e //int MX93_PAD_GPIO_IO05__GPIO2_IO05 0x31e //rst >;    };

Since the W5500 driver uses software reset by default, it’s only necessary to ensure that the reset pin is in a pull-up state.

3. Compilation&Porting

Compile the device tree and drivers, including w5100.ko and w5100-SPI. Ko for W5500.

$ root@DESKTOP-GJ47EH8:/home/OKMX93-linux-sdk# ./build.sh kernel

After compiling, replace the device tree on the development board and place the driver in the directory where the system can find it.

$ root@ok-mx93:~# cp /run/media/boot-mmcblk1p1/OK-MX93-C.dtb /run/media/Boot-mmcblk0p1/
$ root@ok-mx93:~# cp /run/media/boot-mmcblk1p1/w5100.ko ./
$ root@ok-mx93:~# cp /run/media/boot-mmcblk1p1/w5100-spi.ko ./

4. Driver Loading

Execute the load driver command on the development board

root@ok-mx93:~# insmod w5100.ko
root@ok-mx93:~# insmod w5100-spi.ko

The new eth2 network card can be seen through the ifconfig -a command, and the network card can be up normally.

root@ok-mx93:~# ifconfig -a
...
eth2: flags=-28605  mtu 1500        inet 169.254.218.84  netmask 255.255.0.0  broadcast 169.254.255.255        inet6 fe80::c4c5:86ff:fe12:9f9d  prefixlen 64  scopeid 0x20ether c6:c5:86:12:9f:9d  txqueuelen 1000  (Ethernet)        RX packets 2115  bytes 340022 (332.0 KiB)        RX errors 0  dropped 133  overruns 0  frame 0        TX packets 56  bytes 13927 (13.6 KiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...
root@ok-mx93:~# ifconfig eth2 up
root@ok-mx93:~# ifconfig
...
eth2: flags=-28605  mtu 1500        inet 169.254.218.84  netmask 255.255.0.0  broadcast 169.254.255.255        inet6 fe80::c4c5:86ff:fe12:9f9d  prefixlen 64  scopeid 0x20ether c6:c5:86:12:9f:9d  txqueuelen 1000  (Ethernet)        RX packets 2430  bytes 398823 (389.4 KiB)        RX errors 0  dropped 158  overruns 0  frame 0        TX packets 56  bytes 13927 (13.6 KiB)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...

5. Network Test

After the driver is loaded, IP can be set normally and the external network can be pinged.

root@ok-mx93:~# ifconfig eth2 172.20.2.167
root@ok-mx93:~# ifconfig
...
eth2: flags=-28605 mtu 1500 inet 172.20.2.167...

Achieving Fast Startup in the Industrial Automation Field with the Falcon Mode of Forlinx Embedded FET-MX9352-C Platform

Fast startup is a key device performance indicator in today's rapidly evolving embedded systems. With the popularization of IoT, industrial control and in-vehicle electronics, higher requirements are placed on device response speed and startup time. Fast startup can not only enhance the user experience but also respond quickly in emergency situations, ensuring the stability and safety of the system. This article will introduce how to achieve fast startup to the interface after the system is powered on based on Forlinx Embedded's FET-MX9352-C platform.

Two Boot Modes of Bootloader

Bootloader is the first piece of software code to run after the system is powered on. It is responsible for loading the kernel image and detecting hardware and allocating resources. The Bootloader provides two boot modes: the default mode and the Falcon mode.

Default Boot Mode:

Boot Sequence: After the development board is powered on or reset, the BootROM (main program loader) stored in the CPU ROM is first executed.

Peripheral Initialization: The BootROM is responsible for basic peripheral initialization, such as phase-locked loop (PLL), clock configuration, memory initialization (SRAM), etc., to configure the system-on-chip (SoC).

Component Loading: After loading, the BootROM will find a boot device and load the bootloader image from this device. This image usually includes components such as U-Boot SPL, ATF, and U-Boot.

U-Boot SPL: As the first stage of the bootloader, SPL is the minimum code set suitable for SRAM. It is responsible for initializing hardware, such as the clock and memory controller, and configuring and initializing DRAM.

ATF and U-Boot: Subsequently, SPL loads ATF and U-Boot correctly into DRAM. ATF provides a reference trusted code library for the Armv8 architecture and implements a variety of ARM interface standards. U-Boot is the second-stage bootloader, which is responsible for loading and starting the kernel image and providing a command-line interface for interacting with the hardware.

Falcon Boot Mode

Feature: The Falcon mode is a feature in U-Boot that allows SPL to directly start the Linux kernel, thus skipping the loading and initialization process of U-Boot and achieving fast startup.

Advantage: By reducing the time spent in the bootloader, the Falcon mode significantly shortens the system startup time and improves the device's response speed.

Execution Process of Falcon Mode

The execution process of the Falcon mode is relatively simple and efficient, mainly including the following steps:

SPL Initialization: After the system is powered on or reset, the BootROM stored in the CPU ROM is first executed, and then SPL is loaded and run.

Hardware Initialization: SPL is responsible for initializing necessary hardware devices, such as the clock and memory controller, and configuring and initializing DRAM.

Kernel Loading and Startup: In the Falcon mode, SPL directly loads the Linux kernel into DRAM and jumps to the kernel entry address for execution. This process completely skips the loading and initialization steps of U-Boot.

System Startup: After the Linux kernel runs successfully, it takes over system control and completes the subsequent startup process.

Implementation of Falcon Mode

1.Reduce Bootloader Startup Time

The solution provided by NXP is implemented based on the Yocto BSP version 6.6.36, and the modified patches can be downloaded separately.

git clone https://github.com/nxp-imx-support/meta-imx-fastboot.git

u-boot patch

recipes-bsp/u-boot/files/0001-Enable-Fast-Boot-on-i.MX-8M-Family-and-i.MX-93.patch.

The main purpose of this patch is to add the logic of choosing to start UBOOT or the kernel during the SPL execution process. If any key is pressed during the boot process, it can prevent the automatic startup of the kernel, giving users the opportunity to enter the U-Boot command-line interface. If there is no key input, the system will continue the...

OpenCV Porting on T507 Platform with Linux 4.19: A Deep Comparison Between Standalone Compilation and Buildroot Compilation

OpenCV is an open-source computer vision library that provides a rich set of image processing and computer vision algorithms, supporting multi-platform development. It can be used for various computer vision tasks such as image and video processing, feature extraction, object detection, image segmentation, pose estimation, and object recognition. There are two methods for porting OpenCV: standalone compilation and Buildroot compilation.

Standalone Compilation of OpenCV

Standalone compilation requires CMake, a cross-platform build system similar to the commonly used ./configure. Once configured, it generates a CMakeLists.txt file that defines the project's build rules.

1. Install CMake

2. Configuration

First, extract opencv-2.4.13.7.tar.gz, enter its directory, and run cmake-gui to open the configuration interface.

(1)Set the source code path and build output path (the output path must be created in advance);

(2)Click Configure and select Unix platform cross-compilation mode;

(3)Configure compiler settings.

(4)Configure compiler settings after configuration.

Enable TIFF support.

Disable CUDA (Compiling with CUDA fails; CUDA is for NVIDIA GPUs, which are not available on T507, so disabling it has no impact).

Select Grouped to configure the installation path in cmake.

Cancel GTK

Reconfigure and generate the build files.

3. Compilation

Before compiling, modify the CMakeLists.txt file to configure linker rules:

The goal is to configure the rules for the connector,

-lpthread: Links the libpthread.so library, which provides multithreading support

-lrt: links the librt.so library, which provides real-time extension-related functions

-lrt: links the librt.so library, which provides real-time extension-related functions

make compilation

4. Installation and Deployment

The installation path needs to be cleared before installation.

make install.

Generated test program.

Generated library.

There is also a part of the build path.

Package the above content and release it to the file system of the board.

5. Test

The program can be called to the library to run normally.

However, there are still some errors in the application processing.

Build root compile opencv

1. Enter the Graphical Interface

2. Select Compilation Parameters

Select opencv3 in the following path

Tick all the parameter items.

3. Save the .config file.

Go to the output path of the source package/OKT507-linux-sdk/out/t507/okt507/longan/buildroot，

Change the existing target file to any name and create a new target file

4. Standalone Compilation

Networking is required for the compilation process

Buildroot outputs the standalone compiled content to the previously created **target** directory. The contents can then be packaged and deployed to the **filesystem**.

5. Test

ZD-Atom provides an OpenCV Qt test program based on **i.MX6UL**, where the **.pro** file defines the application's dependencies.

These libraries are available in the files generated by the compilation.

Both methods have their pros and cons:

Standalone Compilation: Allows trying different source versions and offers more flexible parameter configuration, but the process is complex.

Buildroot Compilation: Enables easy deployment by simply extracting the generated files, but switching versions is inconvenient.