Analysis Solution of 16/32-bit RISC Embedded CPU Based on ARM920T Core

    1 Introduction

    In today's post-PC era, embedded systems are increasingly used, and embedded products are flooding many fields. Mobile phones, MP4s, PDAs, etc. in daily life are all typical embedded systems. In embedded systems, microprocessors and operating systems are the basis for application development. In terms of microprocessors, S3C2410 is a 16/32-bit RISC embedded CPU based on the ARM920T core launched by Samsung, mainly for handheld devices and cost-effective, low-power applications. In terms of operating systems, Windows CE 5.0 is an embedded operating system provided by Microsoft. Based on Windows CE 4.2, it has added some new features to meet market demand. Board Support Package (BSP) is a component of the operating system that provides support for hardware. The development of BSP accounts for a large proportion of the entire product development time. Rapid transplantation of BSP that meets product requirements is very important in the highly competitive market environment. There are many research reports on S3C2410, Windows CE and BSP. Reference [1] studies the GPS communication technology and implementation based on S3C2410. Reference [2] analyzes the structure of Windows CE in detail. Reference [3] summarizes the customization and tailoring methods of Windows CE 4.2 dedicated operating system. Reference [4] discusses the development of board support package for DSP embedded multimedia application system. Currently, Windows CE applications mainly use Windows CE 4.2 and below. This paper studies the Windows CE 5.0 BSP transplantation technology based on S3C2410.

    2 Analysis of Windows CE 5.0 and BSP Structure

    To transplant Windows CE 5.0 BSP based on S3C2410, it is necessary to analyze Windows CE 5.0 and BSP structure. Windows CE 5.0 is an open, scalable 32-bit embedded operating system with high reliability. It is a hard real-time embedded operating system that can run on multiple processor architectures (such as x86, MIPS, ARM and SH4). Windows CE supports ARM architecture, which is a prerequisite for BSP transplantation based on S3C2410 processor. Windows CE 5.0 BSP usually contains the following parts: Bootloader, OAL (OEM adaptation layer), device driver, configuration file, etc.

    BootLoader is a program that runs when the power is turned on. It initializes the hardware, establishes the system's memory space mapping, and prepares for the final call to the system kernel. In Windows CE 5.0 system, it is mainly used to download and start the image nk.bin, that is, there are two working modes: boot loading mode: the product that the user finally uses is in this mode; download mode: the image is first downloaded to the RAM of the target machine by the bootloader, and then solidified to the Flash.

    Device drivers can be divided into native drivers and stream interface drivers according to the exported interfaces. Native drivers include mouse , keyboard, touch screen, display driver, etc. loaded by GEWS.exe. Stream interface drivers are implemented using a set of stream functions and are usually loaded by Dev IC e.exe, such as network card, sound card, USB, etc.

    OAL is a code layer that logically resides between the Windows CE kernel and the target device. Physically, OAL is connected to the kernel library to generate the kernel executable file. OAL simplifies the communication between the operating system and the target code. OAL code is used to handle interrupts, timers, power management, general I/O control, etc. [5].

    The Configuration File contains configuration information related to the generated image.

    To transplant the BSP corresponding to S3C2410 under Windows CE is to modify the BSP that comes with Windows CE or modify several major components of the previous version of the BSP of the hardware platform so that the BSP can effectively support the hardware system.

    3 BSP transplantation

    If you develop a Widows CE 5.0 BSP from scratch, it will take quite a long time. The usual practice is: (1) port your own hardware platform based on Windows CE 4.2 and earlier versions of the BSP to the Windows CE 5.0 system; (2) find the Windows CE 5.0 BSP that is closest to the hardware platform as a template, and then make corresponding modifications based on your own hardware platform to obtain a BSP that can be used on your own system. The BSP porting discussed in this article belongs to the first case.

    The transplantation platform used this time is the EdukitIII experimental box of Shenzhen Embest Company, with S3C2410 microprocessor, 64M NAND Flash chip and other related hardware resources. Software resources include: edukit2410 package (BSP under Windows CE 4.2 version).

    3.1 Bootloader transplantation

    The execution flow of the bootloader is as follows:

    (1) Execute startup.s: perform some basic initialization of the CPU, memory controller, cache, etc.

    (2) Initialize the serial port: call the function OEMI nitDebugSerial () to complete.

    (3) Initialize the platform: Call the OEMPlatformInit() function to initialize the required hardware resources, which usually include: Ethernet controller (CS8900A), system clock, storage device, and some other peripheral devices.

    (4) Call the OEMPreDownload() function to do some preparatory work such as obtaining the IP address and initializing the TFTP connection.

    (5) Execute the function DownloadImage(): download the image to SDRAM.

    (6) Call OEMLaunch() function to start the operating image.

    Among them, startup.s and OEMInitDebugSerial() can be shared with OAL. The modification of the two functions is described in the OAL porting process.

    The main process of Bootloader transplantation is:

    (1) Modify the corresponding dir and source files. Some library paths are listed below:

    TARGETLIBS=

    $(_TARGETPLATROOT)lib$(_CPUINDPATH) CSP _arm.lib

    $(_COMMONOAKROOT)lib$(_CPUDEPPATH)eboot.lib

    $(_COMMONOAKROOT)lib$(_CPUINDPATH)cs8900dbg.lib

    The csp_arm.lib library only exists in $(_PUBLICOAKROOT) of Windows CE 4.2. It is one of the ARM architecture link libraries. It is located in the PUBLIC directory under Windows CE 4.2 system, and in PLATFORM under Windows CE 5.0 system. As a result, the compilation system cannot find the library file. Therefore, modify the link path of this library so that the Platform builder compilation system can find this link library.

    (2) Modify makefile.inc, because this file specifies the files needed to generate eboot.bin (Ethernet bootloader image) and copy eboot.bin to the releasedir directory, where:

    romimage $(_TARGETPLATROOT)eboot oot.bib

    To generate the configuration file required to generate eboot.bin, otherwise, the system cannot generate eboot.bin after compilation.

    (3) Modify boot.bib so that it does not conflict with the memory allocation in config.bib.

    (4) Improve eboot, because when eboot burns NK.BIN (OS image), it will search for BINFS partition and then burn the downloaded image to BINFS partition. If no existing BINFS partition is found, eboot will low-level format NAND FLASH and create MBR (main boot record), which contains partition table. Currently, up to 4 partitions are supported, and the size of the BINFS partition is aligned with the size of NK.BIN expanded by b LOC k, so there will be a problem. When the modified and regenerated NK.BIN is larger than the IMAGE written into NAND FLASH before and exceeds the block alignment, it will cause the failure of burning the new NK.BIN. We can solve this problem by formatting NAND FLASH before downloading and burning NK.BIN each time, but it is obviously not a proper solution and increases the complexity of user use. Therefore, we can fix the size of the BINFS partition, and this fixed size can refer to the ROMSIZE defined in the config.bib that generates NK.BIN. In this way, no matter how NK is modified, BINFS does not need to be changed once it is created. After eboot writes NK into NAND FLASH, it will create a FAT partition with the remaining FREE space. If we want to implement HIVE REGISTRY, we can mount this partition as MountAsBootable.

    3.2 OAL transplantation

    During the OAL porting process, OEM mainly implements the following functions: Startup.s, debug serial port function, OEMInit function, system clock function, interrupt processing function, etc.

    (1) Modify Startup.s. This function is the first function to be called when the OS starts. It is also one of the important functions that the OEM needs to implement. Its main functions are: initializing the CPU to a known state; and calling the kernel initialization function kernelstart. Startup.s needs to be modified. The modified part of the code is as follows:

    …

    ldr r0, = 0X4A000008

    ldr r1, = 0xffffffff ; Disable all interrupts

    str r1, [r0]

    ldr r0, = 0X4A00001C

    ldr r1, = 0x7ff ; Disable all sub-interrupts

    str r1, [r0]

    ……..

    add r0, pc, #g_oalAddressTable - (. + 8)

    bl KernelStart //Jump to KernelStart

    (2) Modify the serial port debugging function. After executing Startup.s, the system jumps to the Kernelstart function, which is located in the private directory. The first task of this function is to initialize the serial debugging port. Otherwise, the subsequent debugging work cannot be performed. Among them, OEMReadDebugByte, OEMWriteDebugByte, and OEMWriteDebugString do not need to be modified. It should be noted that OEMInitDebugSerial selects UART 0. The register configuration of UART1 is different. If UART0 is selected, use the configuration:

    s2410IOP->rGPHCON &= ~((3 << 4) | (3 << 6));

    s2410IOP->rGPHCON |= ((2 << 4) | (2 << 6));

    If UART1 is selected, the configuration used is:

    s2410IOP->rGPHCON &= ~((3 << 8) | (3 << 10));

    s2410IOP->rGPHCON |= ((2 << 8) | (2 <<10));

    (3) Implement OEMInit(), which will call the following functions: OALCacheGlobalsInit(), OALIntrInit(), OALTimerInit(), OALKitlStart() to initialize Cache Global, interrupt, clock, and start KITL. The implementation code is as follows:

    void OEMInit()

    {

    OALCacheGlobalsInit(); // Initialize cache globals

    if (!OALIntrInit()) {

    OALMSG(OAL_ERROR, (

    L"ERROR: OEMInit: fai LED  to initialize interrupts "

    ));

    } // Initialization interrupt

    OALTimerInit(1, S3C2410X_PCLK/2000, 0); // Initialize the clock

    OALKitlStart(); // Initialize KITL

    }

    (4) Implement OALTimerInit(), which is used to initialize OS TIMER and set a system tick to be generated every millisecond to count the system and trigger process scheduling. It is determined by the CPU's operating frequency and hardware timer resources. The execution process includes: initializing the clock state global variable, initializing the high-resolution clock function pointer, and enabling TIMER.

    (5) Implement the interrupt processing function: OALIntrInit(). This function usually initializes the interrupt mapping table first, because WINCE maps the platform-related physical interrupt number and the system interrupt number for modularization. Then clear external interrupts, internal interrupts, etc.

    3.3 Driver Porting

    Taking the touch screen as an example, we will discuss the transplantation of Windows CE 5.0 system driver. Here, the touch screen interface of Samsung's ARM9 core chip S3C2410 is used as the basis, and the hardware foundation is formed by an external 4-wire resistive touch screen. The entire touch screen consists of horizontal resistance wires and vertical resistance wires. The main functions of the touch screen driver are:

    TSP_Poweron This function will perform some initialization of the touch screen, mainly the configuration of registers.

    DdsiTouchPanelEnable: Enable the DDSI interface so that the hardware can provide stream data to the DDSI interface, and touch operations can be implemented.

    DdsiTouchPanelSetMode: mode setting function, set the touch screen to high sampling rate or low sampling rate

    DdsiTouchPanelGetPoint: Touch screen sampling function

    TSP_CalibrationPointGet: coordinate conversion function, which converts AD samples into coordinates.

    The main process of transplantation:

    (1) Modify the source file and add the following library files:

    TARGETLIBS=$(_COMMONSDKROOT)lib$(_CPUINDPATH)coredll.lib

    SOURCELIBS=

    $(_COMMONOAKROOT)lib$(_CPUINDPATH) ch_cal.lib

    $(_COMMONOAKROOT)lib$(_CPUINDPATH) chmdd.lib

    Because this driver is in the Public directory under Windows CE 4.2, and here the touch screen is moved under Platform, there are no three link libraries under Windows CE4.2, but the Platform and Public compilation paths and prerequisites are different. Therefore, the referenced libraries are different.

    (2) Delete the following library files:

    $(_TARGETPLATROOT)lib$(_CPUINDPATH)drvlib.lib

    This library is a shared library for touch screen and audio under Windows CE 4.2 system, but under Windows CE5.0 system, this library is no longer necessary and no longer exists, so delete it, otherwise the system will have a compilation error.

    (3) Modify platform.bib and include the ported driver dll into nk.bin

    (4) Modify platform.reg, where CalibrationData is a parameter of the touch screen:

    [HKEY_LOCAL_MACHINEHARDWAREDEVICEMAPTOUCH]

    "MaxCalError"=dword:7

    portrait

    "CalibrationData"="517,610 897,934 142,936 129,290 891,285 "

    The process for other drivers is similar to that for the touch screen.

    3.4 Transplantation Summary

    This migration is to upgrade the BSP, and the hardware is basically unchanged, so many codes can be used without modification. Through the above migration, it is not difficult to find that the work to be done in this type of BSP migration process is mainly in the following aspects:

    (1) Modify the dir file. The dir file specifies which folders in the current directory are compiled by the system. The compiler searches layer by layer according to the dir file. Migrating the BSP inevitably brings about changes in the directory. The new compilation path is specified by modifying the dir file.

    (2) Modify the sources file. In the sources file, the compilation types are specified as PLATFORM and OAK. The libraries sourcelib and targetlib referenced during compilation are different. You must pay attention to this when porting. The target file types are Library, Dynlink, and program. The include field contains the header file directory required for compilation. There is a special source, sources.cmn, under Platform (for example, SMD k2410). It contains the common library and header file path of the platform. This file needs to be modified during the porting process, otherwise, the compilation will fail.

    (3) Modify platform.bib, platform.reg and other files, because these two files determine which modules (dll) are included in the image and registry-related information. During the driver transplantation process, each module change requires modifying these two configuration files.

    (4) Modification of header files, functions, and variables in the driver source file, etc., which are determined based on the errors that occur during compilation.

    In addition, the following points should be paid special attention to when transplanting each part:

    Bootloader part: Because the process of bootloader downloading, burning, and starting the image will involve memory address issues, various entry addresses cannot be wrong, and memory out of range and conflicts need to be handled with special care. Especially the g_oalAddressTable table, which defines the conversion between physical addresses and virtual addresses and the size of memory. If it is not set correctly, there will be errors such as verification errors, download failures, or image startup failures.

    OAL part: Special attention should be paid to the two functions of startup.s and OEMInitDebugSerial, which are mainly used to initialize the hardware and serial port, which is the basis for system operation and driver debugging. If the hardware configuration and debug serial port are changed, appropriate modifications are required. In this BSP transplantation, since the hardware platform has not changed, many codes in the OAL part can be used without modification.

    Driver part: The structure and library of Windows CE4.2 and Windows CE5.0 have changed a lot, so it is necessary to modify the reference library path and the reference path of the header file. Most drivers will encounter such problems.

    4 Conclusion

    The innovation of this article: Through the analysis of BSP structure, the Windows CE 4.2 BSP of a specific platform is ported to the Windows CE 5.0 version, including the porting of bootloader, OAL, and driver, so that it can be compiled and generated into an image and can run successfully on the platform. Through this porting, the author realized that BSP porting is a very complicated and tedious process. Because the organizational structure of Windows CE 5.0 and Windows CE 4.2 BSP packages is different, many link libraries cannot be found or these libraries have been replaced or deleted. Only by patiently locating them according to these error prompts, sometimes you also need to find the answer in the makefile. However, porting BSP saves more development time than redeveloping BSP, thereby shortening product development.