Common files in the BSP package for Windows CE System Development

Common files in the BSP package for Windows CE System Development

BSP introduction (board support package) is an underlying software development kit between the underlying hardware and the upper-layer software. It is mainly used to shield hardware and provide the operating system and hardware driver. The specific functions include:

(1) single board hardware initialization, mainly including CPU initialization, providing underlying hardware support for the entire software system;

(2) provide device drivers and system interruption services for the operating system;

(3) customizes the functions of the operating system to provide a real-time multi-task running environment for the software system;

(4) initialize the operating system and prepare for the normal operation of the operating system.

1.1.1 sources. CEN File

Sources. CEN is a common source file, which is used for all source code compilation in BSP. It defines some commonly used nouns, environment variables, or paths.

For example, in the source file of the oampl138 McBSP driver directory, "primary des =$ (primary des );.. \ Inc "this line of pseudocode, where the" (DES) "part promptly references source. the include environment variables in the CEN file are defined as shown in program list 0.1.

Program list 0.1 defines platform-related files, mainly including environment variables

Includes = $ (_ platformroot) \ common \ SRC \ Inc;

Let's take a look at this English introduction;

Sources. CEN is a build configuration system file that allows you to set common variables. this can be useful if more than one directory in the build tree need the variable set to the same value because it can reduce your maintenance efforts.

Each build tree can use one sources. CEN file. when build.exe runs, it will determine the root of the build tree by looking for the top most folder with a dirs file. build.exe then sets buildroot to the top most folder with a dirs files. makefile. def in
Public \ common \ oak \ MISC will include $ (buildroot) \ sources. CEN if it exists.

Some of the variables that are commonly set in sources. mn include cdefines, adefines and between des.

Cdefines and adefines are used to set macros that are common to multiple build folders. These might include Ram and Rom sizes, but might also include OEM and CPU specific macros.

The include path, includes, can be set in sources. CEN which is very helpful, especially if and when you change the directory structure.

The Platform directory tree shocould have winceoem set to 1, so sources. CEN is a good place to do this rather than setting it in each sources file.

Note:Starting with Windows CE 5.0, sources. CEN is no longer really an option. it is required because sources. CEN needs to at least set _ commonpubroot, _ isvincpath, and _ oemincpath. these were set by build.exe in prior versions.

1.1.2 XXX. BAT file

The DAT file is used to define the structure of the file system when wince is started, that is, to define the folders and locations of the files. During each cold start, the filesys module creates directories and files under directories Based on the content in the. dat file.

In BSP, We can find platform. dat. After creating an wince project, you can find project. dat under the project directory. You can define the required root directory and corresponding subdirectories and files in these two. DAT files, except for Windows folders and Their subfolders. You can define shortcuts to reference files in the Windows directory, as shown in program list 0.2.

Procedure List 0.2 DAT file application example

Root:-directory ("My Documents ")

Root:-directory ("Program Files ")

Directory ("\ Program Files"):-directory ("My Projects ")

Directory ("\ Program Files"):-directory ("accessories ")

Directory ("\ Program Files"):-directory ("communication ")

Directory ("\ Program Files \ My Projects"):-file ("My project program", "\ windows \ myproj.exe ")

Root:-file ("\ Control. lnk", "\ windows \ Control. lnk ")

For a brief explanation, the above content is to first create two root directories, my documents and program files, and then create the my documents file under program files to the my projects directory, and the name is my project program. In this example, all files such as myproj.exe are copied from the Rom, so they must be included in the bib file. The last line indicates creating control. lnk in the root path. This file is from the control. lnk file in the ROM and is a shortcut file. Explain some of the above formats;

1. Syntax format of root directory

Root: [-directory ("dir_name")] [-permdir ("dir_name")]

[-File ("target_filename", "source_location")]

Root: indicates the root directory.

-Directory ("dir_name"): defines the directory name under the root directory.

-Permdir ("dir_name"): defines a permanent Directory, which cannot be deleted using the removedirectory function.

-File ("target_filename", "source_location"): defines a target file, which is copied from the Rom. Target_filename is the name of the target file, and source_location is the file in ROM, which is the name of a file in a path under the Windows directory.

2. Syntax format of directory:

Directory ("dir_name"): [-directory ("dir_name")]

[-File ("target_filename", "source_location")]

Directory ("dir_name"): indicates the directory name ." \ "Indicates the root directory.

-Directory ("dir_name"): indicates the path under the Directory, which is a subdirectory.

-File ("target_filename", "source_location"): defines a target file, which is copied from the Rom. Target_filename is the name of the target file, and source_location is the file in ROM, which is the name of a file in a path under the Windows directory.

The syntax used in dat is relatively simple. Let's look at the example to know how to modify it. Generally, we will change the file path structure after wince is started by modifying project. dat and platform. dat. Among them, platform. dat is related to the platform, while project. dat is related to the wince project.

1.1.3 config. bib File

The config. bib file is an important memory in BSP. It is used to specify the CPU memory allocation. First, let's see how this part of oampl138 is arranged, as shown in program list 0.3.

Program configuration 0.3 config. bib File Memory Section

Memory

NK 80000000 02000000 ramimage

Ram 82000000 0173f800 Ram

Display 8373f800 00600000 Reserved

Emacbuf 83d3f800 000c0000 Reserved

ARGs 83dff800 00000800 Reserved

# If defined bsp_dsplink

Dsplink 83e00000 00200000 Reserved

Extensionram 84000000 04000000 Reserved

# Else

Extensionram 83e00000 04200000 Reserved

# Endif

In brief, all memory specified in config. bib refers to virtual memory. If you know the corresponding physical address, you can refer to oemaddrtab. inc code.

In the above Code, NK specifies the address area where the kernel is loaded to the ram. 0x80000000 indicates the start address of the kernel memory, and 0x02000000 indicates the size of the kernel, from this we can see that the kernel cannot exceed 32 MB.

In the preceding code, argS is very important. It is the region where BSP and OS sharing parameters are created. Generally, the parameters set in BSP are stored in the ARGs region. If necessary, you can use kerneliocontrol to obtain the region after the OS is started, read the parameters, and set the system. For example, when the parameters of the display are changed during bootloader startup, bootloader stores the parameters in args. After the OS is started, the LCD Driver obtains the ARGs region and parses the parameters, adjust the LCD display settings so that the LCD can be properly displayed.

L tips

During bootloader compilation, it is sometimes difficult to generate the nb0 file. In fact, the config. bib file has not been set. Let's see how oampl138 is implemented, as shown in program list 0.4. The setting is not explained by referring to program list 0.3.

Program list 0.4 nb0 generation skills

Romstart = 80000000

Romwidth = 32

Romsize = 2000000

In addition, in order to improve the ram utilization, the "NK" area is used to load the memory of the remaining part of the kernel and release it for Ram to expand the program running memory. It seems incredible. In fact, it is very simple. You only need to add"Autosize = on.

1.1.4 platform. bib File

This file contains files related to the hardware platform, mainly driver modules. This file also defines how these modules and files are loaded into the memory. The specific format is shown in program listing 0.5;

Procedure List 0.5 platform. bib format

Name path memory type

Name: the name of the module, such as the file name of a DLL or EXE file.

Path: path, which is generally the release directory of the wince project.

Memory: Specifies the region in which the module is stored. Generally, all modules are in the NK region.

Type: defines the file type, as shown in table 0 sequence 1;

Table 0 Category 1 Type

Type	Description
S	System File.
H	Hide a file.
R	Only the resource part of the module is compressed.
C	All parts of the compression module.
D	Disable debugging.
N	Modules are untrusted.
P	Romimage.exe does not need to check the CPU type.
K	Romimage.exe must fix the kernel address of this module. Modules with this tag can only be loaded by the loadkernellibrary function.
X	Romimage.exe signs the module.
M	Load the entire module during runtime. Do not pagination as needed.
L	Romimage.exe do not separate Rom DLL.

Generally, the type of the files item only supports the S, H, N, and D types, while the type of the modules item is supported.

For example:

Init. EXE % _ winceroot % releaseinit. exe nk sh

Mydll. dll % _ winceroot % releasemydll. dll NK Shk

Bib files also support "Conditional compilation". We can selectively package some modules into wince image by setting environment variables. Generally, in BSP, if is used to judge the environment variables of some driver modules. For the wince system module, it is generally a sysgen variable and should be determined by @ cesysgen if.

L tips

Generally, If you modify the platform. bib or the platform. reg file, the system needs to re-"sysgen" once, and "sysgen" takes a long time, which is unbearable in the work.

In this case, we generally use this method. In platfrom. in the bib file directory at the same level, we recommend that you name a bib file named after the platform, such as oampl138.bib, and then include the file in the platfrom file (as shown in program list 0.6 ), you only need to modify the oampl138.bib file, and then make run-time image to take effect.

Program list 0.6 include

# Include "$ (_ targetplatroot) \ files \ oampl138.bib"