Transplantation of Embedded Real-time Operating System ECOS on S3C2510

Introduction

       ECOS (Embedded Configurable Operating System) is a portable embedded real-time operating system for 16-bit, 32-bit and 64-bit processors. As its source code is open, more and more designers are beginning to pay attention to the ECOS operating system. The biggest feature of ECOS is modularity and configurable kernel. The smallest version of ECOS is only a few hundred bytes, which is very suitable for the development of small embedded systems. Compared with embedded Linux, ECOS has the advantages of flexible configuration and resource saving. Another advantage is that it uses a multi-task preemption mechanism, has minimal interrupt latency, supports all synchronization primitives required by embedded systems, and has flexible scheduling strategies and interrupt handling mechanisms, so it has good real-time performance. Compared with operating systems such as Clinux and COS, ECOS is more suitable for the development of equipment that processes real-time signals, such as mobile communications, WLAN and other communication equipment.

       S3C2510 is a low-power, high-performance microprocessor for Ethernet systems. Its system clock can reach 13 3MHz, and it includes a 16/32-bit wide ARM940T core, 4KB I-CACHE and 4KB D-CACHE. S3C2510 has two independent 10/100Mbps Ethernet controllers. These two interfaces can complete the IEEE802.3 MAC layer processing in hardware, so it is more suitable for the development of SOHO routers, internet gateways, and even broadband wireless access devices. ECOS operating system is also very suitable for the development of these network devices. This article will introduce the transplantation solution of S3C2510 and provide a systematic example for the development of ECOS bottom-level transplantation for various ARM-based processors.

       Basic knowledge of ECOS bottom-level transplantation

       The main components of the ECOS system are shown in Figure 1. The main functions and characteristics of the operating system are determined by its kernel, and the bottom-level transplantation generally does not involve the content of the system kernel. As shown in Figure 1, the hardware abstraction layer is the basic layer for the embedded operating system to directly contact the hardware. It completely isolates the system kernel from the specific hardware platform, realizing the independence of the system kernel from the hardware. This is the embodiment of the good portability of the operating system. Therefore, for developers, the real meaning and work of transplanting the operating system lies in transplanting the hardware abstraction layer of the operating system.

                                                    Figure 1 ECOS operating system structure diagram The

       hardware abstraction layer HAL abstracts the processor structure and system hardware platform. When ECOS is to be run on a new target platform, only the underlying hardware abstraction layer needs to be modified to quickly port the entire ECOS system to the new platform. The hardware abstraction layer mainly includes three modules: architecture abstraction layer (Architecture HAL), variant abstraction layer (Variant HAL) and platform abstraction layer (Platform HAL). The architecture abstraction layer mainly refers to the processor series with different architectures supported by ECOS, such as ARM series, PowerPC series, MIPS series, etc. The variant abstraction layer refers to the particularity of a processor in the processor series in terms of Cache, MMU and FPU. For example, S3C2510 belongs to ARM940T in the ARM series, and the variant abstraction layer will specifically define the Cache of ARM940T. The platform abstraction layer is an abstraction of the current system hardware platform, including platform startup, chip selection and configuration, timing devices, I/O register access and interrupt registers, etc. The writing of platform abstraction layer code is the focus of ECOS porting.

       The main steps of HAL transplantation are

       to establish appropriate file directories.

       ECOS itself has a complete file directory. Only by placing the newly created underlying files under the appropriate file directory can the configuration and compilation work be successful. It also helps to use the existing source code of ECOS itself, such as many mature and available codes in the architecture layer and variant layer. Since the core of the S3C2510 processor in this system is ARM940T, the directory of S3C2510 can be established under the ECOS library path packages/hal/arm/arm9/. Establish the cdl

       file of S3C2510. The cdl file uses the cdl scripting language to describe the characteristics and common indicators of the hardware device (package or platform). The cdl file implements the function and indicator configuration of the system at the source code level, just like a project management senior registering the characteristics of the components in its warehouse. Only the registered packages, components and options can be recognized and configured by the operating system configuration tool. The following are several important descriptions in the cdl file of S3C2510.

       * cdl_package CYGPKG_ HAL_ARM_ ARM9_S3C2510 This is the name of the package registered in ECOSdb for S3C2510, which contains some basic settings and components of the board, such as the parent architecture (parent), included header files, compiled C files,

  etc.

bsp; * cdl_component CYG_HAL _STARTUP System startup mode, there are 3 options: ram startup, rom startup, romram startup.

       * cdl_component CYGNUM_ HAL_CPUCLOCK Platform system clock setting, so that other ECOS components can use this clock as a standard. The default value of the platform system clock is set to 133MHz.

       * cdl_option CYGNUM_HAL_ RTC_PERIODECOS kernel operating clock unit. The ECOS kernel uses a tick as the clock unit, and the length of a tick is equal to the setting value of this option.

[page]

       Register S3C2510 hardware package in ecos.db

       ecos.db is a database file about ECOS system (under the packages directory), which contains hardware package management tools and some packages in the component configuration library. Compared with cdl files, ecos.db registers the items in the warehouse, while cdl files register the characteristics of each item. Only packages registered in ecos.db can be selected and used by ECOS library compilation tool (configtool). If you want to add optional hardware target boards to the template options (template) of the configuration tool, you need to register its package description in ecos.db first, and then add its target board description. General auxiliary hardware (such as network card, serial port, etc.) only needs the first step of registration. Therefore, the basic steps to register the S3C2510 platform hardware package in ecos.db are to register the package description (package CYGPKG_HAL_ARM_ ARM9_ S3C2510) and target description (target S3C2510) of the hardware platform. It should be noted that the three hardware description packages CYGPKG_HAL_ARM, CYGPKG_HAL_ARM_ARM9 and CYGPKG_HAL_ARM_ARM9_ S3C2510 included in the target S3C2510 are indispensable because they are the core of the target board - the main architecture package, the sub-architecture package and the main chip package. In addition, other auxiliary hardware packages (such as network cards, serial ports, etc.) can be optionally added.

       Write the relevant code of the platform abstraction layer

       The general functions of the code files required to be written in the hardware platform layer are as follows.

       * include /plf_cache.h —— Platform-specific cache processing (optional). It is not necessary to write it in this system, and the hal_cache.h of the ARM9 variant layer can be directly called.

       * include / hal_platform_ints.h —— Platform-specific interrupt processing, defining the platform interrupt vector number.

       * include / plf_io.h —— I/O definition and macro definition of system registers.

       * include ¬/ hal_platform_setup.h —— Platform startup code. This file is mainly written in ARM assembly instructions to realize the startup and execution of the program after the platform is powered on. * src/s3c2510_misc.c —— HAL's underlying standard functions, including clock platform initialization, clock delay function, interrupt enable, interrupt mask, interrupt response, etc.

       * src/ hal_diag.c —— Hardware abstraction layer diagnostic output function, including the hardware device driver printed by printf in the ECOS system.

       * misc/ redboot_primary_ ram.ecm —— Redboot minimum configuration file based on RAM boot mode.

       * misc/redboot_primary_ rom.ecm —— Redboot minimum configuration file based on ROM boot mode.

       Hardware startup process

       Writing the hardware startup initialization process is a difficult point in HAL porting. When the hardware is powered on again, the system's program pointer will automatically point to address 0 (usually address 0 stores the bootloade

r code segment). In the ECOS operating system, the program will first run the vectors.S file (this file exists in the hal/arm/arch/src/ directory), which defines various startup labels such as reset_vector and start. Then call the macro platform_setup1 in the hal_platform_ setup.h file of the S3C2510 platform layer and the function hal_hardware_init in the arm9_misc.c file of the arm9 variant layer. hal_platform_setup.h defines the macro platform_setup1 for vectors.S to call. This macro defines the initialization startup of SDRAM and FLASH on the target board, including their data access method and memory size. Then execute the program according to different startup methods. For the RAM startup method, there is no need to move the program segment and the data segment, and the system has assumed that the starting address of the SDRAM is the starting address of the program; for the ROM startup method, the data segment needs to be moved, but the program segment does not need to be moved; for the ROMRAM startup method, both the program segment and the data segment need to be moved, and then the program starting address is mapped to the starting address of the SDRAM. After the program is moved, the system will initialize other hardware, including basic hardware devices such as system clock, system cache, and monitoring serial port. The memory layout file of

       the memory layout file writing

       platform is in the include/pkgconf directory. Usually, each platform includes a set of memory layout files for three different startup modes: RAM, ROM, and ROMRAM. The memory layout file set for each startup mode consists of three types of description files: .h files contain C macro definitions of memory domains; .ldi files define link script files for memory domains and memory segment locations; and .mlt files include descriptions of memory layouts generated by the MLT tool. When the memory layout needs to be modified manually, only .h and .ldi files can be modified, and .mlt files can only be generated by the MLT tool.

       Taking the RAM startup mode memory layout of S3C2510 as an example, the program structure of mlt_arm_s3c2510_ram.h and mlt_arm_s3c2510_ram.ldi is mainly explained. Since the S3C2510 development board has two 16MB SDRAMs, two memory domains ram1 and ram2 need to be defined. The system setting register has remapped the memory segments during initialization, so the base addresses of the two SDRAMs are 0x0 and 0x40000000. The size of the two memory domains is 16MB, and the allocation method is a readable and writable memory segment. It is divided into two parts in mlt_arm_s3c2510_ram.ldi. The first is the MEMORY part, which defines the memory domain required in the RAM startup mode, as well as the starting address and length of the memory domain. The content of the MEMORY part must be consistent with the macros defined in mlt_arm_s3c2510_ram.h. The second is the SECTIONS part, which defines the memory segments specified in the RAM startup mode. The definition of these memory segments is related to the system memory management function. There are corresponding parameters after SECTION_XXX, which include the memory domain to which the memory segment belongs, the starting address (or alignment), the virtual memory address (VMA) and the load memory address (LMA).

       Take SECTION_fixed_vectors (ram1, 0x200, LMA_EQ_VMA) as an example, it means that the fixed_vectors segment belongs to the ram1 memory domain, the starting address is 0x200, and the load memory address is equal to the virtual memory address. LMA_EQ_VMA can also be interpreted as the memory segment does not need to be reallocated and loaded after the program is run.
Debugging results

       The S3C2510 target board has a 4MB FLASH and two 16MB SDRAMs. The newly built S3C2510 target board is compiled using the ECOS built-in compilation tool configtool to generate the ECOS library file. Then copy the install directory content under the library directory to the application project directory to include the ECOS library in the application project. Then use the IDE emulator developed by EMBEST to download the .elf file of the project directly to the SDRAM of the target board. At this time, the ECOS operating system should be in RAM boot mode. The

       debugging and test results of the program through IDE show that the S3C2510 transplantation solution proposed in this paper makes the ECOS operating system run normally and stably in the target board. The operating system supports applications with multiple working threads. The serial port and network port of S3C2510 can transmit data normally with the PC.

       Conclusion

       ECOS is a very young embedded operating system, which was officially promoted and used in 1997. At present, there are still few reference materials and specialized personnel for ECOS development, which has increased the development cycle and development cost of ECOS products. Therefore, the driver bottom code writing method of the ECOS operating system proposed in this paper has a very important guiding significance for developing products using ECOS.

References:

[1]. S3C2510 datasheet http://www.dzsc.com/datasheet/S3C2510_1097662.html.
[2]. ARM940T datasheet http://www.dzsc.com/datasheet/ARM940T_1336037.html.
[3]. rom datasheet http://www.dzsc.com/datasheet/rom_1188413.html.
[4]. MEMORY datasheet http://www.dzsc.com/datasheet/MEMORY_1082507.html.