The purpose of the BSP (Board support packages, board-level supporting package) is to provide operational interfaces for the operating system cores for special hardware platforms, allowing the operating system to be independent of the underlying hardware. For the upper application shielding specific hardware, VxWorks high portability is achieved through the BSP. This article focuses on the customization process of the BSP in the process of porting VxWorks to the at91rm9200 chip.
1 BSP Concept
BSP typically refers to a collection of startup code and some device drivers written by the user for a specific hardware platform. The functions it implements include initializing and driving some devices. The most basic BSP only needs to support processor reset, initialization, driver serial port and necessary clock processing. BSP is relative to the operating system, different operating systems correspond to different forms of BSP, so when writing the BSP must be written in accordance with the requirements of the operating system of the BSP defined form. In the VxWorks system, BSP is a software interface between the underlying hardware environment and the VxWorks, and its main function is to initialize the target hardware and VxWorks after the system is powered up, and to provide some hardware drivers. The BSP is shown in hierarchical relationship 1 in the VxWorks system.
BSP provides a unified software interface for the hardware functions of various boards, including hardware initialization, interrupt capture and processing, hardware clock and timer management, memory address mapping, and memory allocation. Each BSP also includes a ROM boot or other boot mechanism.
2 VxWorks of the boot process
Before you write the BSP, you should first understand the startup process of the entire system. The VxWorks image consists of code snippets, data segments, and BSS section 3. The Vxwotks core can be divided into 3 types: loadable type images, rom-based VxWorks images, and rom-resident images. These 3 types of image organizations are different, so the startup process differs.
The loadable image consists of two parts: VxWorks and Boot ROM, and two parts are created independently. First, the ROM boot program is moved to Ram_high_adrs by the system boot code. The ROM boot program then starts running, loads the VxWorks image into Ram_low_adrs, and jumps to the VxWorks image mount point.
The rom-based VxWorks image is fully moved into RAM when the BSP is initialized, including code snippets and data segments. After the copy execution is complete, the system control is transferred to the initialization code of the VxWorks image in RAM.
Rom-resident images simply copy the data and BSS segments of the VxWorks image in ROM into RAM, and the system control is transferred to the initialization code of the VxWorks image in Rom/flash, the code snippet remains in ROM and runs in ROM. The VxWorks image running in ROM is mostly sufficient to save RAM space, and the disadvantage is that it runs slowly.
Figure 2 and Figure 3 are the initialization processes for the download and ROM VxWorks images, respectively.
The following is a rom-type VxWorks kernel boot process, for example, explains the role of each file:
Romlnit () Save startup type, block interrupt, initialize memory and register, block cache, initialize CPU, position stack pointer to the address of the copy boot ROM image at Ram, jump to Romstart ().
Rorastart () unzip different parts of the VxWorks image based on different image types
3 VxWorks BSP Design on at91rm9200
3.1 at91rm9200 Introduction
AT91RM9200 's on-chip resources include: ARM920T processor edge, 16KB internal SRAM and 128KB internal ROM memory, support SDRAM, SRAM, Burst Flash and CompactFlash, Seamless connection of SmartMedia and Nandflash, 16KB data cache,16kb instruction cache, fully programmable external bus interface ebi,4 A 32-bit PIO controller can reach 122 programmable I/O pins (each with input control, Interruptible and open output capability), advanced interrupt Controller with 8 priority, individually shielded interrupt source, 6 set of hardware timers, 4 Universal synchronous/Asynchronous Transceiver Usart.
3. 2 modification of several important documents in BSP
Because the kernel of at91rm9200 is arm920t, the BSP file is mainly in the VxWorks Environment Tornado directory Target/config/all and target/config/integrator920t folder. Among them, the files in the A11 folder are common to most BSP, and generally do not need to be modified, especially "Configall". h "; The files in the integrator920t folder are the BSP files to be written, which are often closely related to the system hardware.
3.2.1 Modifying Makeflie
The makefile file defines the rules for compiling and linking the entire BSP, such as the selection of the compilation tool, the compilation options and the Include file path, and the control of the type of the generated VxWorks image file, along with the storage size information, and the change to the storage size information must be with CONFIG. The corresponding changes of H are synchronized. Some parameters need to be defined in the file, such as processor type, compiler tool, destination address, and so on. Here are some of the parameters and addresses to be modified:
3.2.2 Modifying Config.h
Config. The h file contains all header files and special CPU-related definitions. The configuration of the VxWorks kernel component is configured by CONFIG. h file definition. Config. The main modifications in H are the definition of the boot line and the modified address.
(1) Defining a guide line
Wherein, Mac (o,0) is the EMAC device in the at91rm9200 chip, host is the hostname, VxWorks is the file name to be downloaded, h is the host IP address, E is the target board IP address, U is the user name, PW is the password, and TN is the target board name.
(2) Change of address
The address definitions in the file, such as Rom_text_adrs, Rom_size, Ram_low_adr, Sram_high_size, and so on, are consistent with the relevant definitions in the Makefik file. The code snippet in this design is stored in the flash inside the CSO which is connected to the external arm chip, the base site is Oxl0000000, so. Defined as follows:
The default configuration of the VxWorks is by Configall. h to determine. In general, the settings of the default configuration are different from the configuration of the self-developed hardware system and can be cotlfig by the user. H to change the default configuration. The user must view the configAll.h and the CONFIG. H Remove unwanted hardware and software configuration and initialization. For example, the default configuration typically contains a floating-point processor, and there is no floating-point register in at9lrm9200, so the configuration is deleted.
3.2.3 Modifying integrator920t.c
This file sets all non-optional, at91rm9200 chip-related information, such as the address definition of each hardware-related register, the definition of the corresponding bit in the device register, the definition of each hardware interrupt vector and interrupt priority, the control of Dbug and Usart, the definition of the network port, system clock and auxiliary clock parameter settings, etc. The target board to be used by VxWorks contains the driver header for the device and should be included at the beginning of the file. The macro definitions in this file are based on the AT91RM9200 chip and are defined according to the specific requirements. For example, the Power Management controller uses two phase-locked loops Plla and PLLB, and some of their parameter setting codes are as follows:
3 2. 4 modifying Rornlnit.s
The file contains the portal initialization assembly code for the boot ROM and rom-based vxworks image. The entry point is the Rominit () function, which is the code that executes first after the system is power-up. The main functions are: Save startup type, make processor reset, initialize Flash and SDRAM, set MMU to known state, instruction cache enable, initialize MMU control register (instruction 32 bits, data 32 bit, write buffer enable), write buffer, and make command and data cache to be effective The interrupt is shielded by setting the IRQ stop bit for the CPSR, the FIR stop bit, and the interrupt disable register in the Advanced Interrupt controller AIC to jump to Bootinit. The Rom-start () in C, and the start type is passed. Where the interrupt mask code is as follows:
When debugging this code, because the serial port and the network port are not started, so only through the lighting program to track the execution of the program, set different LED light to show which step the program to perform. For example, if the 15th bit in the 32 bits of the parallel input/output C is lit, it can be programmed;
In writing this file, it is important to note that there is not too much initialization in the file, and most of the hardware initialization is syslib. C file in the Syshwinit () function.
3.2.5 Modifying Syslib C
Syslib. C is the core code of the BSP initialization. In this file, all the hardware must be reset so that it is in the initialization state, ensuring that no false interrupts are generated after the interrupt is opened. This file contains system-related C programs that are determined by the target machine architecture. These C programs provide board-level interfaces. Based on these interfaces, the VxWorks and application constructs are system-independent. The function of this file includes: Define the physical address and virtual address of Rram, SRAM, ROM, external chip chip, define the priority of each bit in interrupt priority register, call Syshwinit () initialize serial port and network port, install IRQ/SVC interrupt stack assignment program. , bus interrupt function and so on. There are two important functions in this file: Syshwinit () and SysHwInit2 (). The code for Syshwinit () is as follows:
SysHwInit2 () is used to connect system interrupts, install ISR, and perform other configurations. It is called by Sysclkconnect () when initializing the system clock, primarily to initialize the interrupt library and interrupt driver, to install the interrupt of the system clock and the auxiliary clock, and to interrupt the device such as the serial port.
4 Compiling the build image
After the system customization is done, there are two ways to compile: one is to compile the image file under Tornado, and the other is to compile it directly with the Make tool, but write the script file. The vxworks image that is mounted to the target board depends on how you use the download, which mainly includes the following:
①vxworks. This is a ram-based image, and the VxWorks needs to be run through the boot program on the target board to download it from the serial port or the network port to the target board's RAM. In the Tornado development environment, this is a default option that is used primarily during the debugging phase. Use the WINDSH tool and symbol table on the host.
②vxworks. St. This is also a ram-based image that requires the boot ROM to download the VxWorks image to the target memory for execution. The object file has a built-in symbol table.
③vxworks_rom. This is a non-compressed, rom-based image. Before this object file is executed, copy itself to the target RAM. This type of image is usually slower in the start-up phase because the code executes in ROM, but the execution phase is faster than the rom-resident image.
④vxworks. St_rom. This is a VxWorks image based on ROM compression. It extracts itself and copies it to the target machine's RAM before executing it.
⑤vxworks. Res_rom. This is an image of a rom-resident uncompressed VxWorks. It copies the data segment to the target RAM before execution. This type of image is faster in the start-up phase, but is slower on the target than the ROM-based image (because the CPU access ROM is slower than the access RAM). This type of image is typically used on target machines where RAM space is relatively small.
5 issues to be aware of
First, the rominit should be avoided. Too many initialization operations in S. In this history, only the necessary minimum hardware initialization is performed, and most of the hardware initialization is done in Syshwinit (). In addition, Romtnit. The code in S should not be called by another module or function.
Secondly, sysalib should be avoided. Too little work in S. BSP developers are often wrongly considered to be in Rominit. The device initialized in S does not need to be in sysalib. Re-initialize in S. In fact, the VxWorks image does not assume that it is booted by the boot image program, so it must reset and initialize all of the devices it needs to use. Sysinit () is the most important function in the file and the first function. Much of the work in this routine is the same as rominit () to ensure that the kernel image is highly consistent with the hardware and software environment when running and cold booting.
Finally, for a specific BSF. The driver is modified only in a specific BSP directory. The directory in this design is target/config/integra-tor920t, do not modify it directly in Target/src/drv and Target/h/drv. Only Wind River Company's source program can be stored in these directories.
6 conclusion
On the basis of introducing the concept, function and VxWorks image classification of BSP and the system start-up process, this paper takes the ARM9 processor at91rm9200 produced by Atmel as an example, and emphatically introduces several important files that need to be modified in the VxWorks BSP design. Finally, some problems needing attention are put forward. Although the target board hardware is different, the implementation of BSP is not the same, but the basic idea is the same. This design has a certain reference value for the system transplant and subsequent application development of all kinds of development boards.
VxWorks porting and BSP customization process
