Development of SD Card Driver Based on zylonite hardware platform under CE

Abstract:This paper analyzes and studies the underlying Driver (SD card) architecture of Windows ce5.0 embedded system based on the actual project (a GSM/PHS dual-mode smartphone with Wince as the operating system kernel, based on the BSP provided by Marvell Based on the intel zylonite hardware platform, the SD card driver code suitable for actual projects is developed using the Windows ce5.0 platform Builder integrated development environment (IDE, the dynamic loading of the driver is realized in polling and interrupt modes, and the detailed loading process of the SD card driver (streaming driver) is analyzed in depth.
Keywords: Zylonite platform builder bsp sd card driver

0Introduction

With the increasing demand for new business in the communication field and the rapid development of computer technology, semiconductor technology and electronic technology, the emergence of embedded systems has penetrated into all aspects of social life. It is a high-reliability system integrating software and hardware. The biggest feature is that the functions required by the entire platform can be configured by cutting the loading and unloading system module.

Windows CE is an embedded operating system developed by Microsoft. It has strong compatibility with programming interfaces on Windows. Its platform development tool platform
Builder is a fully integrated development environment (IDE ). Hardware development kit intel zylonite involved in this project
Development system is equipped with Intel's XScale Chip Processor monahans
L (pxa300), with related peripheral circuit interfaces (USB2.0, SD/MMC, audio, Ethernet ports, etc.) and peripherals (touch screen, keypad, speaker, receiver, microphone, etc ). Its unique structure optimization capability ensures that the operating environment and general application devices can quickly process tasks at high frequencies and times.

 

1,WinCESD card drive Architecture

Components of the SD card driver protocol stack under wince:

U host hardware underlying part (master controller driver) sdhc_xxx.dll

Ubus intermediate logic command layer (bus driver) s6. DLL

U client upper layer (client driver) sdmemory. dll

 

1.1. master controller drive

 

The driver control on the master control end includes the master controller hardware and follows the driver interface on the master control end. It is used to drive bus communication and set operation parameters. The main controller driver interface provides a hardware extraction layer between the bus and the main control side. That is: sdhc_xxx.dll is the underlying layer. Because this layer is the hardware Association layer, XXX is called for the specific hardware BSP package (for example, the hardware platform of this project is zylonite, the BSP package name provided by its hardware supplier is zylonite. In actual projects, we replace sdhc_xxx.dll with sdhc_zylonite.dll. It is responsible for issuing specific commands and needs to be modified in most cases.

1.2. Bus drive

The bus driver acts as the extract and the management layer is between the master control driver and the client driver. It is included in the ssag. dll file. Provides a standard API for the client driver to run on any Windows CE-based device. The bus driver will be independent of the application and the master controller. It will be transplanted between different processors and does not need to be changed. Ssung. dll is an intermediate layer responsible for integrating commands and management.

1.3 client driver

The interface between the client driver and the SD client driver allows the client driver to communicate with the SD device. The client-side Driver Interface abstracts the execution of SD bus physical devices in a planned manner and provides maximum elasticity of the client driver. The client driver interface allows the client driver to measure a single, synchronous access to the memory card driver using a thread, asynchronous communication device driver. Sdmemory. dll is the highest level, similar to the application layer.

 

2. Develop zylonite BSP package SD Card Driver Based on Microsoft SD card protocol stack

When we develop the SD card driver and analyze and compare the SD driver architecture of Microsoft and the BSP reference SD card driver provided by Intel, we can draw the following conclusions:

L driver for the master control end (sdhc_xxx.dll): Because this layer directly operates the hardware layer, it needs to be modified in most cases. The modified content includes the sending and receiving commands and data transmission and hardware initialization.

L for the bus drive (sdbus. DLL): Because this layer is between the master control driver and the client driver for communication between them, the SD card bus requests are placed in it. Microsoft provides a very complete sample code, therefore, we generally do not need to change it. You can directly call its interface.

L sdmemory. DLL): Because sdmemory is the so-called Client layer, similar to the application layer, it can also be used to identify cards, different types of cards, such as SD memory card, because we only need to develop drivers for the SD card, so there is no need to modify it. (If I want to develop the sdio device of the SD interface, I have to make a big change on this layer ).

Based on the SD card driver in the BSP provided by Intel, the main controller driver (sdhc_zylonite.dll) is implemented, while the sbus driver is called and retained. DLL) and the client Driver (sdmemory. DLL ). Therefore, in combination with the specific hardware design (SD card ctor, etc.), our main task is to develop (configure and improve) the driver code of the SD card master control end in BSP) SD card driver in our actual project.

2.1 Overview of the SD card master controller driver in zylonite BSP

The driver of the SD card is provided in the form of a stream, and the main controller of the SD card is provided in the form of sdhc_zylonite.dll. The entry is:\ Wince500 \ platform \ zylonite \ public \ CSP \ monahans \ sdhc

There are two files:

L sdcontrol. C: contains a very important thread-sdcontrolleristhandler,

It is mainly responsible for card-to-controller interaction and processing of messages received by the Controller. The specific control and processing functions are in this file.

L The export stream interface of Main. C: SDH (master controller driver) is implemented in this file, and

Contains the entry point of the (sdhc_zylonite.dll) driver with the master controller.

The path of the SD card hardware initialization and the Registry Information of the master controller driver is as follows:

 \ Wince500 \ platform \ zylonite \ SRC \ drivers \ sdhc

The main files are:

L impl. C: hardware is initialized when the SD card master controller driver is loaded. Contains a non-

An important thread is sdcarddetectistthread, which is used to handle the plugging operation of the SD card. But the specific plugging operation is also implemented in the sdcontrol. c file.

2.2. development process based on actual projects

2.2.1 external pin and function configuration of the SD card

In the actual project (a GSM/PHS dual-mode smartphone with Wince as the operating system kernel), the external pin of the SD card is connected to the gpio of monahans_l and the circuit diagram of the connection controller is as follows:

 

First, you must configure the external pins and functions of the SD card. The SD card pin is configured under\ SourceFolderXllp_mmc_board.cFileXllpmmcconfigureFunction. (Note: gpio34 should be configured with an interrupt source for detecting SD card insertion .)

2.2.2 analyze and modify and improve the Code of important threads and hardware initialization of the master controller.

LDriver loading and Architecture Analysis on SD card master controller

The SD card driver loading sequence must be declared as follows:

Load sdbus. dll → load sdhc_zylonite.dll → load sdmemory. dll

Here we will only discuss in detail step 1 (loading sdhc_zylonite.dll). At this time, sstrap. dll has been loaded successfully. After the wince system is initialized, the device is loaded. EXE, corresponding code devload. the winmain function in C is called to start the initdevice function. This function searches for sdhc_zylonite.reg under \ wince500 \ platform \ zylonite \ platite \ SRC \ drivers \ sdhc) the Registry Root Key, prepare a parameter to call the Win32 API ----- activedevice, then use the dllmaincrtstartup function to find the sdhc_zylonite.dll entry, execute the file entry function dllmain (), and continue to return to the device. EXE (devload. c), call the launchdevice () function, and then call the main entry of sdhc_zylonite.dll. the sdh_init () in the C file will start the initialization process of the SD card master controller driver:

1. Call sdh_init ()

2. Call sdhcdallocatecontext () to allocate the context of a master controller.

A) context is shared by bus drivers and master controllers.

3. The main controller driver uses the sdhcdsetxxx macro to fill in the context structure.

A) This step describes the master controller to the bus driver.

B) Includes function pointers, supported current, maximum clock, number of slots, and sdio support.

4. Call sdhcdregisterhostcontroller () to register yourself with the bus driver.

5. When the bus driver is ready to process the SD event, it will call the init function (pcontext-> pinithandler) of the master controller)

The code of the sdbus. DLL driver and the interaction settings of the driver on the SD card master control side, such as setting the power supply, clock, and bus width. Generally, the request is initiated by sdbus. dll, and then the API of the main controller driver is called. Here, the slot status interaction is analyzed in detail to confirm, because this is the key to successfully loading sdhc_zylonite.dll. When there is an SD card in the slot, ssung. DLL's slotstatuschange () call and establish an important thread sdcarddetectistthread (). When a card is detected, it is returned to ssung. DLL, the bus driver can call the handleadddevice () function. After initialization, sdhc_zylonite.dll is loaded successfully.

LImprovements to sdcarddetectistthread () code for driving important threads on the master control end

In the previous description, we can see that the thread sdcarddetectistthread () plays a decisive role in the final loading of sdhc_zylonite.dll. However, we found that in the BSP provided by Intel, in the process of detecting the card, it adopts the round-robin method-that is, the CPU reads the gpio34 level once every certain time, to determine whether the SD card is inserted or pulled out, to determine whether to load or uninstall the SD card client and the main control driver. Obviously, the disadvantage of this method is that it occupies too many CPU resources and is very inefficient, seriously affecting the real-time performance of the entire system. Therefore, the most effective way to solve this problem is to use interrupt detection. The following describes how to implement the interrupt mechanism in two different ways:

1. Interrupt static binding Configuration:

1. Define a system interrupt number in the bsp_cfg.h file sysintr_sdmmc_detect

# Define sysintr_sdmmc_detect (sysintr_firmware + n) n is the defined maximum value (to ensure that this interrupt has not been used ).

2. Find the gpio34 definition in the xllp_gpio_plat.h file: # define xllp_gpio_mmc_cd_0 34

3. Associate the system interrupt number with irq in the Intr. c file:

Oalintrstatictranslate (sysintr_sdmmc_detect, irq_gpio_share (xllp_gpio_mmc_cd_0 ));

4. Add the initializehardware () in the hardware initialization code impl. C to the enablesdcardinterrupt () function.

5. Improve enablesdcardinterrupt () in impl. C, and add the gpio rising or falling edge detection and set event.

6. Define hcardinsertinterruptevent in the impl. c file and create hcardinsertinterruptevent in setupcarddetectist ().

7. initialize dwsysintrcd = sysintr_sdmmc_detect in the impl. c file and bind the corresponding event: interruptinitialize (dwsysintrcd, hcardinsertinterruptevent, null, 0)

8. Improve the while part of the code of the thread sdcarddetectistthread () and add waitforsingleobject (hcardinsertinterruptevent, dwtimeout). Only when the cursor is set, it will go down. Otherwise, it will wait here.

9. Rewrite cardremoveinterrupt in the same principle as above to dynamically uninstall the SD card master controller driver.

2. Interrupt binding dynamic configuration:

1. in impl. the setupcarddetectist () function of the C file dynamically configures the system interrupt number and hardware interrupt source: kerneliocontrol (kernel, & dwsdcdirq, sizeof (DWORD), & (dwsysintrcd), sizeof (DWORD ), null )). You can use the loadplatformregistrysettings function to load & dwsdcdirq in the registry of the SD card master controller driver. The value of "carddetectirq" can be changed to "irq_gpio_share_base + X-2" in the sdhc_zylonite.reg file on the platform, irq_gpio_share_base = 52, x = 34.

2. Connect 5-6-7-8-9.