Freigeben über


MEMORY Section (Windows CE 5.0)

The kernel requires a memory table to identify the following information:

  • A region of memory as either RAM or ROM
  • The amount of RAM available for applications

The MEMORY section of a .bib file, specified in Config.bib, reserves MEMORY regions by name. Each board support package (BSP) contains one copy of Config.bib.

The following code example shows the columnar format used in a MEMORY region entry.

  Name        Address        Size        Type

Parameters

  • Name
    Identifies the name of the MEMORY region.

    There is no naming convention for this string; however, the name must be unique.

    There is a predefined section name called RESERVE, which you can use multiple times. RESERVE specifies a hole in a ROM image.

    Another predefined section name is dwProfileBufferMax, which you can use to determine the maximum buffer size for the profiler by assigning it as a FIXUPVAR region.

  • Address
    Specifies the hexadecimal address in memory where the MEMORY region begins.

  • Size
    Specifies the size, in hexadecimal bytes, of the MEMORY region.

  • Type
    Specifies the type of memory.

    The following table shows the values for type of memory.

    Value Description
    FIXUPVAR Changes the value of a global kernel variable, and of kernel module variables, when Romimage is called.

    Romimage typically uses FIXUPVAR regions to fill in the location of the CHAIN file, but these can be used for other purposes.

    FIXUPVAR regions are case insensitive.

    NANDIMAGE Specifies that RAM should overlap these regions when building an run-time image that uses BINFS.

    The overlapping regions are stored in NAND but are fixed up to virtually appear as though they do not overlap.

    When the kernel accesses these regions, BINFS responds by intercepting the request. BINFS accesses NAND and returns the proper data to the kernel.

    This enables a device with NAND to execute in place out of NAND, freeing up RAM for use by the system.

    Romimage generates one binary (.bin) file for each NANDIMAGE entry.

    NANDIMAGE sections must be page aligned.

    RAM Specifies the range of virtual addresses available to the kernel for allocation to running processes and the RAM-based Windows CE-based file system. The region must be contiguous.

    Do not reserve memory in the middle of a RAM section. Doing so creates two noncontiguous regions of memory, which is the maximum supported by Windows CE.

    If you need to reserve memory in the middle of your RAM allocation, a portion of free RAM is reported in the Config.bib file and the rest is reported when the kernel calls OEMGetExtensionDRAM or pNKEnumExtensionDRAM.

    RAM sections must be page aligned.

    RAMIMAGE Specifies that the region should be treated like RAM. The memory addresses in this entry can physically correspond to RAM or to linear flash memory. This memory-type value is useful when loading the ROM image into RAM during the development process or when burning the run-time image onto a single ROM.

    The kernel copies all writable sections for an application into RAM and fixes the memory addresses prior to starting the application process.

    The name used to describe a RAMIMAGE section must be the same name used in the .bib file that specifies the modules and files to add to the run-time image.

    Romimage generates one .bin file for each RAMIMAGE entry.

    After you run Romimage, all noncompressed executable code is fixed up to run at a virtual address in slot 0, which is an address space created by the kernel.

    The actual source code resides in the address range specified in the corresponding RAMIMAGE entry.

    RAMIMAGE sections must be page aligned.

    RESERVED Specifies that a region of RAM or ROM is reserved.

    During run-time image creation, Romimage skips these reserved sections.

    This memory could be a video frame buffer or a direct memory access (DMA) buffer.

Example

The following code example shows a MEMORY region entry.

MEMORY 
  NK        9f800000  00800000  RAMIMAGE 
; Only specify one RAMIMAGE section
; Reserve 4K at reset vector for boot loader and diagnostics
  RESERVE    9fc00000    00001000
  RAM       80080000  00780000  RAM 
; Common RAM regions
  AUD_MDD    80002000  00000800  RESERVED
  DISPLAY    80008000  00013000  RESERVED
  DRV_GLB    80020000  00001000  RESERVED
  DBGSER_DMA  80022000  00002000  RESERVED
  SER_DMA    80024000  00002000  RESERVED
  IR_DMA    80026000  00002000  RESERVED

The memory region for NK starts at the address 0x9f800000 and is 8 MB.

The RAM entry indicates that the region should be treated like RAM and is located between the addresses 0x80080000 and 0x00780000. This region becomes available to the kernel for allocation to the file system or object store, process virtual address spaces such as heaps and stacks, memory mapped files, and writable data sections.

The RAM entry tells the ROM Image Tool (Romimage.exe) to place any executables, modules, data files, and compressed sections in this region.

When Romimage executes, all noncompressed executable code is fixed up to run at a virtual address in slot 0, which is an address space created by the kernel, while the actual code is located in the region specified in the RAM entry.

Six memory regions are specified as reserved. These include the audio DMA buffer, AUD_MDD, the display-frame buffer, DISPLAY, and the driver global memory region, DRV_GLB.

The six memory regions are used, but are not part of the run-time image or RAM space.

In the MEMORY section, you can also specify a memory region that is not filled with run-time image data. This memory region uses the memory name RESERVE and specifies no memory type name.

This option is useful for implementing OEM diagnostics at the reset vector. In the previous example, 4 KB of run-time image space is reserved, starting at the address 0x9fc00000.

See Also

Binary Image Builder File | OEMGetExtensionDRAM | pNKEnumExtensionDRAM

Last updated on Thursday, February 02, 2006

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.