เทคนิค ถาม และ ตอบ

[CE Technical Tip]Contents on BINFS realization (1)

  • no.2540
  • 2013-03-19

Contents to be referred for BINFS realization……   (1)                           

 

XIP vs. Relocatable Code

 

When building Windows CE OS the Windows CE based components can be generated in a form of the two different forms such as the location called “relocatable” independent form, or the location called “execute in place [XIP]” fixed form.

 

During OS run-time in order to run code the OS loader shall fix relocatable codes to the available RAM address dynamically selected by loader. 

 

This method has an advantage to effectively use RAM of system even without clearly specifying RAM layout. On the other hand OS loader has a disadvantage to take a little more time in treating the relocation of code. Additionally as the code is transferred to RAM only there is no way to find where the code is run.

 

XIP image is a location-fixed and built one so that it may be run at a specific // This location should be approached in a continuous structure so that CPU can bring a command together with DRAM and NOR flash memory. XIP image provides the possibility to run code by use of flash memory and minimum RAM.

 

In order to understand how to decide on what is required for windows CE OS build tools to generate XIP and relocatable code the ROM Image Builder tool (Romimage.exe) and Binary Image Builder (.bib) file should be understood. For further information on these you should referred to ROM Image Builder and Binary Image Builder File.

 

By specifying the compressibility of components composing Windows CE OS image and the scope of system address for running code to be located what part of image will be XIP, or which will be relocated during OS run-time can be set. In addition what will be run outside of flash memory, or the setting scope of whether it will be run at RAM can be fixed.        

 

In order to save OS image in Flash memory, the code important in running performance and modules unusually used should be compressed. This causes to use Flash memory as less as possible and page codes to RAM during run-time. Accordingly as a result, the access time is faster.

 

The code important in running performance should be run at RAM without demand paging. This code should be completely loaded by OS loader instead of demand paging, or should be copied at RAM by boot-time loader.

 

ROM Image Builder

ROM Image Builder tool (Romimage.exe) is Windows CE build tool to be run at the final stage of build process. Romimage.exe performs the following functions.

 
In order to generate final OS image the necessary components such as driver, run & data file, etc should be collected.

 

         At what location the run codes should be run will be decided.

 

         A part of image should be compressed.

 

         At the space address between arranged components the data file or compressed parts should be inserted. 

 

         Nk.bin OS image to be loaded on the target platform should be generated. 

 

The settable .bib files should be used for the above process.

 

Binary Image Builder File

 

Binary Image Builder (.bib) file specifies the files and components to be loaded on OS image. Additionally the bib file includes the attribute information to let us know how OS will treat respective files and components. For example, the bib file includes the information on uncompressed image or information to page the entire module during load time. And it includes the information to choose which files and components are loaded in a virtual address space.

 

The .bib file consists of the three parts such as MEMORY, MODULES and FILES.

 

MEMORY section

 

MEMORY part of .bib file specifies the usuable system address information at OS, which is generally specified at Config.bib file. Each Board Support Package (BSP) includes one Config.bib. The following is an example for MEMORY part.

  

NK      80001000 01FFF000 RAMIMAGE

RAM    82000000 01DB0000 RAM

 

RAMIMAGE item causes Romimage.exe to lay out the running codes, modules, data files and compressed parts in the scope of 0x81FFFFFF at the virtual address of 0x80001000.

 

This virtual address physically coincides with RAM or Flashmemory.

 

RAM item specifies the available virtual address scope by Windows CE kernel for File system and Object Store space allocation, process virtual address space such as heap and stack, memory mapped file and writable data part.

 

MODULES section

 

The part of MODULES at .bib file provides Romimage.exe with the information on which files are included in the final OS image and how the files are loaded in the memory area specified at MEMORY part. Further below are the examples of MODULES part.

  

INIT.EXE       %_WINCEROOT%RELEASEINIT.EXE     NK SH

 

MYDLL.DLL    %_WINCEROOT%RELEASEMYDLL.DLL  NK SHC

 

 These items let Romimage.exe know to include ‘Init.exe’ and ‘Mydll.dll’ in OS image.

 

More specifically, they let Romimage.exe to deploy these two files at the part marked NK specified in the scope of RAMIMAGE of MEMORY part. 

 

The second module, ‘Mydll.dll’ has been specified with C flag to inform for Romimage.exe to compress this file. For further details refer to MODULES Section.

 

Romimage.exe, which is the one to compress Mydll.dll’ , lets kernel know that it is necessary to remove compression, and demand page, etc. is required with other run-time fix-up and RAM. If the compressed file is already at the part RAMIMAGE mapped with RAM, the two of ‘Mydll.dll’ will show up at RAM. However this compressed image can exist at the flash memory. 

 

FILES section

 

FILES part at .bib file is similar to the one of MODULES. However Romimage.exe basically compresses all the files defined at this item. FILES part generally includes data files in such an application process as waveform audio file(.wav) and bitmap(.bmp) file. The following is an example of FILES part to include ‘Initobj.dat’ file compressed by Romimage.exe in OS image.

 

INITOBJ.DAT     $(_FLATRELEASEDIR)RELEASEINITOBJ.DAT    NK     SH

 

Image Mapping

 

During OS run-time, in building the components are fetched from the address selected by Romimage.exe. These components can be either paged as RAM by OS loader, or executed in place(XIP) in such a memory as CPU with these components existing to approach.

 

Romimage.exe and .bib file shall establish from which location the components are fetched and how they are composed. More specifically, .bib file can control the division and layout of entire OS image. For example, it can divide components into individual areas and compose OS image, such as Nk.bin which includes kernel, file system and main components rather than single OS image, IE.bin which includes Internet Explorer related components, and app.bin which includes other application. OS image composed in this way enables each part to be updated, controls access to specified area, and provides additional method to connect components through paging or XIP.        

 

Single Image

 

Basically, Romimage.exe produces a single Nk.bin file. During run-time by OS loader this file  includes modules compressed to be paged by RAM, but others not compressed will be run by XIP in the range of address specified at MEMORY part of .bib file. When XIP area physically exists at RAM, and image is saved at such a non-volatile storage device as Flash memory, such a code as to copy to a correct RAM position defined at Config.bib from a non-volatile storage device is required. (Bootloader or OS Startup code)

 

When a part of image is updated, the entire Nk.bin file shall be updated. This method can be a little dangerous. For example, even if the only application seeks to be updated that is why Flash memory operation for entire OS image shall be performed. The best solution is to deploy applications periodically requiring being updated at divided image area. In addition to limiting linear flash memory of XIP during ⓤpdateof Flash memory, the application under run shall be finished, and the only application area updated. And without affecting rebooting and kernel the application can be run again.

 

Multiple Region Images

 

The layout of image can be finely adjusted into Multi-region image, and the regional ⓤpdatecan be controlled. And when components are paged during run-time based on each region how OS will approach this region can be determined. For instance, through low-level flash memory file system driver or FAT file system at flash memory the modules will be paged from the region by OS loader. In order to produce Multi-region image the modification of .bib file and OEM Adaptation Layer(OAL) source code is required.

 

Multiple region BIB changes

 

In order to specify several image regions and their positions the memory part of Config.bib file to describe starting address and length of each region shall be modified. The codes below show examples for this.

 

NK       80220000   008de000   RAMIMAGE

 

CHAIN    80afe000   00001000   RESERVED

 

EXT2      80aff000   00001000   RAMIMAGE

 

EXT       80b00000   00100000   RAMIMAGE

 

RAM      80c00000  01000000   RAM

  

Each item in the above MEMORY part informs Romimage.exe of the fact that the four regions such as NK, EXT2, EXT and CHAIN including kernel and main components of OS shall be produced. The size defining each region is the maximum one in these regions. When a region is updated, the code and data size can be increased up to the size defined at MEMORY part. Once Multi-region image is produced, in order to maintain compatibility with OSbuild in the future MEMORY size value cannot be changed. The above MEMORY item also shows RAM region which kernel controls the region of 0x81BFFFFF at 0x80C00000.  

 

Multi-region image requires CHAIN region belonged by chain file. The chain file is a list including information on each image region. Through OAL it can be used by kernel, which provides how to let OS know about files and modules forming each region. 

 

At MEMORY part in order to check where chain file has been deployed by Romimage.exe the fix-up variable used by OAL shall be defined. In this method you may not directly code the address at OAL. For reference the value designated at this variable shall be coincided with starting address in a defined CHAIN region.

 

The code below shows an example of how the starting address in CHAIN region, 0x80AFE000 is defined at LPDWORD pdwXIPLoc of OAL. 

  

 pdwXIPLoc 00000000 80afe000 FIXUPVAR

 

After defining fix-up variable, the item to let Romimage.exe know the location to be deployed by chain file shall be added to CONFIG part of .bib file, and the one to make automatic module image size also added. The codes below show example of items to be added to CONFIG part.

 

XIPSCHAIN=80afe000

 

DLLADDR_AUTOSIZE=ON

 

XIPSCHAIN variable shall indicate the starting address of CHAIN region defined at MEMORY part.

 

Finally it shall be decided at which region each component will be deployed by correcting .bib file. The codes below show example of .bib files with components divided by region.

 

pcmcia.dll       $(_FLATRELEASEDIR)ti1250.dll         EXT  SH

 ensoniq.dll      $(_FLATRELEASEDIR)ensoniq.dll        EXT  SH

 iesample.exe     $(_FLATRELEASEDIR)iesample.exe     EXT2 S

 

In the above examples of codes, ‘pcmcia.dll’ and ‘ensoniq.dll’ driver shall be deployed at EXT region. And ‘iesample.exe’ shall be deployed at EXT2 region. Like this by modifying part of MODULES and FILES at .bib file the component for many regions can be composed. Each region shall be produced as a .bin file including Table of Content(TOC) to describe information on each file in the region. The chain file also provides how to check the number of TOC’s in all the region. Therefore the kernel provides how to check the location of image file.


Multiple region OAL changes

 

Windows CE kernel will find out whether at the process of OAL initiation(at OEMInit) the multiple-regional image exists. The kernel allocates the structure arrangement of each region indicating TOC’s, and provides how to check all the files in each region by providing this pointer. The codes below show an example of how this process will become.

 

Ref : This example code uses pdwXIPLoc variable commented at Multiple region BIB Change.

 

#define NOT_FIXEDUP         (DWORD*)-1

 #define MAX_ROM             32 // Maximum number of regions.

 #define ROMXIP_OK_TO_LOAD   0x0001

  // ROM chain pointer exported by the kernel library

 extern ROMChain_t     *OEMRomChain;

  // Fix-up variable (corresponds to variable in Config.bib)

 DWORD *pdwXIPLoc = NOT_FIXEDUP;

  voidInitRomChain()

 {

     static ROMChain_ts_pNextRom[MAX_ROM] = {0};

     DWORD dwRomCount = 0;

     DWORD dwChainCount = 0;

     DWORD *pdwCurXIP = 0;

     DWORD dwNumXIPs = 0;

     PXIPCHAIN_ENTRY pChainEntry = NULL;

 
    // Verify that Romimage.exe fixed up chain file pointer

     if(pdwXIPLoc == NOT_FIXEDUP)

     {

         return; // No chain or not fixed up properly

     }

      // settle  top bit to mark it as a virtual address

     pdwCurXIP = (DWORD*)(((DWORD)pdwXIPLoc) | 0x80000000);

 

     // First DWORD is number of XIP regions.

     dwNumXIPs = (*pdwCurXIP);

  

    // Make sure number of XIP regions does not exceed our maximum

     if(dwNumXIPs > MAX_ROM)

     {

         lpWriteDebugStringFunc(TEXT("ERROR: Number of XIP regions exceeds

           the maximum.n"));

         return;

       }

 

     // Point to the first XIP region chain entry

     pChainEntry = (PXIPCHAIN_ENTRY)(pdwCurXIP 1);

  

    // Skip first entry because loader will add that in for

 

    // us (this is the kernel region)

     pChainEntry;

     dwChainCount;

     while (dwChainCount < dwNumXIPs)

     {

         // If region is a valid XIP region and signature

 

        // matches, then proceed.

         if ((pChainEntry->usFlags & ROMXIP_OK_TO_LOAD) &&

           *(LPDWORD)(((DWORD)(pChainEntry->pvAddr))

             ROM_SIGNATURE_OFFSET) == ROM_SIGNATURE)

         {

             s_pNextRom[dwRomCount].pTOC =

               *(ROMHDR**)(((DWORD)(pChainEntry->pvAddr))

                 ROM_SIGNATURE_OFFⓢet 4);

             s_pNextRom[dwRomCount].pNext = NULL;

             if (dwRomCount != 0)

             {

                 s_pNextRom[dwRomCount-1].pNext = &s_pNextRom[dwRomCount];

             }

             else

             {

                 OEMRomChain = s_pNextRom;

             }

             dwRomCount;

         }

         else

         {

            lpWriteDebugStringFunc(TEXT("Invalid XIP region found.n"));

         }

          pChainEntry;

    dwChainCount;

     }

     }

  

When InitRomChain function is paged by OEMInit, InitRomChain will register multiple XIP regions at kernel. And it provides a complete contents of entire image. For further details of InitRomChain check ROMChain_t and ROMHDR structure defined at the next route. 

 

%_WINCEROOT%PublicCommonOakIncRomldr.h.

 

Building and using multiple region images

 

When Multi-region image is built by so far checked setting, the five .bin files such as Chain.bin, Nk.bin, Ext.bin, Ext2.bin and Xip.bin are produced. The first four files include files allocated at each region defined. The last Xip.bin file is a compound image composed of the four(4) files, which is used for easily downloading at target device.

 

After downloading and saving the entire image at target device, subsequently .bin file only in a specific region can be downloaded and updated in each region. Through Bootloader the OS image can be downloaded and updated, by other method through the application of OS this kind of operation can be made.