Wince6.0 supports multiple xip

1. Multiple xip support

Xip (execute-in-place) is a local execution that allows the xip region (region) application code to be executed in the ROM chip, without having to read the code to ram for execution. Wince supports building (construct) Multiple xip regions in a single system. We use multiple xip regions to replace a single region for the following reasons:

(1) applications can be divided into functional subsets and installed separately from the OS kernel.

(2) When adding a new feature, you do not need to replace the entire runtime image ).

(3) update after a bug is fixed does not need to replace the entire runtime image.

(4) you can update the runtime image.

The image is permanently updated during runtime (permanent) and is not easily affected during cold start.

Flash memory is widely used as a substitute for mask read-only memory (masked ROM). It is a chip technology that supports multiple xip regions. In this help topic that discusses multiple xip regions, Rom-related flash memory is used to save the system image ).

In multiple xip regions, the ROM image is divided into separate and gradually increasing address units, which are used here to describe,

 

 

 

Figure 1

So how to divide xip images? Consider the owners of modules and files in the region, and consider the functions of these modules and files.

Note that xip cannot cross discontinuous physical areas. Although the virtual address is continuous, some devices do not respond when code that spans different physical areas is executed locally ). Files and modules that are not compressed and span discontinuous physical areas are directly mapped or accessed without being copied, but the kernel only processes physical continuous files.

2. Multiple xip regions

Because we can construct multiple xip areas in a single system, from this point, we are using multiple storage areas (memory areas, such as using multiple memories such as ROM and flash at the same time in the design) in application scenarios, we can use the xip function. For example, we can install the kernel part of the OS in the Rom, and install other parts of the OS in flash memory. The xip application can be executed in two places. We can gradually plan the flash region as needed, but the xip area in the memory must be read-only, than xipkernel in 1. nbo must be read-only in NAND Flash.

We can link Multiple Rom areas (chain) as needed. When downloading an xip image via USB, we can download the chain. LST, then eboot automatically downloads xipkernel Based on the LST file. bin, NK. BIN and chain. bind the file, and then start the wince operating system. Each time we add a rom area, the kernel can replace another Rom area. Here, the kernel does not replace this module physically, instead, we use a module in a different Rom region to replace its functionality (each time you add a rom region, the kernel may
Replace another Rom region. The kernel does not physically Replace the module, but replaces its functionality with a new module in a separate Rom region ). The order in which we define the ROM region determines the order in which the OS writes modules. Rom.exe with nk.exeincluded is used to manage the directories of multiple romators. See figure 1. Our nk.exe is included in xipkernel. Bin. The module of the original image outside the region.

 

To add a rom region (which can be understood as XXX. BIN) to an existing runtime image, create a new column. bib file, which lists the modules we want to add or replace in an existing OS design. If you want to add a new. exefile to replace one that already exists, you can only add an. EXE file to the. bib file.

 

If we add or repair a DLL, we must create an added entry in the. bib file. In wince, all DLL files are loaded from top to bottom in the virtual memory process space (all DLLs load from the top down in the virtual memory process space ). Because wincesets the same address to a specified. EXE file to load all DLL files, the. binfile modules Part reserves the same size of virtual memory space for all DLL files. For any specified process, the system does not load the same DLL file to the process address space, or reserve space for subsequent loading (
Any specified process, the system either loads the same DLLs to the process address space or reserves space to load later ). When makeimg.exe is used to compile a ROM image (such as NK. Bin), it generates the start address and the last address of the DLL in the image, as shown below:

First DLL address: 01f90000h

Last DLL address: 02000000 H

 

We must include an entry in the config section of the New. bib file. Use dllhighaddr to specify the starting address of the DLL address space of the associated ROM image. The starting address is the lowest address of the virtual memory space allocated for the DLL in the original (original). binfile. In the new. binfile, makeimg.exe lists the starting addresses from the virtual memory that the system can reserve and load. The system reserves the storage space from the starting address (the system reserves memory from the starting address down ), the following Sample Code explains a new one. binfile to generate the starting address of an example DLL:

Dllhighaddr = 0x01f90000

 

Make sure that the xip area does not overlap. Otherwise, the system cannot start properly. To avoid system problems, you need to leave a certain amount of memory space between DLL areas, but this will reduce the size of virtual memory available in a process. Because the kernel reserves the same size of virtual memory space for all Rom to load DLL, the kernel never uses the memory space between DLL. This memory space is used to expand the DLL space of the ROM image without re-arranging the ROM image followed by it.

 

The kernel permits a DLL to be completely detached from an image, even if it is implicitly associated with other modules. Romimage.exe prints a warning that the DLL is missing, but the image file is still created. In this way, we can load the unfound DLL from the RAM file system or target control framework (target control shell.

 

3. booting an image with multiple xip regions

To boot a multiple xip image, bootloader must load data to flash memory or ram, and then the oeminit function must process each entry in the xip chain, add each entry to the oemromchain struct. The definition of this struct is shown in:

 

 

 

Figure 2

In config. bib, the OEM can set the romchain order of all xips, as shown in ratio 1, xipkernel, chain, and NK. If the chain table of the traversal oemromchain structure and the kernel (xipkernel. Bin here) cannot be found, the kernel automatically attaches the Rom to the oemromchain Chain List.

4. Building an image with multiple xip regions

Create an image composed of multiple xip regions, which is composed of config. bib and imgmultibin (but in fact imgmultixip) environment variables to control, this variable must be set to 1, for example, in smdk6410.bat set as follows:

Set imgmultixip = 1

After multiple xips are compiled successfully, the following files are generated:

(1) generate a corresponding. binfile for each xip region, such as xipkernel. Bin, chain. bin, and NK. Bin.

(2) A separate xip. binfile that contains all xip region files, such as xip. bin = xipkernel. bin + chain. bin + NK. Bin.

(3) binfile of an xip chain, which is the chain. binfile.

(4) If romstart, romwidth, or romsize is set in the config. bib file, the xip. nb0 file is generated. The layout of all. binfiles in xip. nb0 files, as shown in 1, contains chain. bin because they (xipkernel. Bin, chain. bin, and NK. Bin) should be saved in the Rom.