ECS operating system: hardware platform porting and driver programming

The bottom layer of the hierarchy of embedded software packages in the eCos system is the Hardware Abstraction Layer, referred to as HAL, which is responsible for operating and controlling the target system hardware platform, including processing interrupts and exceptions, and providing hardware operation interfaces for upper-level software. By simply providing an abstract layer for new hardware, the entire eCos system, including eCos-based applications, can be ported to a new hardware platform.

To build an eCos system, you must first build your own hardware abstraction layer, then create a driver, and then you can write an application.

The hardware abstraction layer is divided into three different sub-modules: Architecture HAL, Variant HAL, and Platform HAL. Architecture abstraction layer

: Different processor series supported by eCos have different architectures, such as ARM series, PowerPC series, MIPS series, etc. The architecture abstraction layer
abstracts and defines the basic structure of the CPU. In addition, it also includes interrupt delivery processing, context switching, CPU startup, and the instruction system of this type of processor structure.

Variant abstraction layer: refers to the special features of the processor in this processor series, which include Cache, MMU, FPU, etc. The variant abstraction layer of eCos is to abstract and encapsulate these particularities.

Platform abstraction layer: abstracts the hardware platform of the current system, including platform startup, chip selection and configuration, timing devices, I/O register access, and interrupt registers.

There is no clear boundary between the three submodules of the hardware abstraction layer. For different target platforms, this distinction is somewhat ambiguous. For example, MMU and Cache may belong to the architecture abstraction layer on a certain platform, but may belong to the scope of the variant abstraction layer on another platform; for another example, memory and interrupt controller may be an on-chip device and belong to the variant abstraction layer, or may be an off-chip device and belong to the platform abstraction layer.

The transplantation of eCos is completed through these three submodules, namely the transplantation of the platform abstraction layer, the transplantation of the variant abstraction layer, and the transplantation of the architecture abstraction layer. For a new architecture, it is relatively difficult to establish its system structure abstraction layer. eCos supports most of the currently widely used embedded CPUs and has hardware abstraction layers that support various architectures. Therefore, the transplantation of eCos rarely requires the writing of the architecture abstraction layer.

** Migration of platform abstraction layer **

Generally speaking, when developing eCos, the main work of migration is the platform abstraction layer, because eCos has implemented the architecture abstraction layer and variant abstraction layer of most popular embedded CPUs. The main work of the platform abstraction layer includes: memory layout, early platform initialization, interrupt controller, and simple serial port driver. The easiest

way to build a new platform system is to use the reference platform hardware abstraction layer with the same architecture and CPU model provided by the eCos source code, use it as a template, copy and modify all files related to the new platform. If eCos does not have such a platform, a similar hardware abstraction layer of another architecture or CPU model can be used as a template. For example, eCos provides the platform SNDS4110 with Samsung's ARM CPU S3C4510b as the core. When you need to migrate eCos to ARM CPU S3C44B0, this will be a good starting point.

The best way to start the migration work is to start with RedBoot. The first goal is to make RedBoot run on the new platform. RedBoot is the startup code that comes with eCos. It is simpler than eCos and does not use interrupt and thread mechanisms, but contains most of the most basic functions.

The RedBoot of the target platform is usually built in the following steps (taking the construction of a new platform of S3C44b0 as an example):

① Copy the reference platform selected in the eCos source code and rename the directories and files as needed. The main contents of the renaming include: the directory name of the new platform, the component definition file (CDL), the memory layout file (MLT), the source file and header file for platform initialization.

② Adjust the component definition file (CDL) options. Including the name of the option, the real-time clock/counter, the CYGHWR_MEMORY_LAYOUT variable, the serial port parameters and some other options.

③ Add the required packages to the top-level ecos.db file and add a description of the target platform. Initially, the entry of the target platform can only contain the hardware abstraction layer package, and other hardware support
packages will be added later. After the modification, the new platform can be selected in the eCos configuration program for configuration.

④ Modify the memory layout (MLT) file in include/pkgconf. Modify the MLT file according to the memory layout of the new hardware platform. MLT files have three files with different suffixes for each startup type: .h files, .ldi files, and mlt files. When modifying manually, you only need to modify the .h files and .ldi files, and ensure that the two files are modified synchronously. The main contents of the modification are the starting
address of ROM, the size of ROM, the starting address of RAM, and the size of RAM.

⑤ Modify the io macro definition of the platform. Complete the various IO macro definitions of the platform in the include/plt_io.h file, including the
I/O addresses of various CPU system configuration registers, memory configuration registers, serial port configuration registers, LCD configuration registers, Ethernet configuration registers, etc.

⑥ Modify the Cache code of the platform. Modify the macro definition of Cache in the include/hal_cache.h file. In the early stage of development, it is best to turn off the Cache first and then
turn it on after the transplantation is stable.

⑦ Implement a simple serial port driver. The initialization, reception, and transmission of the serial port are completed in the src/hal_diag.c file. The main functions are as follows:
cyg_hal_plf_serial_init_channel(), completes the specific initialization of a serial port;
cyg_hal_plf_serial_putc(), sends a character from the serial port;
cyg_hal_plf_serial_getc(), receives a character from the serial port;
cyg_hal_plf_serial_getc_nonblock(), receives a character in a non-blocking manner, that is, returns immediately when there is no data in the buffer;
cyg_hal_plf_serial_isr(), serial port interrupt service routine;
cyg_hal_plf_serial_init(), calls cyg_hal_plf_serial_init_channel() function to initialize each serial port, and registers the serial port interrupt service routine, serial port read and write routines and configuration routines to the kernel.

⑧ Modify or add platform initialization program. Platform initialization is done in 3 files: src/s3c44b0_misc.c, include/hal_platform_setup.h and
include/hal_platform_ints.h.
hal_platform_ints.h completes the interrupt macro definition of the system. The number and type of devices on different platforms are different, and the decoding method of interrupts is also inconsistent, which needs to be adjusted according to the specific situation.
hal_platform_setup.h mainly completes the preliminary configuration of the system hardware. Here, the system clock frequency, ROM and RAM initialization parameters are generally configured after the watchdog and interrupt are turned off.
The s3c44b0_misc.c file completes the further initialization of the target board, interrupt processing, delay routines and operating system clock settings.
After the above modifications, the underlying platform abstraction layer is basically completed. At this time, the eCos configuration tool can be used to generate RedBoot for testing.
After the RedBoot test is successful, it means that the platform has been able to complete the initialization operation correctly, and the serial port driver can also work normally. Then, the interrupt and cache tests need to be completed. Some multi-threaded small program tests can be used to detect whether the clock configuration is correct, and whether the interrupt can work normally.


** Driver design **

After the platform abstraction layer is completed, the system device driver needs to be completed. The interrupt module of the eCos device driver is divided into three levels: interrupt service program ISR, interrupt delay service program DSR and interrupt thread. ISR is called immediately in response to interrupt, DSR is called after ISR issues a call request, and the interrupt thread is the client program of the driver.

Hardware interrupt is delivered to ISR for processing in the shortest time. The hardware abstraction layer decodes the hardware interrupt source and calls the corresponding interrupt ISR. ISR can perform simple operations on the hardware, and the processing time of ISR should be as short as possible. When ISR returns, it can put its own interrupt delay service routine DSR into the task scheduling of the operating system, and DSR can run safely without interfering with the normal operation of the scheduler. In most cases, DSR will run immediately after the ISR is executed.

All device drivers used by eCos are described by device table entries. The macro DEVTAB_ENTRY() can be used to generate device table entries. Its format is:

DEVTAB_ENTRY(l, name, dep_name, handlers, init, lookup, priv);
Description: {
l: "C" identifier of device table entry.
name: "C" string name of the device, used when searching for devices.
dep_name: For a hierarchical device, this parameter is the "C" string name of the device under the device.
handlers: I/O function handle pointer, implemented by the macro DEVIO_TABLE.
init: The function called when eCos is in the initialization phase. This function can search for devices, set up hardware, and perform other operations.
lookup: The function called when the cyg_io_lookup() function is called to operate the device.
priv: Private data required by the device driver.
}

The handles handlers in the device entry contain a set of device driver interface functions, which are pointers to the device function table DEVIO_TAB. DEVIO_TAB contains a set of function pointers. The device I/O function table is defined by the DEVIO_TAB macro, and the format is as follows:
DEVIO_TABLE(l, write, read, get_config, set_config);
Description: {
l: The "C" identifier of the table, that is, the handlers in DEVTAB_ENTRY.
write: Implement data transmission to the device.
read: Implement data reading from the device.
get_config: Implement reading device configuration information.
set_config: Implement configuration operations on the device.
}

During the initialization boot process of eCos, the corresponding init() function (that is, the initialization function registered by the DEVTAB_ENTRY macro) is called for all devices in the system, and all I/O operations on the device
are completed through handlers.

The device driver contains the following content (xxx: represents a certain device):

◆ Use macros to define the DEVIO_TABLE device I/O function table.
DEVIO_TABLE(xxx_handlers, // I/O function handle pointer
xxx_write, // write function
xxx_read, // read function
xxx_get_config, // read configuration
xxx_set_config)// Set configuration
◆ Use macros to define DEVTAB_ENTRY to register the device entry.
DEVTAB_ENTRY(xxx_device, // Device entry name
"/dev/xxx", // Device name,
NULL is used when searching for devices, // The underlying driver to be used, empty here
xxx_handles, // I/O function handle pointer
xxx_init, // Device initialization function
xxx_lookup, // Device search
xxx_priv) // Device private data pointer
◆ Complete the initialization function xxx_init. Complete the initialization of the hardware, call the function cyg_drv_interrupt_create to create the interrupt object, and then call the function cyg_drv_interrupt_attach to complete the connection between the interrupt and the hardware vector.

◆ Complete the interrupt service program.
◆ Complete the interrupt lag service program.
◆ If there is an interrupt thread, complete the interrupt thread.
◆ Complete the device search function xxx_lookup.
◆ Complete the write function xxx_write.
◆ Complete the read function xxx_read.
◆ Complete the read configuration function xx_get_config.
◆ Complete the set configuration function xxx_set_config.

Conclusion:
After the hardware platform is ported and the driver is written, various applications can be developed on this basis.