Device Driver Development Based on FPGA Embedded System

Abstract: Based on FPGA embedded system, under the Linux2.6 operating system environment of PowerPC architecture, the driver of general-purpose input/output interface (GPIO) controller adopts platform device mechanism for interrupt control management. Through this management mechanism, the resources of the GPIO device itself are registered into the kernel, which is managed by the kernel. Based on the platform device drivers of the Linux 2.6 kernel source, the drivers for the GPIO devices were written and tested. The driver has been validated on the Xilinx FPGA Development Board ML403 and is stable.

Since Linux 2.6 introduced the platform device mechanism, namely the platform device driver mechanism, most device drivers in Linux can use this mechanism [1]. Compared with the traditional device driver mechanism (registered by the driverregister function), the obvious advantage is that the platform mechanism registers the resources of the device itself into the kernel, which is managed by the kernel and is provided by the platform device when these resources are used in the driver. Apply for the standard interface and use [2]. This improves the independence of the driver and resource management, and has better portability and security. The GPIO devices discussed in this article have dual identities: platform devices and miscdevices. The platform device means that the GPIO controller device is a separate module belonging to the platform; the hybrid device (ie, the major device number is 10) is a special character device that describes the access mode of the GPIO controller is sequential [1].

The ML403 development board uses the vertex-4 series FPGA, which integrates the PowerPC405 hard core with a kernel management unit (MMU), so the Linux 2.6 operating system can be run on the development board. In the embedded Linux 2.6 operating system, peripherals are managed through the Platform mechanism. The process of developing a device driver is shown in Figure 1:

In the Linux 2.6 kernel, the platform device is described by the structure platform_device, which is defined in kernel\include\linux\platform_device.h:
Struct platform_device {
Const char * name; //device name of the platform device
U32 id; //device ID of the platform device
Struct device dev; //device structure
U32 num_resources; //The number of resources used by the platform device
Struct resource * resource; //resource
};

An important element of the structure is the resource, which stores the most important device resource information. When the BSP (Board Support Package) is generated in the embedded development tool EDK, there is a device parameter header file xparameter.h, which defines the number of devices, address resources, interrupt resources, and clock resources of the related devices. The address information and interrupt information defined in the header file are required when adding platform device information. The Xilinx Virtex-4 platform device is defined in kernel/arch/ppc/syslib/virtex_devices.c before writing the driver. , you need to add a device definition for the GPIO controller to this file:
/*
* ML300/ML403 Gpio Device: shortcut macro for single instance
*/
#define XPAR_GPIO(num) { \
.name = "xilinx_gpio", \
.id = num, \
.dev.platform_data=XPAR_GPIO_##num##
_IS_DUAL, \
.num_resources = 2, \
.resource = (struct resource[]) { \
{ \
.start=XPAR_GPIO_##num##_B
ASEADDR, \

.end=XPAR_GPIO_##num##_HI
GHADDR, \
.flags = IORESOURCE_MEM, \
}, \
{ \
.start=XPAR_INTC_0_GPIO_##n
Um##_VEC_ID, \
.flags = IORESOURCE_IRQ, \
}, \
}, \
}
/* GPIO instances */
#if defined(XPAR_GPIO_0_BASEADDR)
XPAR_GPIO(0),
#endif
#if defined(XPAR_GPIO_1_BASEADDR)
XPAR_GPIO(1),
#endif
#if defined(XPAR_GPIO_2_BASEADDR)
XPAR_GPIO(2),
#endif

The above code defines the GPIO device name - xilinx_gpio, the name element in the XPAR_GPIO platform device structure and the driver.name in the device driver's platform_driver structure must be the same. This is because when the platform device driver registers, the name in all registered platform_devices is compared with the driver.name of the currently registered platform_driver, so that platfrom_device and platform_driver are associated, and only platfomr_device with the same name can be registered successfully. In the description of the platform device, the GPIO device defines 2 resources, one is the I/O space resource, describes the bus address range occupied by the GPIO controller device, and IORESOURCE_MEM indicates that the first group describes the resource information of the memory type; One is the interrupt resource, which describes the interrupt number of the device. IORESOURCE_IRQ indicates that the second group describes the interrupt resource information, and the device driver obtains the corresponding resource information according to the type. This document shares three GPIO devices XPAR_GPIO(0), XPAR_GPIO(1), XPAR_GPIO(2).

The platform_device in virtex_devices.c is registered with the virtex_init(void) function at system startup.

At the same time, there are many devices on the virtex platform. This function is called during the system initialization phase. The driver registration needs to match all registered device names in the kernel. Therefore, the registration process of the platform_device device must be called before the corresponding device driver is loaded.

Cast Iron LV 3PH Asynchronous Motor

Cast Iron Lv 3Ph Asynchronous Motor,Three Phase Asynchronous Cast Iron Motors,Cast Iron Motors,Cast Iron Electric Motor

Yizheng Beide Material Co., Ltd. , https://www.beidevendor.com