2 BSP tissue structure
2.1 Introduction:
This chapter describes the part of the BSP, lists and describes all BSP-related source files and contains files. For .h files, this chapter describes the consequences caused by definition or canceling standard symbol constants; for .C files, this chapter describes and All necessary and optional functions related to files. This chapter also describes derived documents, such as syslib.o, syslib.o is a target file that is interpolated between the board-based dependencies and board-level code.
In this chapter, there will be some focused on the important BSP-related functions and their call sequence (reference to Appendix D VxWorks boot order), which will provide you with a system concept that debug VxWorks startup phases.
At the end of this chapter, there will be a discussion about the BSP development newcomers often make mistakes.
2.2 BSP Part:
One BSP consists of a series of routines or programs that provide them with the interface of the hardware environment to VxWorks.
Figure 1 shows the various components of VxWorks, and signs which is hardware independent, which is hardware-dependent.
figure 1
The BSP routine is included in many C or assembly files you have to create. If you start from a template BSP, these files may only be modified and do not have to be developed from scratch. The following summarizes the files and directories of the BSP.
2.2.1 BSP source and include files
This section introduces Target / config / all and target / config / bspname (bspname is your specific directory). Strictly speaking, the file below the directory target / config / all is not part of the BSP, but the module defined there is Shared by all BSPs. So if you want to understand your specific BSP, the familiarity of these modules is necessary. When a project's image is image, the part of the directory target / config / comps / src directory replaces the file under Target / Config / ALL. A component configuration refers to the C source code compiled by the project tool as part of the project build step. These files only provide the final project
Some of the limited parts are configured.
Directory Target / Config / ALL below
Directory Target / Config / ALL The following file is published as part of the VxWorks architecture unless it is absolutely necessary, do not easily modify these files. It is important to note that the file configall.h. This file sets all the default configurations of VxWorks Images, and your definition in this file should be common, so it can be used with most developers you use the same environment, if not all developers. If you need a VxWorks Image than the default configuration, you can use the value in the CONFIG.H of your BSP to override the default value in ConfigAll.h.
The file in the config / all directory is not used directly in a building project, which is only scanned once when you create a new project from a BSP. When a new project is established, any modifications made to the file in the config / all directory will not have any impact on the project. If you expect some changes to be referred to in the project, then you must make changes directly in the project instead of making changes in the config / all directory.
Note: Change the configall.h file from the command line may generate bad side effects for users using the same machine using the same machine, which is applied only to the command line build. One feature of Tornado 2.0 is a change that does not affect existing projects, and only new projects created from a BSP will inherit the modification of ConfigAll.h before.
Bootconfig.c - Boot Rom Images The most important initialization file.
BootConfig.c is the main initialization and control files for all boot rom images. It contains a complete Boot Rom shell task. It contains a table (NETIF) for the initialization of network devices. This module is actually a subset of USRCONFIG.C. Boot Rom images provides all optional features like a complete VxWorks Images. Special note is that Boot images do not use the MMU library (unless used for SPARC). Tornado 2.0 project tools are not capable of creating and maintaining a Boot ROT ROM project. For items created from the BSP, you can find a button from the build menu, which performs a traditional Boot Rom Image from the command line. Special attention, when Build Rom Image, the configuration information of a specific project is not effective, only traditional config.h, configall.h, bootconfig.c and bootinit.c have affected a BOOT
Rom Image of Build.
Bootinit.c - the second phase of the ROM initialization.
Bootinit.c file is the second phase of Boot ROM initialization. After Rominit.o, the function rominit () in the rominit.s file is jumped to romstart () at the end, and the ROMStart () function is defined in bootinit. . Function romstart () performs the necessary code decompression and ROM images, first, it copies the text and the data segment from the ROM to the RAM, then it is clear that the part of the RAM is no longer used, and finally it will Image of image is compressed. Different configuration options can determine how these operations are performed specifically.
For a ROMized VxWorks Image, in the project under Tornado 2.0, Romstart.c replaces the function of bootinit.c, pay attention to this is not for a Boot Rom Image.
DataseGpad.s --Vxvmi Text Section Protection.
Document DataseGpad.s is only protected by VxVMi Text sections, which guarantees that the text segment and the DATA segment do not share a MMU page.
USRCONFIG.C - The initialization code for VxWorks Image.
The USRCONFIG.C file contains the main initialization code for VxWorks Images. Not like the bootconfig.c file is self-contained, the usrconfig.c file contains target / src / config / usrextra.c, and the USRextra.c file also contains other files used to provide subsystem initialization and configuration.
USRCONFIG.C is only used to make Build from the command line, just like in Tornado 1.0. When using the project tool to the build project, the project initialization group determines the order of the component initialization, each component has a set of attributes to identify which initialization group belongs to the part belongs and also identifies where it should be placed in that group? .
Directory Target / config / comps / vsworks
The file in this directory is the basic component description file (CDF file) of the VxWorks real-time system kernel. Refer to Chapter 6 (Parts) to learn how to create, use, and delivered more information about how components are created. Refer to Appendix F.1 (Part Description Language CDL) to learn about the details of the grammar of the CDF file.
Documents under Target / Config / COMPS / SRC
