Vxworks BSP transplantation on Samsung S3C2440 platform

It is of great significance to study the transplantation of Vxworks BSP based on S3C2440 platform. This paper introduces the concept of BSP, several files that need to be modified during BSP transplantation, serial port and network port drivers, and BSP debugging and simulation in detail.

BSP Overview

The VxWorks operating system puts all the hardware functions into a series of libraries, which are called board support packages (BSP). BSP is an interface software package that connects the VxWorks operating system and the hardware platform. It plays an important role in booting the system and supporting the system operation. First, the bootrom that boots the operating system can be generated through BSP; second, the foundation of the boot line project is BSP; finally, BSP has the function of interacting with users and can provide a basic hardware debugging environment. BSP can also enable VxWorks to run on specific hardware platforms, such as ARM, PPC, X86, etc. It contains a series of hardware-related functions to complete basic input and output operations for hardware, allowing upper-level programmers to program without being familiar with the hardware. For example, it generally completes the following operations: target board hardware initialization, memory controller initialization, stack initialization, peripheral device initialization (I/O, Interrupt...), exception vector processing, CACHE operation, hardware device bottom driver, timer driver, serial port driver, END network driver, FLASH driver, LCD driver, etc.

The role played by BSP in embedded systems is very similar to that of BIOS and drivers in PC systems. Figure 1 includes various components of the VxWorks operating system, indicating the position and role of BSP in the entire system.

BSP Design of VxWorks on S3C2440

S3C2440 Introduction

The hardware configuration of the transplant target machine is as follows: processor S3C2440, using ARM920T core, memory size 64M; NAND Flash size is 128M;

NOR Flash size is 2M; 3-way URAT; 2-way SPI; IIC bus interface; Network card: DM9000, 10/100M adaptive.

Figure 1. Block diagram of the position of BSP in embedded systems [page]

BSP Porting Process

To develop and design BSP, it is best to have a reference template. Since the core of Samsung S3C2440A is ARM920T, the reference template is Tornado for arm's integrator920t. BSP files are mainly in the target/config/all and target/config/integrator920t folders of the VxWorks compilation environment Tornado. Among them, the files in the all folder are common to most BSPs, and generally do not need to be modified. The focus is to modify several files in the integrator920 folder, which mainly refers to the modification of the relevant parts in makefile, config.h, rominit.s and sysLib.c. In addition, the serial port driver and DM9000 network card driver are added.

Modify the Makefile

The two main functions of Makefile are to provide dependencies between files and target file generation methods, and to define the rules for compiling and linking the entire BSP. Some parameters in the Makefile have been defined in the config.h file, but the definitions in the two places must be consistent, otherwise compilation errors will occur. The following are some parameters that need to be modified:

CPU: describes the processor type of the target board, which is ARMARCH4 in the design;

TOOL: This parameter is used to select the compilation tool. In VxWorks, GNU and DIAB can be used. The GNU compiler is used to compile the target code in the design;

TGT_DIR: The default setting is $(WIND_BASE)/target;

TARGET_DIR: The default is the directory where the BSP is located, which is mini2440 in the design;

VENDOR: The name of the board manufacturer, HITSAT in the design;

BOARD: the name of the board, OMU in this design;

ROM_SIZE: ROM or Flash size (hexadecimal);

RAM_LOW_ADRS: The starting address of VxWorks in RAM, i.e. the entry address;

RAM_HIGH_ADRS: The loading address of the startup program of the non-resident ROM kernel. The designation of the entry address and high address should refer to the RAM organization of the hardware.

The rest of the settings and definitions in this file are consistent with those in the template.

Modify config.h

The config.h file is an important file in the BSP software. The configuration of the VxWorks kernel component can be defined through the config.h file. The config.h file contains all header files and special definitions related to the CPU. The configuration parameters in the config.h file are set according to the hardware resources of the development board based on the content of the configAll.h file, including defining the boot line, modifying the address of the storage space, etc. The following is a detailed introduction to some of the configuration parameters modified in the config.h file:

(1) Define the guide line

#define DEFAULT_BOOT_LINE "dm(0,0) zwj-PC:d:VxWorks h=192.168.0.1 e=192.168.0.2 u=zwjhjj pw=zwjfile tn=mini2440"

Among them: dm(0,0) is the boot device, that is, the boot device image;

zwj-PC is the host name;

d: VxWorks is the file name, that is, the path of the VxWorks image file to be downloaded;

h=192.168.0.1 is the host IP address;

e=192.168.0.2 is the target board IP address;

u=zwjhjj is the user name for FTP login;

pw=zwjfile is the password for FTP login;

tn=mini2440 is the name of the target board.

(2) Modify the address

When modifying the configuration parameters of the target board storage area, you must pay attention to the following: the address definitions in this file, such as ROM-TEXT-ADRS, ROM-SIZE, RAM-LOW-ADR, SRAM-HIGH-SIZE, etc., must be consistent with the relevant definitions in the Makefile file. Determine the target board memory based on the actual CPU and the size of the external memory.

#define LOCAL_MEM_LOCAL_ADRS 0x30000000 /*Start address of RAM*/

#define LOCAL_MEM_SIZE 0x04000000 /*RAM size is 64M*/

#define ROM_BASE_ADRS 0x00000000 /*Flash base address*/

#define ROM_SIZE0x00100000 /*Flash size for storing VxWorks*/

#define ROM_COPY_SIZE ROM_SIZE

#define ROM_SIZE_TOTAL 0x00200000 /*Total Flash size*/

#define RAM_LOW_ADRS 0x30001000 /*Entry address of VxWorks image*/

#define RAM_HIGH_ADRS 0x32e00000 /*Bootrom starting address in RAM*/

Modify S3C2440x.h

This file is a file added by myself, which includes the processor-related peripheral register structure, address, peripheral interrupt number allocation, serial port settings, etc. The following mainly introduces the definition of the serial port in this file:

/* Definition of s3c2440 serial port*/

#define UART_XTAL_FREQ s3c2440x_PCLK

/*Serial port clock frequency*/

#define N_s3c2440x_UART_CHANNELS 3 /*Number of serial port channels*/

#define N_SIO_CHANNELS N_s3c2440x_UART_CHANNELS

#define N_UART_CHANNELS N_s3c2440x_UART_CHANNELS

#define UART_0_BASE_ADR 0x50000000 /*Base address of serial port 0*/

#define UART_1_BASE_ADR 0x50004000/*Base address of serial port 1*/

#define UART_2_BASE_ADR 0x50008000/*Base address of serial port 2*/

In addition, a s3c2440xSio.h file is added, in which the serial port data structure is defined:

typedef struct s3c2440x_CHAN

{ SIO_CHAN sio; /* Standard SIO_CHAN structure */

STATUS (*getTxChar) (); /*Install the send callback function*/

STATUS (*putRcvChar) (); /*Install receive callback function*/

void * getTxArg;

void * putRcvArg;

…….

UINT32 channelMode; /*Current mode (interrupt or polling)*/

int baudRate; /*Current baud rate*/

}

After the data structure is initialized, there are several important functions to note: sysHwInit(): initialization of the processor I/O port; sysSerialHwInit(): initialization of the device descriptor; sysSerialHwInit2(): connect the serial port interrupt handlers s3c2440xIntTx and s3c2440xIntRcv to the corresponding interrupt vectors through intConnect(), and enable two interrupts through int Enable(), call s3c2440xDevInit2() to assign the _UCON register to complete the final configuration of the serial port from polling mode to interrupt mode, and implement the reception and transmission of serial port data in the interrupt service program. The design of the serial port driver is completed by adding these function functions.

Modify romInit.s

[page]

Some code modifications are as follows:

/*Added initialization of the serial port UART, configured some control registers of UART, and set the baud rate. Some codes are as follows*/

InitUART：

#define UART_BRD (( 50750000 / (115200 * 16)) - 1)

mov r2, #UART_BRD /*Set the baud rate of the serial port*/

/* Initialize stack pointer */

ldr sp, L$_STACK_ADDR

mov fp, #0

After the stack is established, the system has the conditions for executing high-level languages, and subsequent code can be implemented in C language.

/* Make the program jump to the C language program segment code as follows*/

#if (ARM_THUMB)

ldr r12，L$_rStrtInRom

orr r12，r12， #1

bx r12

#else

ldr pc, L$_rStrtInRom /*jump to romStart() to execute*/ #endif

After the CPU transfers the execution right to romStart(), the function clears the memory, copies the entire boot image to the memory, and finally transfers the control right of the CPU to usrInit().

Modify sysLib.c

The file sysLib.c provides the board-level connection between VxWorks and the application. Here we focus on the memory mapping function.

The target system has the MMU module enabled, and the BSP defines a sysPhysMemDesc[ ] table in the sysLib.c file. Part of the code is as follows:

PHYS_MEM_DESC sysPhysMemDesc [] =

{ (void*) (ROM_BASE_ADRS+0xf0000000)， (void *) (ROM_BASE_ADRS)，

ROUND_UP(ROM_SIZE_TOTAL*2，PAGE_SIZE)，

VM_STATE_MASK_VALID|VM_STATE_MASK_WRITABLE|VM_STATE_MASK_CACHEABLE，

VM_STATE_VALID|VM_STATE_WRITABLE_NOT|VM_STATE_CACHEABLE_NOT

}

The above code snippet is a memory mapping of ROM_BASE_ADRS. ROM_BASE_ADRS+0xf0000000 is the virtual address to be mapped. ROM_BASE_ADRS is the actual physical address defined during hardware design. ROUND_UP(ROM_SIZE_TOTAL*2,PAGE_SIZE) is the mapping length. VM_STATE_MASK_VALID|VM_STATE_MASK_WRITABLE|VM_STATE_MASK_CACHEABLE are the initializable address states. VM_STATE_VALID|VM_STATE_WRITABLE_NOT|VM_STATE_CACHEABLE_NOT are the actual initialized address states.

If a new peripheral is added, the memory space corresponding to the peripheral must be configured in sysPhysMemDesc[]. This configuration completes the memory mapping and MMU enablement.

Modify dm9kEnd.c

Since S3C2440 uses the DM9000 network card, to make a good END driver for the DM9000 network card, you must first initialize the network card's data structure dm9kDevice, which is as follows:

typedef struct dm9kDevice

{

END_OBJ endObj; /*Inherited class*/

int unit; /*device unit number*/

UINT32 flags; /* Local flag signal*/

int ivec; /* interrupt vector */

int ilevel; *interrupt level*/

……

} DM9K_DRV_CTRL

The END_OBJ type member, network card unit number, interrupt number and interrupt vector in the data structure are member elements that must be included in the network card driver.

Some interface functions of the driver mainly include the network card loading function dm9kEndLoad, the network card starting function dm9kStart, the network card stopping function dm9kStop, the network card control function dm9kIoctl, the network card unloading function dm9kUnload, the network card sending function dm9kSend, the multicast address getting function dm9kMCastGet, the polling mode starting function dm9kPollStart, the polling mode closing function dm9kPollStop, the polling mode sending function dm9kPollSend, the polling mode receiving function dm9kPollRcv, etc. The network card driver is realized by writing functions for these interface functions.

In the process of writing the driver, you must also pay attention to the following: Since the target board uses a 100-pin DM9000 chip, this chip has 6 address chip select signals SA4~SA9 in addition to the CMD signal. According to the CPU address lines corresponding to SA4~SA9 and the pin definitions in the data sheet, the port address of the network card can be calculated. If SA4~SA9 corresponds to addr4~addr9 of the CPU address, then the base address of the network card port is 0x18000300, so the base address of the network card can be calculated.

Figure 2 Printing information of VxWorks COM1 port

[page]

After the BSP modification is completed, it is time to debug. Here we use the debugging method of lighting up the LED light. Write a lighting program, use BSP to generate bootrom and VxWorks images, use H-JTAG software to burn bootrom into norflash of the target board, debug BSP by repeatedly calling the lighting program at different locations and burning bootrom into norflash, and view the debugging information through the serial port. As shown in Figure 2, it is the debugging message printed on the host through the serial port during the startup of the operating system. This information can be used to determine which part of the system startup process has a problem.

Figure 3 VxWorks Shell interface

After the system is powered on, the bootrom runs first, and then the VxWorks image file is downloaded into the rom through the network cable. Figure 3 shows the Shell interface of VxWorks, which displays the device list with serial port and network port, indicating that the serial port and network port are driven successfully.