Introduction With the rapid development of embedded technology and the widespread application of Linux in the information industry, it has become possible to implement image acquisition and processing using embedded Linux systems. Real-time acquisition of image data is a crucial step in realizing these applications. This paper uses the Samsung S3C2410 processor as the system hardware platform and designs a method for establishing image and video processing on an embedded Linux system platform based on this. 1 System Hardware Circuit Design The S3C2410 chip processor integrates a 32-bit microcontroller with the ARM920T processor core from ARM Corporation. It has abundant resources, including an independent 16 kB instruction cache and 16 kB data cache, an LCD (liquid crystal display) controller, a RAM controller, a NAND flash memory controller, 3 UARTs, 4 DMAs, 4 timers with PWM, parallel I/O ports, 8 10-bit ADCs, a Touch Screen interface, an I2C interface, an I2S interface, 2 USB interface controllers, and 2 SPIs. The maximum clock frequency can reach 203 MHz. Based on the processor's abundant resources, this platform is configured with 64 MB of Flash and 64 MB of 32-bit SDRAM to support the needs of the operating system and LCD display. The S3C2410 has a built-in LCD controller, which can support TFT color LCD screens with a maximum of 256k colors and STN color LCD screens with a maximum of 4k colors. Considering the relatively high requirements for image display in the application field of this system, an 8-inch 640×480 TFT LCD screen (model LQ080V3DG01) is used. The LQ080V3DG01 requires a typical power supply voltage Vdd of 3.3 V/5 V, and the minimum high-level input voltage Vih for LCD data and control signals is 2.3 V. Therefore, this system directly connects to it using the S3C2410's control lines without setting up a level conversion circuit. The specific circuit connection is shown in Figure 1. The chip operates in 16-bit color (5:6:5). 2 System Software Design 2.1 Linux Operating System The software of this video display system is based on embedded Linux. Linux is a free, fast, and efficient operating system. In recent years, embedded operating systems based on the open-source Linux system have seen significant development. Although Linux is not a microkernel architecture, its modular structure allows users to easily configure it, removing unnecessary modules to reduce system overhead, resulting in a size of only a few hundred kilobytes. Considering system functionality, scalability, and operating speed, the embedded Linux kernel version used in this solution is kernel-2.4.18. After installing the embedded Linux operating system μCLinux on the S3C2410-based hardware platform, a driver for the LCD needs to be developed under μCLinux to ensure proper LCD display. 2.2 Framebuffer Device Driver The framebuffer is a driver interface that appears in the Linux 2.2.xx kernel. This device provides an abstract description of the LCD controller. It also represents the video memory on the LCD controller. Applications can access the LCD controller through a predefined interface without needing to know any underlying operations. This system uses the framebuffer to implement the LCD driver development. This device uses a special device node; it's a character device with a major device number of 29 and a minor device number defining the number of framebuffers. From the user's perspective, the framebuffer device is similar to other devices located under `/dev`. The framebuffer's display buffer resides in the kernel address space of μCLinux. In μCLinux, each application has its own virtual address space, and applications cannot directly access the physical buffer address. Therefore, μCLinux provides the `mmap` function to map file contents to the application space. For the framebuffer device, this mapping operation maps the physical address of the screen buffer to a segment of virtual addresses in the application space. Then, the screen buffer can be accessed by reading and writing to this virtual address to draw on the screen. The memory block distribution in the framebuffer is shown in Figure 2. The framebuffer device is a regular memory device, supporting direct reading and writing of its contents. It supports the `read`, `write`, `seek`, and `mmap` functions. The difference is that the framebuffer's memory is not all memory areas, but rather the portion of memory dedicated to the LCD controller. `/dev/fb*` allows the use of `ioctl` operations, which can be used to read or set device parameters. The color map is also set via `ioctl`. Below is a section on ioctl and its related applications and data structures in this system: a) Retrieving some invariant information about the device, such as the device name, the length of the memory area corresponding to the screen organization, and the starting address. b) Retrieving information that can change, such as bit depth, color format, timing, etc. If these values ​​are changed, the driver will optimize the values ​​to meet the device characteristics. c) Retrieving or setting parts of the color table. However, in actual system applications, using the read and write functions to continuously seek addresses before reading or writing will cause a lot of overhead. The basic solution is to map screen memory. When screen memory is mapped to the application, a pointer directly pointing to screen memory will be obtained. In this system and other similar applications, information must first be retrieved from the newly acquired framebuffer device. The framebuffer device largely relies on three data structures: Stnlct fb_var_screeninfo; Struct fb_fix_screeninfo; and Struct fb_info, which are declared in include/linux/fb.h. The first structure describes the characteristics of the graphics card and is usually set by the user. The second structure defines the hardware characteristics of the graphics card, which cannot be changed; once the LCD controller and display are selected, its hardware characteristics are fixed. The third structure defines the independent state of the current graphics card frame buffer device. 2.3 Implementation of the Frame Buffer Driver Similar to general applications, in this system implementation, the application mainly implements kernel control over the frame buffer through the following three methods: a) Read/write /dev/fb: equivalent to reading/writing the screen buffer. b) Mapping operation : Through mapping operations, the physical address of the screen buffer can be mapped to a segment of virtual address space in user space. Then, the user can access the screen buffer and draw on the screen by reading and writing this virtual address. c) I/O control: For the frame buffer device, the ioctl operation of the device file can read the parameters of the display device and screen, such as resolution, number of display colors, screen size, etc. The ioctl operation is performed by the underlying driver. Therefore, the framebuffer driver also needs to perform the following tasks: allocate video memory size, initialize LCD control registers, and set/modify the corresponding var and fix information of the hardware device. In μClinux, since the framebuffer device is a character device, the application needs to open a framebuffer device as a file and perform read and write operations on the framebuffer device. The address space of the framebuffer device has been introduced above. For the operating system, reading and writing to the framebuffer device is to read and write data in the physical address space. Therefore, the most important thing in reading and writing to the framebuffer device is to obtain the physical address space of the framebuffer device in memory and some characteristics of the corresponding LCD. Figure 3 reflects the entire process of how the application writes to the framebuffer device to display graphics. After understanding the concepts mentioned above, the actual work of writing the framebuffer driver is not complicated. For this system, the main tasks are as follows: a) Write the initialization function. The initialization function first initializes the LCD controller, sets the display mode and display color number by writing registers, and then allocates the LCD display buffer. In Linux, a contiguous space can be allocated using the kmal-loc function. The LCD display used in this paper is 640×480. Based on the hardware connection between the ARM chip and the TFT controller, its display mode is 16-bit, requiring a display buffer of 640×480×16/8=600 kB. The buffer is typically allocated in a large-capacity off-chip SDRAM, with its starting address stored in the LCD controller register. Finally, an `fb_info` structure is initialized, its member variables are filled, and `register_Framebuffer(&fb_info)` is called to register `fb_info` into the kernel. b) Writing the member functions corresponding to the function pointer `fb_ops` in the `fb_info` structure: For a simple implementation of the embedded system, the following three functions are set to meet the requirements: `struct fb_ops` is defined in `fb.h`. These functions are used to set/get the member variables in the `fb_info` structure. When the application performs ioctl operations on the device file, these functions are called. For example, for `fb_get_fix`, the application passes in the `fb_fix_screen info` structure, assigns values ​​to its member variables within the function, mainly `smem-start` (buffer start address) and `smem-len` (buffer length), and finally returns it to the application. The `fb_set_var` function takes `fb_var_screen info` as its parameter, and assigns values ​​to `xres`, `yfes`, and `bits_per_pixel` within the function. Note that, according to the hardware characteristics of this system, the LCD's 16 bits are (5:6:5), that is: 5 bits for red (bits[11:15]), 6 bits for green (bits[5:10]), and 5 bits for blue (bits[0:4]). In other words, the LCD supports a maximum of 32 shades of red, 64 shades of green, and 32 shades of blue in mixed display. At this point, the display driver development is basically complete. Taking this system as an example, to display a single pixel, the following steps are sufficient: This allows each pixel to be displayed sequentially on the LCD screen, thus displaying the entire image. Figure 4 shows the three English letters "SEU" representing Southeast University displayed on the LCD screen of the established system. "S" is pure red (31, 0, 0), "E" is pure green (0, 63, 0), and "U" is pure blue (0, 0, 31), while the background color is pure white (31, 63, 31). 3 Conclusion Embedded systems are widely used in various fields because they guarantee real-time system response and operational reliability. The image display system designed in this paper can serve as the foundation for applications such as security monitoring, industrial inspection, and remote operation. Development examples demonstrate that embedded Linux systems are not only simple and efficient in image acquisition and processing but also flexible and adaptable in field applications, offering broad development prospects in robot monitoring systems, industrial control image acquisition and positioning, and remote teaching.