Abstract: The RTL8019AS Ethernet controller has been widely used in embedded systems due to its excellent performance, while μcLinux enables communication and data exchange. Experiments show that using the HPI interface for communication between C5416 and S3C4510B meets the real-time requirements of embedded systems. Keywords: S3C44B0X + μcLinux, Embedded Ethernet Memory Management Unit Introduction With the rapid development of semiconductor technology, embedded products have been widely used in various fields such as military, consumer electronics, network communication, and industrial control. Networking is an inevitable trend in the development of embedded systems. Embedded Linux, as an operating system with many advantages such as open source code, excellent network performance, and customizability, is very suitable for embedded systems with network functions. This paper introduces the network interface design based on the S3C44B0X ARM processor and RTL8019AS Ethernet controller, and explains how to implement the network card driver under the embedded operating system μcLinux. I. Introduction to the S3C44B0X Processor ARM is a well-known chip design IP supplier in the industry, and its 32-bit RISC microprocessors occupy more than 80% of the global market share. The ARM7 series processors are currently the most mature and widely used processors on the market. The S3C44B0X from Samsung is a 16/32-bit RISC processor based on the ARM7TDMI core. Manufactured using a 0.25μm CMOS process, it provides a cost-effective and high-performance microprocessor solution for handheld devices and general applications. The S3C44B0X significantly reduces the number of peripheral components by providing comprehensive and universal on-chip peripherals, thereby greatly reducing system costs. The internal structure of the S3C44B0X chip is shown in Figure 1. II. Network Interface Circuit Design Before introducing the circuit design, let's briefly introduce the network controller RTL8019AS. The RTL8019AS is a cost-effective, plug-and-play full-duplex Ethernet controller manufactured by REALTEK in Taiwan. It integrates two RAMs: a 16KB RAM (addresses 0x4000～0x7FFF) and a 32-byte RAM (addresses 0x0000～0x001F). 16K of RAM is used as a buffer for transmitting and receiving data. Generally, 0x4000~0x46FF is used as the transmit buffer, and 0x4700~0x7FFF is used as the receive buffer. Figure 2 shows the Ethernet interface circuit designed for S3C44B0X using RTL8019AS, 74LV138 (3-to-8 decoder), and FB2022 (network card transformer). The circuit has a data width of 16 bits and uses the external interrupt EXINT3. The processor's chip select signals nGCS1 and A16, A17, and A18 are output through 74LV138 as the network card enable control terminals. nOE and nWE control the network card's read and write operations, nRESET controls the network card's reset, and FB2022 acts as a transformer filter. III. Introduction to μcLinux Operating System and Network Driver Development 1. Why was μcLinux chosen for this system ? Linux has become one of the most popular operating systems today due to its open source code, powerful network functions, and many other advantages. μcLinux is derived from the Linux kernel, inheriting most of Linux's features. It is specifically designed for CPUs without an MMU (Memory Management Unit) and has undergone significant miniaturization for embedded systems. Its kernel is small yet powerful, the system is robust, and it offers broad hardware support, making it an excellent embedded operating system. The S3C44B0X is a processor without an MMU, making μcLinux a very suitable operating system choice for this system. 2. Introduction to Network Driver Development under μcLinux The implementation process of drivers in μcLinux is basically the same as in Linux. Linux treats all devices as specific files, accessing them through the file system layer. Therefore, in the Linux/uclinux framework, device-related processing can be divided into two layers—the file system layer and the device driver layer. The device driver layer hides the details of specific devices, while the file system layer provides users with a unified and standardized user interface. This device management method effectively achieves "device independence," allowing Linux/uclinux to be easily extended according to the development of hardware peripherals. For example, to implement a device driver, one only needs to provide a set of access interfaces to the file system based on the specific hardware characteristics. The structure of the entire device management subsystem is shown in Figure 3. In Linux/μclinux, the entire network interface driver framework can be divided into four layers, from top to bottom: the protocol interface layer, the network device interface layer, the device driver function layer providing the actual functionality, and the network device and network media layer. This framework is already built in the kernel network module. When designing a network driver, our main task is to implement the device driver functionality based on the net_device structure defined in the upper-layer network device interface layer and the specific hardware characteristics at the lower level. The network driver mainly consists of two data structures: one is sk_buff, which is used for data packet transmission between different protocol layers in TCP/IP and between the network driver and the protocol layer. This structure mainly includes variables needed by the transport layer, network layer, and connection layer, pointers determining the location and size of the data area, and specific device information used for sending and receiving data packets. Its detailed definition can be found in the kernel source code. The other is the net_device structure, which is defined in [the kernel source code]. This structure is the core of the network driver. It defines many standard device methods for system access and protocol layer calls, including the `init` function for device initialization and system registration, the `open` and `stop` functions for opening and closing the network device, the `hard_start_xmit` function for handling packet transmission, interrupt handling functions, and interface status statistics functions. 3. Implementation of the RTL8019AS Driver In embedded system development, writing device drivers can be very time-consuming. The following details the steps involved in designing the network card driver for this system. * Initialization function `static int RTL8019_init(struct net_device *dev)` { Calls the `ether_setup(dev)` function to set up the general Ethernet interface; populates the attribute fields of the `net_device` data structure; calls `kmalloc` to allocate the required memory space; manually sets the MAC address; } * Device open and close function `static int RTL8019_open(struct net_device *dev)` { Disables interrupts; registers the interrupt number and I/O address; initializes the device registers; enables interrupts; } The device close function performs the opposite action of the open function. * **Packet Sending Function:** `static int RTL8019_sendpacket(struct sk_buff *skb, struct net_device *dev)` { Enables the `tbusy` flag; Writes the packet to the RTL8019's send buffer, enabling DMA send; Releases the buffer; } * **Packet Receiving Function:** `static int RTL8019_rx(int ​​irq, void *dev_id, struct pt_regs *regs)` { Allocates the `skb` buffer to store the new packet; Reads the newly arrived data from the hardware; Calls the function `netif_rx()` to send the new packet to the next layer of the network protocol; } Finally, the driver is compiled into the kernel. Since μcLinux does not support dynamic module loading, static compilation must be used. If everything is normal, the network card will work properly after setting the IP address and subnet mask using the `ifconfig` and `route add` commands. IV. Conclusion The RTL8019AS Ethernet controller has been widely used in embedded systems due to its excellent performance, and μcLinux supports communication and data exchange. Experiments show that using the HPI interface for communication between the C5416 and S3C4510B meets the real-time requirements of embedded systems.