Forlinx

Cross-compilation Toolchain Location: OK113i-linux-sdk/out/t113_i/ ok113i/longan/buildroot/host/bin/arm-linux-gnueabihf-gcc‍ Before executing the method below, please delete the out directory and decompress the cross-compilation tool chain in the lower path of the source code./buildroot/buildroot-201902/dl/toolchain-external-linaro-arm/gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz 1. Modify mkcmd.sh and mkcommon.sh according to the patch modification method in the figure. 2. Go back to the sdk path and execute the following command: forlinx@ubuntu:~/shuishui/OK113i-linux-sdk$ ./build.sh config It is modified to emmc or NAND version according to the actual board configuration. 3. Next, execute the following command to enter the configuration of buildroot. Enter toolchain Modify the relevant options as shown in the figure below: Enter target options Because hard-float is needed, the highlighted part in the diagram needs to be modified to EABIhf. Save and exit after setting. Enter the following path to compile. ./build.sh Full compilation may require an error with an environment variable, resulting in a failure to compile. If this problem occurs, execute the following instructions and compile the buildroot. export LD_LIBRARY_PATH="" In the middle of compiling buildroot, you may encounter an error as shown in the following figure. If these errors are encountered, you can find the corresponding source code and compile it through the tools in the decompressed cross-compilation chain. Subsequently, place the compiled executable file in the bin path and the library file in the lib path. Finally, continue executing ./build.sh until compilation is successful. After compiling successfully, return to the SDK path, perform full compilation build. sh, and then pack the image. Next, write a test program to verify whether the cross-compilation chain can be successfully replaced. Here, you need to compare the program compiled with the original compilation chain with the program cross-compiled with the current compilation chain. The part highlighted in the diagram is a program compiled using our original cross-compilation chain. It can be observed that it does not run normally. "Test" is a program compiled using the tools from the replaced cross-compilation chain, which runs normally. Additionally, the relevant information of the two programs can be determined using the ''strings'' tool.

Routing is a core component of device networking, responsible for intelligent data packet forwarding, ensuring efficient communication and internet access. It also assigns IP addresses to devices connected via the network interface, ensuring stable and secure connections. Below is a guide on how to implement routing functionality on the Forlinx i.MX93 platform. 1. Bridge Building 1.1 Busybox Compilation and Brctl Tool Loading There is no brctl tool in the busybox of the 93 development board, so it needs to be recompiled. If the busybox of the board has the brctl tool, this step can be ignored. Down load busybox-1.35 source code, website： https://busybox.net/ Unzip it on the 93 development environment and execute make menuconfig to configure. forlinx@ubuntu:~/work/busybox$ tar -xvf busybox-1.35.0.tar.bz2 forlinx@ubuntu:~/work/busybox$ cd busybox-1.35.0/ forlinx@ubuntu:~/work/busybox/busybox-1.35.0$ . /opt/fsl-imx-xwayland/5.15-kirkstone/environment-setup-armv8a-poky-linux forlinx@ubuntu:~/work/busybox/busybox-1.35.0$ make menuconfig Select Setting-->[*] Don't use /usr Add cross-compilation path (it can be set according to your own requirements): Setting-->--- Build Options (arch64-poky-linux-) Cross compiler prefix (/opt/fsl-imx-xwayland/5.15-kirkstone/sysroots/armv8a-poky-linux) Path to sysroot (-O2 -pipe -g -feliminate-unused-debug-types) Additional CFLAGS (-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,relro,-z,now) Additional LDFLAGS Select brctl tool Networking Utilities --->[*] brctl (4.7 kb) Modify and then compile forlinx@ubuntu:~/work/busybox/busybox-1.35.0$ make forlinx@ubuntu:~/work/busybox/busybox-1.35.0$ make install Copy the generated busybox command to the development board/home/root path 1.2 Kernel Source Code Modification forlinx@ubuntu:~/work/ok-mx93/OKMX93-linux-sdk/OKMX93-linux-kernel$ vi drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c (478 line) /* if (hw->promisc) { netdev_err(dev, “Adding VLAN in promisc mode not supported\n"); return -EPERM; }*/ （533 line） /* if (hw->promisc) { netdev_err(dev, "Deleting VLAN in promisc mode not supported\n"); return -EPERM; }*/ Save and recompile the kernel after modification, generate Image and update the kernel 1.3 Building a Bridge With Brctl root@ok-mx93:~# ./busybox brctl addbr br0 //Create bridge device br0 root@ok-mx93:~# ./busybox brctl stp br0 off //Turn off the STP root@ok-mx93:~# ./busybox brctl addif br0 eth0 //Add eth0 to the bridge root@ok-mx93:~# ./busybox brctl addif br0 eth1 //Add eth1 to the bridge root@ok-mx93:~# ifconfig br0 192.168.0.10 up configure br0 ip and start it 2. 4G for Network Forwarding 2.1 4G Dial-up If there is command service, you need to delete it and restart. root@ok-mx93:~# rm /usr/sbin/connmand root@ok-mx93:~# sync root@ok-mx93:~# reboot root@ok-mx93:~# fltest_quectel.sh root@ok-mx93:~# ifconfig eth0 up root@ok-mx93:~# ifconfig eth1 up Note: The network port will be closed in the 93 dial-up script. If it is not necessary, you can comment out the command to close the network port in the script. 2.2 Route Priority Adjustment Checking with ''route -n'' reveals that the priorities of eth0 and eth1 are higher than 4G. At this point, 4G cannot access the Internet, so it is necessary to adjust the priorities to avoid affecting the 4G network. root@ok-mx93:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth1 0.0.0.0 10.137.251.242 0.0.0.0 UG 10 0 0 usb0 10.137.251.240 0.0.0.0 255.255.255.252 U 0 0 0 usb0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 Modify the metric parameter to change the priority. root@ok-mx93:~# route del default gw 192.168.1.1 root@ok-mx93:~# route del default gw 192.168.2.1 root@ok-mx93:~# route add default gw 192.168.1.1 dev eth0 metric 11 root@ok-mx93:~# route add default gw 192.168.2.1 dev eth1 metric 11 root@ok-mx93:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.137.251.242 0.0.0.0 UG 10 0 0 usb0 0.0.0.0 192.168.2.1 0.0.0.0 UG 11 0 0 eth1 0.0.0.0 192.168.1.1 0.0.0.0 UG 11 0 0 eth0 10.137.251.240 0.0.0.0 255.255.255.252 U 0 0 0 usb0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 After modification, 4G can access the Internet normally. root@ok-mx93:~# ping www.baidu.com PING www.a.shifen.com (39.156.66.18) 56(84) bytes of data. 64 bytes from 39.156.66.18 (39.156.66.18): icmp_seq=1 ttl=51 time=32.7 ms 64 bytes from 39.156.66.18 (39.156.66.18): icmp_seq=2 ttl=51 time=31.4 ms 64 bytes from 39.156.66.18 (39.156.66.18): icmp_seq=3 ttl=51 time=29.3 ms 64 bytes from 39.156.66.18 (39.156.66.18): icmp_seq=4 ttl=51 time=29.1 ms ^C --- www.a.shifen.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 29.066/30.612/32.663/1.494 ms 2.3 4G Forwarding Turn on IP to forward. root@ok-mx93:~# echo 1 > /proc/sys/net/ipv4/ip_forward Set forwarding rules. root@ok-mx93:~# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o usb0 -jMASQUERADE root@ok-mx93:~# iptables -A FORWARD -i br0 -j ACCEPT Configure the udhcpd service and modify the/etc/udhcpd. conf films. root@ok-mx93:~# vi /etc/udhcpd.conf ... # The start and end of the IP lease block start 192.168.0.100 end 192.168.0.254 # The interface that udhcpd will use interface br0 ... # Examples: opt dns 114.114.114.114 option subnet 255.255.255.0 opt router 192.168.0.10 Turn on the udhcpd service root@ok-mx93:~# udhcpd /etc/udhcpd.conf & 3. Computer and Device Side Set both the computer and the device to obtain IP automatically. After obtaining the IP, the two can access the external network and ping each other.

The touchscreen driver usually employs the input subsystem driver framework, so the application layer interface must adhere to the interfaces of the input framework. By entering ls -l /dev/input in the command line, you can see the current input devices available. root@freescale ~$ ls -l /dev/input/ total 0 crw - r----- 1 root root 13, 64 Jan 1 00:17 event0 crw - r----- 1 root root 13, 65 Jan 1 00:17 event1 crw - r----- 1 root root 13, 66 Jan 1 00:17 event2 crw - r----- 1 root root 13, 63 Jan 1 00:17 mice Lrwxrwxrwx 1 root root 6 Jan 1 00:18 ts0 -> event2 Lrwxrwxrwx 1 root root 6 Jan 1 00:18 ts2 -> event1 root@freescale ~$ View Touch Original Data When there is an issue with the touch function, you can determine whether the problem lies in the driver layer or the application layer by checking the raw data. There are several methods to view the raw data: 1. cat /dev/event2 Directly using cat on the touch event will output garbled characters when you touch the screen. 2. hexdump $ hexdump -d /dev/input/event0 0000000 15989 00000 18969 00004 00004 00004 00001 00009 # Other events 0000010 15989 00000 18969 00004 00001 00272 00001 00000 # BTN_MOUSE，press 0000020 15989 00000 18969 00004 00003 00000 16333 00000 # ABS_X 0000030 15989 00000 18969 00004 00003 00001 09599 00000 # ABS_Y 0000040 15989 00000 18969 00004 00000 00000 00000 00000 # Synchronous events 0000050 15989 00000 49415 00005 00004 00004 00001 00009 # Other events 0000060 15989 00000 49415 00005 00001 00272 00000 00000 # BTN_MOUSE，release 0000070 15989 00000 49415 00005 00000 00000 00000 00000 # Synchronous events The fourth, third, and second-to-last lines correspond to type, code, and value, which are all defined in linux/input.h. The event types for input devices in Linux are: #define EV_SYN 0x00 // Synchronous events #define EV_KEY 0x01 // Key events #define EV_REL 0x02 // Relative coordinates #define EV_REL 0x03 // Absolute coordinates #define EV_MSC 0x04 // Other events Type is the event type, where 3 is the EV _ ABS = 0x03 and 0 is the EV _ SYN = 0x00 (as a separator of events). The value of code depends on the event type. If the type is EV _ ABS, the value of code 0 is ABS _ X and the value of code 1 is ABS _ Y. Then, the value represents the measurement under the premises of type and code. For example, if the type is EV_ABS and the code is 0 (which corresponds to ABS_X), then the value represents the absolute X-axis position of the touch point. For example, if the type is EV_KEY, the code 272 corresponds to BTN_MOUSE, and code 330 corresponds to BTN_TOUCH; a value of 1 indicates a press, while a value of 0 indicates a release. For instance, if the type is EV_ABS and the code is 24 (which corresponds to ABS_PRESSURE), a value of 1 indicates that the screen is being pressed, while a value of 0 indicates it is released. The tests show that the coordinate values generated by the touchscreen touch events have a range of X: 016384 and Y: 09600, and this touchscreen does not upload ABS_PRESSURE. 3. ts_print / ts_print_raw The difference between the two is that ts _ print prints the data after tslib processing, while ts _ print _ raw prints the data before tslib processing. 4. evtest Evtest can not only print original, but it also allows you to see the event types. Driving Layer Processing Idea 1. Find the corresponding driver in the kernel source code by checking the device information. You can look for the corresponding string in the kernel source code; 2. To locate the touch reporting position, you can search for the string ABS in the corresponding driver. The image above shows the touch driver for a resistive screen. 3. Add print statements for further processing. Application Layer Processing 1. Use tools like ts_test to check if tslib is receiving data. 2. Change the version of tslib. Capacitive Screen In theory, capacitive screens do not require touch calibration; however, if they are not calibrated, there may be instances where the touch effects are opposite to the actual response, requiring the touch input to be inverted. However, if the reported data on the screen does not match the actual resolution, lower versions of Qt may not be able to handle it, necessitating manual calibration.

Configuring a Bridge for LAN Ports 1. Create/etc/systemd/network/br0.netdev 2. Create/etc/systemd/network/br0.network 3. Create the Port Configuration Files: Enter the following content, taking fm1-mac2.network as an example: Name=fm1-mac2 The attribute differs, must correspond to the filename. Enable 5G Dial-Up on Boot 1. Add 5G Autostart: At the end of the /root/.forlinx file, add the following content: Possible Reasons for Dial-Up Failure: SIM card inserted incorrectly, SIM card is out of credit. IoT card is locked, need to add APN (cmnet: Mobile; 3gnet: Unicom; ctnet: Telecom). The board has a 4/5G switching dial switch. Install and Configure udhcpd Service 1. Install udhcpd Service: Other Solutions for Source Update Failure: (1) https://blog.csdn.net/Chaowanq/article/details/121559709 apt command certificate error. (2) https://blog.csdn.net/zhushixia1989/article/details/104550890 GLib-CRITICAL **: g_strchomp: assertion ‘string != NULL’ failed (3) https://blog.csdn.net/downanddusk/article/details/126334776 kali-rolling InRelease‘ is not signed 2. Configure udhcpd Service: Open /etc/udhcpd.conf and modify the /etc/udhcpd.conf configuration file to customize the IP pool, gateway, DNS, interface, etc. Here, I allocate IP range 192.168.3.20 — 192.168.3.254, interface as br0. Modify /etc/default/udhcpd to enable it. DHCPD_ENABLED=“yes”. After configuration, start the service: systemctl start udhcpd.service. Restart the service: systemctl restart udhcpd.service. Enable the service at boot: systemctl enable udhcpd.service. Check the service status: systemctl status udhcpd.service. Set Network Node usb0 Forwarding Rules 1. Set Forwarding Rules: 2. Save Forwarding Rules: -t nat: Specifies the table to operate on as the nat table. The nat table is used for network address convert. -A POSTROUTING: -A indicates that a rule is being appended to the end of the chain, and in this case, the chain being appended is the POSTROUTING chain. Rules in the POSTROUTING chain are handled when a packet is about to leave a network interface. -o usb0: The -o option specifies which network interface the packets will be sent out from. In this example, usb0 is the designated network interface (usually a USB network adapter). -j MASQUERADE: The -j jump to target action, here is MASQUERADE, which means enabling IP masquerading, replacing the source address with the IP address of the interface sending the packets, useful especially for dynamically assigned IP addresses.

Compile the driver to the kernel： Create the hello folder for the kernel driver source code, add the hello. c and Makefile file, modify the parent directory/kernel/drivers/Makefile file, and execute the full compilation operation. Modify as follows: /hello/Makefile is：obj-y += hello.o /kernel/drivers/Makefile; add the following code：obj-y += hello Compile the driver as a module： Method 1： Create the hello folder for the kernel driver source code, add the hello. c and Makefile file, modify the parent directory/kernel/drivers/Makefile file, and execute the full compilation operation. Modify as follows: /hello/Makefile is：obj-m += hello.o /kernel/drivers/Makefile; add the following code：obj-y += hello If wanting to compile the driver but not wanting to perform a full compile operation that takes too much time, the following method can be chosen. Method 2： Create a hello folder in the kernel driver source code, add the hello. c and Makefile file, modify the parent directory/kernel/drivers/Makefile file, modify the/kernel/Makefile file to add the architecture and cross-compiler, and execute the make modules command. Modify as follows: /hello/Makefile is：obj-m += hello.o /kernel/drivers/Makefile; add the following code：obj-y += hello /kernel/Makefile, add the following code: ARCH?= arm64 CROSS_COMPILE?= $(srctree)/../prebuilts/gcc/linux-x86/aarch64/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- Advantages: When executing the make modules command, only the modules will be compiled, and the compilation time will be shortened. Disadvantages: The driver source code needs to be added to the kernel, which is not easy to find and modify. In addition, the make modules command will determine that the source code is configured as a module and will be compiled. Issues encountered: Solution: The kernel top-level Makefile file specifies the architecture and cross-compiler. Method 3： Create a folder named "hello" at any path, and add the files ''hello.c'' and ''Makefile''. In the ''/hello/Makefile'', add the architecture and cross-compiler. Then, execute the ''make'' command in the directory where ''hello.c'' is located. /hello/Makefile to write the following code. Advantages: Execute the make command, and only hello. C driver files will be compiled separately. Issues encountered: Solution: The kernel top-level Makefile file specifies the architecture and cross-compiler. Appendix: hello.c #include #include MODULE_LICENSE("Dual BSD/GPL"); static int hello_init(void) { printk(KERN_ALERT "Hello World enter\n"); return 0; } static void hello_exit(void) { printk(KERN_ALERT "Hello World exit\n"); } module_init(hello_init); module_exit(hello_exit); MODULE_DESCRIPTION("A Sample Hello World Module"); MODULE_ALIAS("A Sample module");

System sleep and wake technology is a crucial aspect of power management. Firstly, it allows the system to reduce power consumption to the lowest level when idle by putting external devices, internal IP of the chip, and clocks into a low-power state or completely shut off the power state, thereby greatly extending the product's runtime. Secondly, when users need the system to run, it can quickly recover power, clocks, internal IP of the chip, and the working state of external devices to ensure that the user's experience is not interrupted. Forlinx T113 supports two types of sleep modes: freeze and mem. These two methods can be operated through the/sys/power/state file node, and the user can trigger the corresponding sleep state by writing freeze or mem to the file node. Before hibernation, the system configures the wakeup source. Once the system enters the sleep state, it can be awakened by these wake-up sources, such as keys, RTC, etc., when needed. This design allows users to choose when and how to wake up the system quickly according to their needs, achieving a balance between power consumption minimization and fast recovery. This mechanism enables the system to greatly reduce power consumption in the sleep state, while retaining the convenience of the user to use the system quickly after waking up. Here's how to enter sleep mode and wake up the system using the RTC on the Forlinx Embedded OK113i-S development board. Two Sleep Modes: freeze: Freezes I/O devices, placing them into a low-power state, and puts the processor into an idle state. It offers the quickest wake-up time, but consumes more power than other methods. Measured current with only serial port connected and 5V power supply: Approximately 0.112A mem: Suspend-to-RAM, where the computer stores current runtime state data in memory and shuts down the hard drive, external devices, etc., entering a wait state. At this time, the memory still needs power to maintain its data, but the whole machine consumes very little power. When recovering, the computer reads data from memory, returns to the state before suspension, and recovers quickly. Measured current with only serial port connected and 5V power supply: approximately 0.076A 1. cat /sys/power/state shows the supported modes. 2. cat /sys/power/state shows the supported modes. 3. cat /sys/power/state shows the supported modes. RTC Alarm Wakeup Tips: Note that the internal RTC needs to be used here; external RTCs do not support wakeup functionality, and we will mention this later. Enter the kernel configuration: Follow the instructions in the diagram to select the wake-up function. After completing the configuration, save it, then modify the device tree file to enable the internal RTC. Compile after saving: After the compilation is successful, it is packaged into an image. After the programming is completed, we test it at the serial port terminal. Enter the serial port terminal for test: echo''+15''> /sys/class/rtc/rtc0/wakealarm This sets a 15-second timer, which can be adjusted as needed. After executing this command, it will take effect. If the system goes into sleep after 15 seconds, it will not trigger a wake-up. (Note: This requires using the internal RTC; external RTC does not support wake-up functionality.)echo mem > /sys/power/state (The two commands need to be entered closely together; a long interval between them will make them ineffective.) (It should be noted here that when the internal RTC is not opened, the default external RTC node is rtc0. After modification, the external RTC device node will be changed to rtc1.) 3. cat /sys/power/state shows the supported modes. RTC Alarm Wakeup Tips: Note that the internal RTC needs to be used here; external RTCs do not support wakeup functionality, and it will be mentioned later. Enter the kernel configuration: Follow the instructions in the diagram to select the wake-up function. After completing the configuration, save it, then modify the device tree file to enable the internal RTC. Compile after saving: After the compilation is successful, it is packaged into an image. After the programming is completed, we test it at the serial port terminal. Enter the serial port terminal for test: echo''+15''> /sys/class/rtc/rtc0/wakealarm This sets a 15-second timer, which can be adjusted as needed. After executing this command, it will take effect. If the system goes into sleep after 15 seconds, it will not trigger a wake-up. (Note: This requires using the internal RTC; external RTC does not support wake-up functionality.) echo mem > /sys/power/state (The two commands need to be entered closely together; a long interval between them will make them ineffective.) It should be noted here that when the internal RTC is not opened, the default external RTC node is rtc0. After modification, the external RTC device node will be changed to rtc1.

This project is based on the Forlinx Embedded OKMX8MP-C development board, which has a virtual machine ported. It is necessary to install the required packages on the development board and ensure that the board is connected to the network. 01 Logging into the OKMX8MP-C Development Board Connect the Type-C cable to the Debug port and select eMMC as the boot mode (i.e., set mode selection switch 2 to “on” and all others to “off”). After booting, log in using the root account. 02 Modifying the pip Source To speed up the installation process, it is necessary to modify the pip source: Add the followings: 03 Installing the Python venv Environment First, install the python3-venv package: apt install python3-venv Once installed successfully, create a directory named yolo (or any name of choice) and enter this directory to set up the Python 3 environment: Create the yolo directory (the directory name can be taken by yourself), and enter the directory to install the python3 environment: Execute the following figure: Activate the Python 3 venv environment: If activation is successful, it will display the following: 04 Installing Ultralytics Ultralytics YOLOv8 is based on cutting-edge deep learning and computer vision technologies, offering unparalleled performance in speed and accuracy. Its streamlined design makes it suitable for various applications and easily adaptable to different hardware platforms, from edge devices to cloud API. To install it, use the following command: Be patient while the installation completes: Once the installation is successful: 05 Testing the Installation Use the following command to test the setup. The image link in source can be replaced with another link: During this process, the model and image will be downloaded, so patience is required. After successful execution, the results will be generated in the runs/detect/predict* directory. The results can be copied to a Windows computer using the scp command. In the cmd terminal, execute the following command: If the output can be recognized, it indicates that the YOLO environment is functioning correctly. It is the process of setting up the YOLO environment on the Forlinx Embedded OKMX8MP-C development board. Hope it is useful.

MIPI-CSI is a common camera interface in embedded systems or mobile devices, enabling high-speed image data transfer. The latest OK3576-C development board from Forlinx Embedded offers a wealth of resource interfaces, including support for 5 x CSI-2 , meaning it can support up to five camera inputs simultaneously. This article introduces the Camera path of RK3576 processor and how to configure different output formats of MIPI-CSI camera through OK3576-C development board. 01. RK3576 Camera Channels If there is only one camera access, turn on only rkispx_vir0 . Please note: vicap and isp do not have a direct correspondence; The relationships between different vir0/vir1 channels are essentially the same hardware being multiplexed, with the same effect. When using multiple cameras, configure them using 0, 1, 2, etc., as much as possible. The hardware channel diagram is as follows: There is one dcphy interface and two dphy interfaces. The connection paths are as follows: Single Camera (connected to one dphy): Dual Cameras (connected to two dphys) Three Cameras (connected to dcphy and two dphys) Five Cameras (connected to dcphy and two split dphys) Camera Channel Connection Diagram: (Note: For RGB data input, it is also necessary to connect to rkisp_virx) 02. Sensor Link Scenarios for Different Platforms yuv422/rgb888 input There are three common scenarios for yuv422/rgb888 input: Cameras with Built-in isp or External isp. Enter yuv422 format; HDMI to MIPI CSI Input. Common chips like rk628d/f,lt6911xxx, etc., typically convert yuv422, but rgb888 format is also possible; Multiple ahd and serdes. A single mipi port can support up to four virtual channels. For these scenarios, an isp is not required, and the connection only needs to go to cif. Thus, the link is: The isp node can be disabled. The X varies depending on the platform and hardware connections. The node used for capturing images is the first video node corresponding to rkcif_mipi_lvdsX. This can be viewed using media-ctl to check the topology. For example, on the OK3576-C development board with an OV5645 camera, it is mounted on the media1 node. root@ok3576-buildroot:/# media-ctl -p -d /dev/media1 Media controller API version 6.1.57 driver rkcif model rkcif-mipi-lvds1 serial bus info platform:rkcif-mipi-lvds1 hw revision 0x0 driver version 6.1.57 Device topology - entity 1: stream_cif_mipi_id0 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video11 pad0: Sink <- "rockchip-mipi-csi2":1 [ENABLED] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 5: stream_cif_mipi_id1 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video12 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [ENABLED] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 9: stream_cif_mipi_id2 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video13 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [ENABLED] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 13: stream_cif_mipi_id3 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video14 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [ENABLED] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 17: rkcif_scale_ch0 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video15 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [ENABLED] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 21: rkcif_scale_ch1 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video16 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [ENABLED] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 25: rkcif_scale_ch2 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video17 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [ENABLED] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 29: rkcif_scale_ch3 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video18 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [ENABLED] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 33: rkcif_tools_id0 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video19 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [ENABLED] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [] - entity 37: rkcif_tools_id1 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video20 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [ENABLED] <- "rockchip-mipi-csi2":11 [] - entity 41: rkcif_tools_id2 (1 pad, 11 links) type Node subtype V4L flags 0 device node name /dev/video21 pad0: Sink <- "rockchip-mipi-csi2":1 [] <- "rockchip-mipi-csi2":2 [] <- "rockchip-mipi-csi2":3 [] <- "rockchip-mipi-csi2":4 [] <- "rockchip-mipi-csi2":5 [] <- "rockchip-mipi-csi2":6 [] <- "rockchip-mipi-csi2":7 [] <- "rockchip-mipi-csi2":8 [] <- "rockchip-mipi-csi2":9 [] <- "rockchip-mipi-csi2":10 [] <- "rockchip-mipi-csi2":11 [ENABLED] - entity 45: rockchip-mipi-csi2 (12 pads, 122 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Sink [fmt:UYVY8_2X8/1920x1080 field:none colorspace:srgb crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] <- "rockchip-csi2-dphy0":1 [ENABLED] pad1: Source -> "stream_cif_mipi_id0":0 [ENABLED] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad2: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [ENABLED] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad3: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [ENABLED] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad4: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [ENABLED] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad5: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [ENABLED] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad6: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [ENABLED] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad7: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [ENABLED] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad8: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [ENABLED] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad9: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [ENABLED] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [] pad10: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [ENABLED] -> "rkcif_tools_id2":0 [] pad11: Source -> "stream_cif_mipi_id0":0 [] -> "stream_cif_mipi_id1":0 [] -> "stream_cif_mipi_id2":0 [] -> "stream_cif_mipi_id3":0 [] -> "rkcif_scale_ch0":0 [] -> "rkcif_scale_ch1":0 [] -> "rkcif_scale_ch2":0 [] -> "rkcif_scale_ch3":0 [] -> "rkcif_tools_id0":0 [] -> "rkcif_tools_id1":0 [] -> "rkcif_tools_id2":0 [ENABLED] - entity 58: rockchip-csi2-dphy0 (2 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY8_2X8/1920x1080@10000/300000 field:none colorspace:srgb crop:(0,0)/1920x1080] <- "m01_f_ov5645 3-003c":0 [ENABLED] pad1: Source -> "rockchip-mipi-csi2":0 [ENABLED] - entity 63: m01_f_ov5645 3-003c (1 pad, 1 link) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: Source [fmt:UYVY8_2X8/1920x1080@10000/300000 field:none colorspace:srgb crop:(0,0)/1920x1080] -> "rockchip-csi2-dphy0":0 [ENABLED] If it is a multi-channel input, it corresponds to the first four, that is, video11-video14. RAW format input Starting from RK3588, that is, from isp3.0, the isp of Rockchip microprocessor no longer has the acquisition function, but only does image processing, so the whole path is: It needs to be explained here: Without running aiq (Automatic Image Quality), rkcif_mipi_lvdsX can directly capture RAW images; If only the isp node vir0, i.e., rkispx_vir0, is enabled and the subsequent nodes rkispx_vir1/vir2, etc., are not enabled, this is a direct pass-through configuration. Even without running aiq, nv12 images can still be obtained, but these images are unprocessed and generally appear in a light green color; Enabling other vir nodes indicates that the isp needs to be time-multiplexed, which requires aiq to be enabled in order to capture images (aiq will handle time-multiplexing of the isp). Therefore, if only one camera is used, it is advisable to disable other isp nodes. 03. Summary When configuring the camera, first determine the camera’s channel path and the format of the camera output. If it is RAW data, it must go through rkisp. If it is yuv422/rgb888, it only needs to be configured to rkcif_mipi_lvdsx. This article introduced the camera channels of the RK3576 processor and explained how to configure different output formats for MIPI-CSI cameras. Future articles will continue to cover camera parameter configuration and device tree setup for the RK3576 processor.

1. OTG Driver Installation Tool: OK3568-C ForlinxDesktop User Profile\ForlinxDesktop\Tool\DriverAssitant_v5.11.zip Extract the above path file to any directory and run it with administrator privileges Open DriverInstall.exe Click "Driver Installation" 2. OTG Full Flashing Test Path: OK3568-C ForlinxDesktop User Profile\ForlinxDesktop\Tool\RKDevTool_Release.zip It is a development tool provided by Rockchip, before using it, unzip it to a full English path, connect the development board and the host computer with a Type-C cable, press and hold the recovery key of the development board and don't release it, then press the reset key to reset the system, about two seconds after releasing the recovery key. There will be prompts on the Rockchip development tool : loader device found Note: The condition for recognition is that the development board is powered up and the recover key is in the pressed state. Theoretically, Rockchip development tools have no requirements for the unzip directory. However, some users have feedback that the unzip directory should be in full English. If the tool doesn't match the following figure, please consider unzipping it in an English directory. Note: Pay attention to two points during OTG programming: 1. Link the OTG line. 2. If OTG is multiplexed with the USB 3.0, it is necessary to modify the dial switch, as shown in the following figure: Open the RKDevTool Click the "Upgrade Firmware" tab, click the "Firmware" button to select the full upgrade image update.img. If the key operation fails, the board will start normally, and the tool interface displays Found One ADB Device. In this case, you can click the “switch” button of the tool to enter loader mode. 3. OTG Step Programming Test In the development phase, it is very time-consuming to flash all of them every time, so here is the method of using OTG flashing tool to flash in separate partitions. Note: The condition for recognition is that the development board is powered up and the recover key is in the pressed state. First, after OK3568-Forlinx Desktop-release is compiled, a separate partition image can be found in the rockdev directory Take separate programming boot.img (including device tree and startup logo) as an example to demonstrate the programming method. Use the Type-C cable to connect the development board to the host. Press and hold the recover key and do not release it. Then press the reset key to reset the system. Release the recover key after about two seconds. The system will prompt to discover the loader device. Click the "Dev Partition" button to automatically read the partition address. There will be a prompt that some partitions cannot be read. Click OK. Click the right test area of the partition to select the partition mirror, and check the partition. Click the "Run" button will automatically flash and restart. Other partitions have been detected on the right but are not displayed in the list on the left, and when you need to flash the partition, you need to right-click on the left and select "Select Add Item", just enter the partition, click "Read Partition Table" again, and the software will automatically assign the partition address. Introduction to MASKROM mode If Loader mode is inaccessible (loader problem, etc.), press and hold the BOOT key, then press the reset key to enter maskrom mode for flashing. At this time, the system will prompt the discovery of a maskrom device. The flashing process is consistent with the loader mode, so it is best to use an update.img flashing. Note: Don't click "Device Partition Table" in maskrom mode, it is invalid.

OTA Description OTA, short for Over-the-Air Technology, refers to the process in Android systems where mobile devices download and install updates directly via wireless networks (such as WiFi, 3G/4G/5G) from remote servers, without needing to connect to a computer, simplifying the upgrade process and enhancing user experience. Advantages of OTA The advantages of OTA (Over-the-Air) updates in the Android ecosystem are significant and well-appreciated. The primary reason for their popularity is the convenience and speed – users can upgrade their devices without connecting to a computer, simply by being on a network, which saves a considerable amount of time and effort. Simultaneously, OTA updates efficiently and automatically detect new versions and notify users, ensuring that their devices always operate on the latest, most secure system or applications. This not only simplifies the process of manually searching for and installing updates but also reduces the security risks associated with outdated versions. Consequently, OTA updates are vital for enhancing user experience, lowering operational costs, and ensuring the security of devices. How to implement Android OTA upgrade in imx8mp platform? Build the OTA upgrade package 1. Build the target file Enter the related path： forlinx@ubuntu:~$ cd imx8mp/OK8MP-android-source/ forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ Configure the environment: forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ source env.sh forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ source build/envsetup.sh forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ lunch evk_8mp-userdebug ============================================ PLATFORM_VERSION_CODENAME=REL PLATFORM_VERSION=11 TARGET_PRODUCT=evk_8mp TARGET_BUILD_VARIANT=userdebug TARGET_BUILD_TYPE=release TARGET_ARCH=arm64 TARGET_ARCH_VARIANT=armv8-a TARGET_CPU_VARIANT=cortex-a53 TARGET_2ND_ARCH=arm TARGET_2ND_ARCH_VARIANT=armv7-a-neon TARGET_2ND_CPU_VARIANT=cortex-a9 HOST_ARCH=x86_64 HOST_2ND_ARCH=x86 HOST_OS=linux HOST_OS_EXTRA=Linux-5.4.0-150-generic-x86_64-Ubuntu-18.04.4-LTS HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release BUILD_ID=RQ1A.201205.003 OUT_DIR=out PRODUCT_SOONG_NAMESPACES=device/generic/goldfish device/generic/goldfish-opengl external/mesa3d vendor/nxp-opensource/imx/power hardware/google/pixel vendor/partner_gms hardware/google/camera vendor/nxp-opensource/imx/camera ============================================ Start compiling: forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ ./imx-make.sh bootloader kernel -j4 make: Entering directory '/home/forlinx/imx8mp/R3_6.28/OK8MP-android-source' /home/forlinx/imx8mp/R3_6.28/OK8MP-android-source/device/nxp/common/build/uboot.mk:74: *** shell env AARCH64_GCC_CROSS_COMPILE is not set. Stop. make: Leaving directory '/home/forlinx/imx8mp/R3_6.28/OK8MP-android-source' forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ make target-files-package -j4 ============================================ PLATFORM_VERSION_CODENAME=REL PLATFORM_VERSION=11 TARGET_PRODUCT=evk_8mp TARGET_BUILD_VARIANT=userdebug TARGET_BUILD_TYPE=release TARGET_ARCH=arm64 TARGET_ARCH_VARIANT=armv8-a TARGET_CPU_VARIANT=cortex-a53 TARGET_2ND_ARCH=arm TARGET_2ND_ARCH_VARIANT=armv7-a-neon TARGET_2ND_CPU_VARIANT=cortex-a9 HOST_ARCH=x86_64 HOST_2ND_ARCH=x86 HOST_OS=linux HOST_OS_EXTRA=Linux-5.4.0-150-generic-x86_64-Ubuntu-18.04.4-LTS HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release BUILD_ID=RQ1A.201205.003 OUT_DIR=out PRODUCT_SOONG_NAMESPACES=device/generic/goldfish device/generic/goldfish-opengl external/mesa3d vendor/nxp-opensource/imx/power hardware/google/pixel vendor/partner_gms hardware/google/camera vendor/nxp-opensource/imx/camera ============================================ [……] #### build completed successfully (13:07 (mm:ss)) #### After the compilation is completed, it will generate "evk_8mp-/target_files-eng.forlinx.zip" under the path "out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates/".target_files-eng.forlinx.zip" in the path "evk_8mp-eng.forlinx.zip", this is the zip package we need for OTA upgrade. forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ cd out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates/ forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates$ ls evk_8mp-target_files-eng.forlinx evk_8mp-target_files-eng.forlinx.zip evk_8mp-target_files-eng.forlinx.zip.list Back up "evk_8mp-target_files-eng.forlinx.zip"，rename to ''target_files_v1.0.zip''： forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates$ cp evk_8mp-target_files-eng.forlinx.zip target_files_v1.0.zip forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates$ ls evk_8mp-target_files-eng.forlinx evk_8mp-target_files-eng.forlinx.zip evk_8mp-target_files-eng.forlinx.zip.list target_files_v1.0.zip 2. Build a complete update package Configure the environment in the same way as in step 1. Compile command: forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ make otapackage -j4 ============================================ PLATFORM_VERSION_CODENAME=REL PLATFORM_VERSION=11 TARGET_PRODUCT=evk_8mp TARGET_BUILD_VARIANT=userdebug TARGET_BUILD_TYPE=release TARGET_ARCH=arm64 TARGET_ARCH_VARIANT=armv8-a TARGET_CPU_VARIANT=cortex-a53 TARGET_2ND_ARCH=arm TARGET_2ND_ARCH_VARIANT=armv7-a-neon TARGET_2ND_CPU_VARIANT=cortex-a9 HOST_ARCH=x86_64 HOST_2ND_ARCH=x86 HOST_OS=linux HOST_OS_EXTRA=Linux-5.4.0-150-generic-x86_64-Ubuntu-18.04.4-LTS HOST_CROSS_OS=windows HOST_CROSS_ARCH=x86 HOST_CROSS_2ND_ARCH=x86_64 HOST_BUILD_TYPE=release BUILD_ID=RQ1A.201205.003 OUT_DIR=out PRODUCT_SOONG_NAMESPACES=device/generic/goldfish device/generic/goldfish-opengl external/mesa3d vendor/nxp-opensource/imx/power hardware/google/pixel vendor/partner_gms hardware/google/camera vendor/nxp-opensource/imx/camera ============================================ [……] #### build completed successfully (13:07 (mm:ss)) #### After compilation, "evk_8mp-ota-eng.forlinx.zip" will be generated under "out/target/product/evk_8mp/", this is the zip file we need for the OTA upgrade. This is the zip file we need for the OTA upgrade. forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ cd out/target/product/evk_8mp/ forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp$ ls evk* evk_8mp-ota-eng.forlinx.zip Back up ''evk_8mp-ota-eng.forlinx.zip''，re name to ''full-ota_v1.0.zip''： forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp$ cp evk_8mp-ota-eng.forlinx.zip full-ota_v1.0.zip forlinx@ubuntu:~/imx8mp/OK8MP-android-source/out/target/product/evk_8mp$ ls full* full-ota_v1.0.zip After completing steps 1 and 2, you can modify the source code according to actual needs. After the modification is completed, follow steps 1 and 2 again, at this time the new "evk_8mp-target_files-eng.forlinx.zip" is renamed "target_files_v2.0.zip"; "evk_8mp-ota-eng.forlinx.zip" is renamed "full-ota_eng.forlinx"; "evk_8mp-ota-eng.forlinx.zip" is renamed "full-ota_eng.forlinx"."; "evk_8mp-target_files-eng.forlinx.zip", renamed to "full-target_v2.0.zip". 3. Compile incremental upgrade package The incremental update package contains only the encoding of the differences between the two files. The incremental update package can only be installed on devices using the old or source version. Before building the incremental update package, two target files need to be built. Old packages that have been applied on the device, such as the target _ files _ v1.0.zip saved earlier; The latest package waiting for the application on the device, such as the target _ files _ v2.0.zip saved earlier. In the Android environment, use the following command to generate the incremental upgrade package: forlinx@ubuntu:~/imx8mp/R3_6.28/OK8MP-android-source$ cp out/target/product/evk_8mp/obj/PACKAGING/target_files_intermediates/target_files_v* ./ forlinx@ubuntu:~/imx8mp/OK8MP-android-source$ out/host/linux-x86/bin/ota_from_target_files -i target_files_v1.0.zip target_files_v2.0.zip incremental-ota.zip Note: Copy target_files_v1.0.zip and target_files_v2.0.zip to the OK8MP-android-source directory first, otherwise the execution command will report an error. 4. Upgrade with full package (using update system from development board storage). Copy the compiled "full-ota_v1.0.zip" to a USB flash drive and extract it to get payload.bin and payload_properties.txt. Insert the USB drive into the development board. The path to the USB drive is a directory under /mnt/media_rw/ with a random name; use the actual name. In this case, it is: CA35-A916. Copy payload.bin and payload_properties.txt to the /data/ota_package directory of the development board: evk_8mp:/ $ su evk_8mp:/ # cd /data/ota_package/ evk_8mp:/data/ota_package # cp /mnt/media_rw/CA35-A916/full-ota_v1.0/payload* ./ evk_8mp:/data/ota_package # ls payload.bin payload_properties.txt View payload_properties.txt: evk_8mp:/ # cat payload_properties.txt FILE_HASH=isiQeegRKyOdi9/aazwQjrZWRAIbB1Nyj1WdZ22L3Pk= FILE_SIZE=555766395 METADATA_HASH=p0+xQATUAG7dZg/kuPaQACDdClkEOZDHoOhxx0lBEuA= METADATA_SIZE=56853 Note: The contents in different payload _ properties. txt are inconsistent, and the actual queried values are the main ones. Enter the following command on the debug serial port to update: evk_8mp:/ # update_engine_client --payload=file:///data/ota_package/payload.bin --up\ date -- headers="FILE_HASH=isiQeegRKyOdi9/aazwQjrZWRAIbB1Nyj1WdZ22L3Pk= FILE_SIZE=555766395 METADATA_HASH=p0+xQATUAG7dZg/kuPaQACDdClkEOZDHoOhxx0lBEuA= METADATA_SIZE=56853" Description: payload specifies the upgrade file,/data/ota _ package/payload. bin is the path to the file. headers is the file information of the upgrade file, which is obtained from the payload _ properties. txt. Note: When entering commands, ensure that values enclosed within double quotes, such as FILE_HASH, are entered on a new line. The system automatically executes the command that follows after recognizing the backtick. Also, make sure that you do not add any spaces after each value, as adding spaces may cause errors in parsing. After the input is completed, the update _ engine _ client will be automatically upgraded in the background. You can use the following command to view the progress. evk_8mp:/ # logcat -s update_engine [……] 08-08 16:38:33.926 569 569 I update_engine: [INFO:update_attempter_android.cc(535)] Update successfully applied, waiting to reboot. [……] The above message indicates that the upgrade is complete. Restart the development board to switch to the new system. 5. Upgrade with incremental packages Note on incremental upgrades: An incremental upgrade is an upgrade between two target files, replacing only the parts that differ between the two targets. The same code generates different target files each time. For example, if the current code commit is A, and you have used the ''target files'' command multiple times to generate A1, A2, and A3, then after modifying the code, the code becomes B, and using the ''target files'' command generates B1. If at this point the program on the board is identical to target files A1, then the incremental package generated with A1 and B1 can be successfully upgraded. However, the incremental packages generated with A2 and A3 and B1 cannot be successfully upgraded due to a hash value verification failure in the partition. When creating and performing an upgrade using the incremental package method, upgrade failures often occur, primarily due to the reasons mentioned above. In order for the upgrade to be successful, it is necessary to ensure that the system's internal programs are identical to the old target files used to generate the upgrade package. Flashing the system is done via image writing, so the hash values of the various partitions will differ from those of the target file we generated. Consequently, if an incremental upgrade is to be used, the initial upgrade must be performed with a full package, and the target file corresponding to this full package must be preserved as the foundation for the subsequent incremental upgrade. Subsequently, the target file from each upgrade must be retained as the basis for the next incremental upgrade. If the hash values within the system do not match those required by the incremental package, a full package upgrade is needed to establish the correct correspondence. So, the incremental upgrade tests were all incremental upgrade tests after a full upgrade had been completed. The incremental upgrade steps are the same as the full package upgrade, just follow step 4.

Product Background With the rapid development and widespread application of drone technology, drone-mounted hyperspectral imaging systems that integrate drone platforms with high-precision spectral imaging technology are gradually gaining attention. The drone-mounted hyperspectral imaging system can measure spectral information of plants, water bodies, soil, etc., in real-time and generate spectral images. By analyzing these images, it is possible to establish relationships with the physicochemical properties of plants and use the data for research on plant classification and growth conditions. Additionally, it has applications in geological and mineral resource exploration, forest pest and disease monitoring, meteorological studies, and other industry fields. Product Features Hyperspectral resolution: Capable of capturing hundreds of continuous and narrow spectral bands, enabling detailed spectral characterization of surface materials. High spatial resolution: Combined with the flexibility and stability of the drone platform, this enables high-resolution imaging of ground targets. Intelligent data processing: Integrates advanced image processing algorithms and spectral analysis software, supporting rapid processing and interpretation of data. Portability and ease of use: The equipment is lightweight and portable, making it easy to mount on drone platforms, while the user interface is user-friendly, simplifying operation for users. Broader application scenarios: Suitable for environmental monitoring, agricultural surveys, geological exploration and other fields, meeting the needs of different users. Product Requirements: 1. Compact carrier board design: Considering the weight and space constraints of the drone, the accompanying imaging device needs to be designed as compactly as possible. The carrier board design should be compact, effectively utilizing every inch of space while ensuring that all key components can be securely installed. The size of the SoM should also be strictly controlled to fit the compact carrier board layout, without sacrificing its performance. 2. High compression ratio image compression algorithm: The product should incorporate a proprietary high compression ratio image compression algorithm to optimize the storage and transmission efficiency of image data. The algorithm needs to fully leverage the computational power of the SoM to ensure that excessive performance loss does not occur during image compression. The compression algorithm should minimize file size while maintaining image quality to accommodate the limited data transmission bandwidth and storage space of drones. 3. High-quality product stability: Given the complexity of the product application environment, such as extreme weather and mechanical vibrations, the requirements for product quality and stability are extremely high. All components and materials shall be of industrial grade or higher quality to ensure proper operation in a variety of harsh environments. Products shall be subjected to rigorous tests for shock, impact and weather resistance to verify their reliability in complex application environments. Based on the product characteristics, Forlinx Embedded recommends using the FET3588J-C system on module(SoM) as the hardware design solution for the product. Solution Features: 1. Strong performance support High-performance processor: FET3588-C is based on Rockchip's new flagship RK3588 processor, which adopts an 8nm manufacturing process and integrates a quad-core Cortex-A76+quad-core Cortex-A55 architecture with a clock speed up to 2.4GHz, ensuring strong data processing capabilities for drones during hyperspectral imaging. Powerful computing power: The built-in NPU provides 6 TOPS computing power, which makes it possible for artificial intelligence to be applied in UAV hyperspectral imaging, such as automatic target recognition, real-time analysis, etc. 2. Excellent image processing capabilities Next-generation ISP 3.0: The FET3588-C introduces a 48-megapixel ISP 3.0, which supports various image optimization functions such as lens shading correction and 2D/3D noise reduction. This is crucial for enhancing the quality and clarity of hyperspectral imaging. 3. Highly integrated and scalable Abundant high-speed data communication interfaces: FET3588-C is equipped with high-speed data communication interfaces, which can ensure the rapid transmission and processing of hyperspectral imaging data and improve the operation efficiency. 4. Wide application adaptability Temperature range upgrade: The temperature range of the commercial-grade FET3588-C SoM is increased from 0 ℃ ~ + 80 ℃ to -20 ℃ ~ + 85 ℃, enabling the UAV to perform hyperspectral imaging operations in a wider range of environmental conditions. Support for multiple operating systems: Adapt to multiple operating systems, provide flexibility for different users and development environments, and facilitate the integration and development of hyperspectral imaging systems. In short, the FET3588-C SoM offers strong performance, great image processing, flexible display setup, high integration and scalability, and wide adaptability for use in unmanned aerial vehicle hyperspectral imaging equipment. These advantages make FET3588-C an ideal choice for UAV hyperspectral imaging.

In order to fully meet the growing demand in the AIoT market for high-performance, high-computing-power, and low-power main controllers, Forlinx Embedded has recently launched the FET3576-C System on Module, designed based on the Rockchip RK3576 processor. It features excellent image and video processing capabilities, a rich array of interfaces and expansion options, low power consumption, and a wide range of application scenarios. This article delves into the distinctive benefits of the Forlinx Embedded FET3576-C SoM from four key aspects. Advantages: 6TOPS computing power NPU, enabling AI applications Forlinx Embedded FET3576-C SoM has a built-in 6TOPS super arithmetic NPU with excellent deep learning processing capability. It supports INT4/ INT8/ INT16/ FP16/ BF16/ TF32 operation. It supports dual-core working together or independently so that it can flexibly allocate computational resources according to the needs when dealing with complex deep learning tasks. It can also maintain high efficiency and stability when dealing with multiple deep-learning tasks. FET3576-C SoM also supports TensorFlow, Caffe, Tflite, Pytorch, Onnx NN, Android NN and other deep learning frameworks. Developers can easily deploy existing deep learning models to the SoM and conduct rapid development and optimization. This broad compatibility not only lowers the development threshold, but also accelerates the promotion and adoption of deep learning applications. Advantages: Firewall achieves true hardware resource isolation The FET3576-C SoM with RK3576 processor supports RK Firewall technology, ensuring hardware resource isolation for access management between host devices, peripherals, and memory areas. Access Control Policy - RK Firewall allows configuring policies to control which devices or system components access hardware resources. It includes IP address filtering, port control, and specific application access permissions. Combined with the AMP system, it efficiently manages access policies for diverse systems. Hardware Resource Mapping and Monitoring - RK Firewall maps the hardware resources in the system, including memory areas, I/O devices, and network interfaces. By monitoring access to these resources, RK Firewall can track in real-time which devices or components are attempting to access specific resources. Access Control Decision - When a device or component attempts to access hardware resources, RK Firewall will evaluate the access against predefined access control policies. If the access request complies with the policy requirements, access will be granted; otherwise, it will be denied. Isolation Enforcement - For hardware resources identified as requiring isolation, RK Firewall will implement isolation measures to ensure that they can only be accessed by authorized devices or components. In summary, RK Firewall achieves effective isolation and management of hardware resources by setting access control policies, monitoring hardware resource access, performing permission checks, and implementing isolation measures. These measures not only enhance system security but also ensure system stability and reliability. Advantages: Ultra clear display + AI intelligent repair With its powerful multimedia processing capability, FET3576-C SoM provides users with excellent visual experience. It supports H.264/H.265 codecs for smooth HD video playback in various scenarios, while offering five display interfaces (HDMI/eDP, MIPI DSI, Parallel, EBC, DP) to ensure compatibility with diverse devices. FET3576-C SoM notably supports triple-screen display functionality, enabling simultaneous display of different content on three screens, significantly enhancing multitasking efficiency. In addition, its 4K @ 120Hz ultra-clear display and super-resolution function not only brings excellent picture quality enjoyment, but also intelligently repairs blurred images, improves video frame rate, and brings users a clearer and smoother visual experience. Advantage: FlexBus new parallel bus interface FET3576-C of Forlinx Embedded offers a wide range of connectivity and transmission options with its excellent interface design and flexible parallel bus technology. The FlexBus interface on the SoM is particularly noteworthy due to its high flexibility and scalability, allowing it to emulate irregular or standard protocols to accommodate a variety of complex communication needs. FlexBus supports parallel transmission of 2/4/8/16bits of data, enabling a significant increase in the data transfer rate, while the clock frequency of up to 100MHz further ensures the high efficiency and stability of data transmission. In addition to the FlexBus interface, the FET3576-C SoM integrates a variety of bus transfer interfaces, including DSMC, CAN-FD, PCIe2.1, SATA3.0, USB3.2, SAI, I2C, I3C and UART. These interfaces not only enriches the SoM's application scenarios but also enhances its compatibility with other devices and systems. It is easy to see that with the excellent advantages of high computing power NPU, RK Firewall, powerful multimedia processing capability and FlexBus interface, Forlinx Embedded FET3576-C SoM will become a strong player in the field of embedded hardware. Whether you are developing edge AI applications or in pursuit of high-performance, high-quality hardware devices, the Folinx Embedded FET3576-C SoM is an unmissable choice for you.

Note: Operate under the root user by default. 1. Qemu and Debootstrap Installation Since a Debian file system is built on Ubuntu, these two tools can be installed directly using the apt-get command. The commands are as follows: sudo apt-get install binfmt-support qemu qemu-user-static debootstrap 2. Extracting Debian File System Use the debootstrap command to extract the file system. Execute the following command to retrieve the file system from the Debian mirror: mkdir /home/forlinx/debian sudo debootstrap --arch=armhf --foreign buster root https://mirrors.tuna.tsinghua.edu.cn/debian/ Explanation of command parameters: arch：Specify CPU architecture buster：Debian version (currently 10) foreign：Use when initializing unpacking in a different architecture than the host root：The folder where the file system is stored https: // mirrors.tuna.tsinghua.edu.cn / debian /：Download source Extraction may take around 10 minutes. Please be patient. Successful extraction reveals the Linux directory tree. If extraction fails, try multiple attempts or switch networks. 3. Perfecting the File System Since the operation is conducted on an X86 virtual machine, QEMU needs to be used to simulate an ARM environment to improve the file system. a.To copy qemu-arm-static into the newly built base system, use the following command: cd root sudo cp /usr/bin/qemu-arm-static usr/bin cd .. b.Initialize the file system. Execute the following command: sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot root debootstrap/debootstrap --second-stage c.Use the chroot root command to initialize file system chroot root d.Use the command to create the following echo "proc /proc proc defaults 0 0" >> etc/fstab mkdir -p usr/share/man/man1/ mknod dev/console c 5 1 e.To update the download sources, use the command vi /etc/apt/sources.list to open the source.list file and replace the contents with the following: deb http://mirrors.ustc.edu.cn/debian stable main contrib non-free #deb-src http://mirrors.ustc.edu.cn/debian stable main contrib non-free deb http://mirrors.ustc.edu.cn/debian stable-updates main contrib non-free #deb-src http://mirrors.ustc.edu.cn/debian stable-updates main contrib non-free #deb http://mirrors.ustc.edu.cn/debian stable-proposed-updates main contrib non-free #deb-src http://mirrors.ustc.edu.cn/debian stable-proposed-updates main contrib non-free Then save and exit. Use the command apt-get update to update the source. If updating the download source reports an error,use the date command to modify the system time to solve the problem. f.Use the command apt-get install vim to install some necessary software apt-get install vim apt-get install sudo apt-get install dpkg apt-get install bzip2 apt-get install net-tools apt-get install ntpdate g.Create a new user with the command adduser forlinx, then enter the password adduser forlinx h.Set the root password, use the command passwd root, and set the password to forlinx. passwd root i.To set up Ethernet, enter the following command: vi /etc/network/interfaces As follows: #/etc/network/interfaces -- configuration file for ifup(8), ifdown(8) #The loopback interface auto lo iface lo inet loopback #Wireless interfaces iface wlan0 inet dhcp wireless_mode managed wireless_essid any wpa-driver wext wpa-conf /etc/wpa_supplicant.conf iface atml0 inet dhcp #Wired or wireless interfaces auto eth0 #iface eth0 inet dhcp #iface eth1 inet dhcp iface eth0 inet static address 192.168.0.232 netmask 255.255.255.0 gateway 192.168.0.1 broadcast 192.168.0.255 auto eth1 iface eth1 inet static address 192.168.1.232 netmask 255.255.255.0 gateway 192.168.1.1 broadcast 192.168.1.255 #Ethernet/RNDIS gadget (g_ether) #... or on host side, usbnet and random hwaddr iface usb0 inet static address 192.168.7.2 netmask 255.255.255.0 network 192.168.7.0 gateway 192.168.7.1 #Bluetooth networking iface bnep0 inet dhcp Add a network reboot cd etc/rc5.d/ vi /etc/rc5.d/S02net_restart.sh As follows: #!/bin/bash echo "network restarting!" /etc/init.d/networking restart echo "network restart complete!" j.Modify host name vi /etc/hostname Modify to: Debian k.Modify the system time zone cp /usr/share/zoneinfo/Hongkong /etc/localtime ntpdate ntp.aliyun.com Take East Zone 8 as an example, other time zone files are also included under this path. l.Since 6ull is weak, skip installing the desktop and go straight to using the exit m.Just exit the qemu environment exit 4. Package the file system Go to the debian filesystem directory and use the command tar - cjf rootfs.tar.bz2. / * to package it. 5. Burn-in verification Place the packaged file system into the burner, while keeping the other images as they are and only replacing the file system. Then proceed with the burn-in test. 6. Debian command a.Check Debian version cat /etc/issue b.Install wget apt-get install wget Solve ERROR: The certificate of ‘packages.microsoft.com’ is not trusted. Report error，then add -- no - check - certificate after the command. Appendix: Installation Method for .net on Linux 1. Download the .net compressed package from the official website https://dotnet.microsoft.com/en-us/download/dotnet/6.0 2. Enter the /home/root directory cd /home/root 3. Install script settings vi install.sh The script is as follows: #!/bin/sh DOTNET_FILE=dotnet-sdk-6.0.402-linux-arm.tar.gz export DOTNET_ROOT=$(pwd)/.dotnet mkdir -p "$DOTNET_ROOT" && tar zxf "$DOTNET_FILE" -C "$DOTNET_ROOT" export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools DOTNET_FILE is the name of the downloaded zip file. 4. Execute the installation chmod u+x install.sh ./install.sh 5. Modify environment variables vi /etc/profile As follows: export DOTNET_ROOT=$HOME/.dotnet export PATH=$PATH:$HOME/.dotnet:$HOME/.dotnet/tools 6. Test Enter the following command: dotnet new console -o sample1 cd sample1 dotnet run The following output should be seen: Hello World!

1. Product Description Vending machines, combining modern technology with the idea of convenient shopping, have become essential in our lives. It breaks through the constraints of time and space, providing us with round-the-clock uninterrupted product purchasing services. Whether in busy transportation hubs or quiet residential areas, you can always find its presence. 2. Components: Body Compartment: Made from high-strength, corrosion-resistant metal materials to ensure the stability and durability of the vending machine. The warehouse's interior is well-designed and can be adjusted according to the size of the goods to maximize the use of storage space. Payment System: Integrated with multiple payment methods including coins, bills, card swiping, and mobile payments, satisfying various consumer payment needs. Display and operation: HD touchscreen shows product information and purchase process, simplifying steps to enhance user experience. Product Delivery System: Uses precise mechanics and sensors for accurate, fast delivery to the outlet after payment. Communication Management System: Enables real-time monitoring, sales data analysis, and remote fault diagnosis and repair of vending machines via wireless network. Business Logic Topology The vending machine's main control system acts as its operational core, akin to its "brain", overseeing and coordinating each module's functions. With the ongoing development of IoT, big data, and AI, automation has become an inevitable trend in the vending machine industry. This has led to new demands for the main control systems, focusing on: Core Controller: It is essential to choose a stable, reliable, and high-performance core controller to ensure the overall logic control and data processing capabilities of vending machines. Device Stability: It requires 24/7 uninterrupted operation, necessitating high stability and durability in both hardware and software. Specifically, the software system should have fault self-check and automatic recovery capabilities. Scalability and Compatibility: To meet various scenarios and demands, the main control system of vending machines needs to be scalable. As products evolve, the main control system should be compatible with new hardware and software standards. Payment Security: As payment methods diversify, ensuring the security of the payment process has become increasingly important. Vending machines need to guard against various security threats, such as data breaches and fraudulent activities. AI Integration: Vending machines need to have intelligent recognition capabilities and data analysis abilities to recommend products based on users' purchasing preferences. FET3568-C system on module(SoM) from Forlinx Embedded Systems offers high performance, low power consumption, and rich functionality, making it ideal for vending machines for these reasons: Powerful Performance: FET3568-C SoM is based on the Rockchip RK3568 processor, which features a quad-core 64-bit Cortex-A55 architecture with a clock speed of up to 2.0GHz. It supports lightweight edge AI computing and delivers strong computational and processing capabilities. Such performance meets the high demands of logic control and data processing for vending machine control systems, ensuring efficient and stable operation of the vending machines. Rich Interfaces and Expandability: The FET3568-C SoM offers 3 x PCIe slots, 4 x USB ports, 3 x SATA3.0 controllers, and 2 x Gigabit Ethernet ports. It supports 5 x display interfaces including HDMI2.0, eDP, LVDS, RGB Parallel, and MIPI-DSI, with up to three simultaneous display outputs. These interfaces provide great convenience for expanding the functionality of vending machines, enabling customized development to meet various scenarios and requirements. Multi-OS Support: FET3568-C SoM supports multiple operating systems including Linux, Android 11, Ubuntu, and Debian 11. This flexibility allows developers to choose the most suitable operating system according to actual needs, thereby simplifying the software development process and improving development efficiency. Meanwhile, Forlinx Embedded has made numerous optimizations in software, such as introducing a 4G watchdog process. This design ensures that the 4G communication function can automatically recover after a disconnection, significantly improving the stability and reliability of the vending machine's network communication. Advanced Security: In terms of security, the FET3568-C hardware can integrate encryption chips and trusted root modules. These hardware-level security measures provide solid protection for system information security. The ability to verify software integrity and authenticity from the hardware level effectively prevents the intrusion of malicious software and the risk of system tampering. High Stability: FET3568-C has undergone rigorous environmental temperature testing, stress testing, and long-term stability operation testing, ensuring stable and reliable performance in various terminals and operational environments. This is crucial for vending machines that require 24/7 uninterrupted operation, as it can significantly reduce failure rates and enhance user experience. In summary, the FET3568-C SoM not only features robust performance and stability, but also offers flexible operating system options, optimized software design, rich interfaces, and powerful expandability. These features make it an ideal choice for vending machine control solutions, capable of meeting the evolving needs of the industry.

Introduction to the U-Boot boot process U-Boot Boot Process Stage 1 Main process Partial Hardware Initialization -> Load Full U-Boot into RAM -> Jump to Stage 2 Entry for Execution. Files Used Mainly in Stage 1 (Non-Open Source Scenario): start.S (Hardware Initialization, watchdog, interrupts, clock configurations) lowlevel_init.S (RAM (DDR) initialization, U-Boot code loading, stack setup, BSS clearing, jump to U-Boot Stage 2 U-Boot Boot Process Stage 2 Stage 2 involves further hardware initialization by U-Boot, configuring command line parameters and environment variables, and transitioning to the kernel. The main documents used are: board.c file: Typically, our own files are located in the board/forlinx/ directory. main.c file: Located in the common directory Main function Some of the more important initialisation functions are as follows: 1.''setup_mon_len'' function: Set the ''gd'' structure's ''mon_len'' member variable, representing the length of the entire code; 2.''initf_malloc'' function: Sets the ''gd '' structure's member variables related to ''malloc''; 3.''board_early_init_f''function; 4.To initialize the IO configuration of the serial port, defined in the board/freescale/mx6ull_toto/mx6ull_toto.cfile; 5.''timer_init'' function: Initialize the kernel timer to provide clock ticks for U-Boot, defined in the ''arch/arm/imxcommon/timer.c''file; 6.''get_clocks'' function: Retrieve the clock for the SD card peripheral (sdhc_clk), defined in the arch/arm/imxcommon/speed.c file; 7.''init_baud_rate'' function: Initialize the baud rate, defined in the ''common/board_f.c'' file. 8.''serial_init'' function: Initialize serial communication settings, defined in the''drivers/serial/serial.c''file; 9.''console_init_f'' function: Initialize the console, defined in the ''common/console.c'' file; 10.''display_options'' function: Print U-Boot version information and compilation details, defined in the lib/display_options.c file; 11.''print_cpuinfo'' function: To display CPU information and the main clock frequency, defined in the arch/arm/imx-common/cpu.c file; 12.''show_board_info'' function: Print development board information, defined in the common/board _ info.c file; 13.''init_func_i2c'' function: To initialize I2C; 14.''announce_dram_init'' function: This function is simple, it outputs the string "DRAM:"; 15.''dram_init'' function: Doesn't actually initialize DDR but rather sets the value of gd->ram_size. Current U-boot startup print information U-Boot SPL 2021.01-gd1345267-dirty (Jul 08 2023 - 08:00:49 +0800) SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.1--w2022.07-am62x (Terrifi') am625_init: board_init_f done(counter=1) SPL initial stack usage: 13768 bytes i2c_write: error waiting for data ACK (status=0x116) i2c_write: error waiting for data ACK (status=0x116) Auth Success! normal mode am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 Loading Environment from MMC... MMC: block number 0x3500 exceeds max(0x2000) *** Warning - !read failed, using default environment am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 init_env from device 9 not supported! Starting ATF on ARM64 core... NOTICE: BL31: v2.5(release):v0.6-6-gd489c56b NOTICE: BL31: Built : 15:08:18, Jun 26 2023 U-Boot SPL 2021.01-gd1345267-dirty (Jul 08 2023 - 08:00:56 +0800) SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.1--w2022.07-am62x (Terrifi') am625_init: board_init_f done am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 U-Boot 2021.01-gd1345267-dirty (Jul 08 2023 - 08:00:56 +0800) SoC: AM62X SR1.0 Model: Forlinx OK62xx-C board DRAM: 2 GiB MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from MMC... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 52334 bytes read in 5 ms (10 MiB/s) Saving Environment to MMC... Writing to MMC(0)... OK Net: eth0: ethernet@8000000 Autoboot in 1 seconds switch to partitions #0, OK mmc0(part 0) is current device SD/MMC found on device 0 Failed to load 'boot.scr' Failed to load 'uEnv.txt' MMC: no card present 20208128 bytes read in 111 ms (173.6 MiB/s) 52334 bytes read in 5 ms (10 MiB/s) 4595 bytes read in 5 ms (897.5 KiB/s) ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Device Tree to 000000008fef0000, end 000000008fffffff ... OK U-boot shortens 2 seconds of boot time by disabling USB and Ethernet via defconfig.Modify the autoboot.c file to hardcode bootdelay=0, reducing it by 1 second. diff --git a/common/autoboot.c b/common/autoboot.c index e628baff..685779b6 100644 --- a/common/autoboot.c +++ b/common/autoboot.c @@ -328,10 +328,11 @@ const char *bootdelay_process(void) int bootdelay; bootcount_inc(); - +/* s = env_get("bootdelay"); bootdelay = s ? (int)simple_strtol(s, NULL, 10) : CONFIG_BOOTDELAY; - +*/ +bootdelay = 0; if (IS_ENABLED(CONFIG_OF_CONTROL)) bootdelay = fdtdec_get_config_int(gd->fdt_blob, "bootdelay", bootdelay); Comment out the function that reads uEnv.txt file. Remove useless printed information. Cropped Log 16:33:00:290 U-Boot SPL 2021.01-gd1345267-dirty (Jul 25 2023 - 16:14:18 +0800) 16:33:00:303 SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.1--w2022.07-am62x (Terrifi') 16:33:00:351 am625_init: board_init_f done(counter=1) 16:33:00:351 SPL initial stack usage: 13768 bytes 16:33:01:527 i2c_write: error waiting for data ACK (status=0x116) 16:33:01:527 i2c_write: error waiting for data ACK (status=0x116) 16:33:01:527 Auth Success! 16:33:01:544 normal mode 16:33:01:544 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 16:33:01:544 Trying to boot from MMC1 16:33:01:729 Loading Environment from MMC... MMC: block number 0x3500 exceeds max(0x2000) 16:33:01:749 *** Warning - !read failed, using default environment 16:33:01:749 16:33:01:776 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 16:33:01:795 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 16:33:01:795 init_env from device 9 not supported! 16:33:01:795 Starting ATF on ARM64 core... 16:33:01:795 16:33:01:812 NOTICE: BL31: v2.5(release):v0.6-6-gd489c56b 16:33:01:812 NOTICE: BL31: Built : 15:08:18, Jun 26 2023 16:33:02:990 16:33:02:997 U-Boot SPL 2021.01-gd1345267-dirty (Jul 25 2023 - 16:14:43 +0800) 16:33:02:997 SYSFW ABI: 3.1 (firmware rev 0x0015 '21.5.1--w2022.07-am62x (Terrifi') 16:33:02:997 am625_init: board_init_f done 16:33:03:022 am625_init: spl_boot_device: devstat = 0x1843 bootmedia = 0x9 bootindex = 0 16:33:03:022 Trying to boot from MMC1 16:33:04:507 16:33:04:507 16:33:04:507 U-Boot 2021.01-gd1345267-dirty (Jul 25 2023 - 16:14:43 +0800) 16:33:04:507 16:33:04:507 SoC: AM62X SR1.0 16:33:04:508 Model: Forlinx OK62xx-C board 16:33:04:530 DRAM: 1 GiB 16:33:04:593 MMC: mmc@fa10000: 0, mmc@fa00000: 1 16:33:04:640 Loading Environment from MMC... OK 16:33:04:640 In: serial@2800000 16:33:04:640 Out: serial@2800000 16:33:04:640 Err: serial@2800000 16:33:04:654 51701 bytes read in 6 ms (8.2 MiB/s) 16:33:04:654 using kernel dtb display control 16:33:04:685 Saving Environment to MMC... Writing to MMC(0)... OK 16:33:04:701 Net: eth0: ethernet@8000000 16:33:04:701 Autoboot in 0 seconds 16:33:04:748 switch to partitions #0, OK 16:33:04:748 mmc0(part 0) is current device 16:33:04:795 SD/MMC found on device 0 16:33:05:104 3229642 bytes read in 141 ms (21.8 MiB/s) 16:33:05:228 20075008 bytes read in 111 ms (172.5 MiB/s) 16:33:05:228 51701 bytes read in 6 ms (8.2 MiB/s) 16:33:05:244 4575 bytes read in 5 ms (893.6 KiB/s) 16:33:05:285 ## Flattened Device Tree blob at 88000000 16:33:05:285 Booting using the fdt blob at 0x88000000 16:33:05:306 Loading Device Tree to 000000008fef0000, end 000000008fffffff ... OK 16:33:05:306 16:33:05:306 Starting kernel ...