In previous posts, I have discussed bib files but focused on the areas that probably are modified the most during platform development, those being the FILES and MODULES sections. In this post I will look deeper into config.bib which typically contains the MEMORY and CONFIG sections.
To start with let’s examine the simplified config.bib below. This is actually the Windows CE 6.0 MainstoneIII config.bib, but I processed it to make it more readable.
MEMORY
 
;   Name             Start          Size           Type
;   -------          --------       --------       ----
    RSVD             80000000       000FF000       RESERVED     ;0x8000_0000 -> 0x8010_0000 (1MB EBOOT RAM & ARGS)
    ARGS             800FF000       00001000       RESERVED
 
    NK               80100000    03000000    RAMIMAGE
    RAM              83100000 00F00000      RAM
 
    ZBANK            9A500000       00100000       RESERVED     ;Reserve ZBANK virtual block (No physical memory
                                                                ;is required to back this virtual range).
 
    EBOOT            9AA00000       00040000       RESERVED     ;EBOOT Flash image
    BOOTCFG          9AA40000       00040000       RESERVED     ;BOOT config parameters
 
CONFIG
    AUTOSIZE=OFF
    KERNELFIXUPS=ON
   COMPRESSION=ON
    PROFILE=OFF
    ROMFLAGS=00
 
MEMORY Section
The MEMORY section defines the ROM section that contains the OS image and the RAM to be used by applications. 
The ROM section can be either ROM or RAM addresses. The decision is up to the OEM and will be based on whether the system should run eXecute In Place (XIP) from ROM or from RAM. There are arguments for doing both. 
The RAM section defines the working RAM that the system can use. You may need to set aside RAM for special purposes, like DMA and display buffers, so the RAM set here may not include the entire RAM in the system. The RAM set up here must reside in contiguous addresses. For more on handling noncontiguous sections of RAM see Platform Builder: Handling Noncontiguous RAM.
The MEMORY section starts with the MEMORY keyword:
MEMORY
Then includes memory defininitions in the form of:
                <Identifier> <Virtual Start Address> <Size> <Memory Type>
·         Identifier – a unique name given to the memory definition. This name can be used in FILES and MODULES sections of the bib files to specify that the file is to be place in the named memory area. You will see this most often in the OS image bib files as NK.
·         Virtual Start Address – this specifies the starting address for this memory definition. This should be specified as a virtual address.
·         Size – the number of bytes for this memory definition
·         Memory Type – a predefined memory type. This should be one of:
o   RAM – specifies that this memory definition defines the RAM that the OS will use for the Object Store. The MEMORY section should set up only one instance of RAM. This must be a contiguous block of RAM. For more see: Platform Builder: Handling Noncontiguous RAM
o   RAMIMAGE – specifies the address and size of the OS image at runtime.
o   RESERVED – used to document address usage in the system
o   NANDIMAGE – used to specify address and size of binfs file system
o   FIXUPVAR – used to change, or fix up, a kernel variable when romimage creates the OS image
Looking at a few of the settings in the config.bib above we see that there is 1K of SRAM set aside for the boot ARGS. I know that this is SRAM because I looked in the OEMAddressTable to see how the virtual address 0x800FF000 is allocated.
    ARGS             800FF000       00001000       RESERVED
Then 48MB of SRAM is defined for the OS image itself. This will be run in RAM, but to run from ROM change the address to a ROM address.
    NK               80100000    03000000    RAMIMAGE
Then the RAM to be used by the OS is defined. This sets up 15MB.
    RAM              83100000 00F00000      RAM
The addresses are not some voodoo magic, they do require some work on the part of the OEM. To establish the addresses, define the physical memory map of the system and then assign virtual addresses in the 2GB from 0x80000000-0x9FFFFFFF which is the kernel’s cached virtual address space. Once you understand the system’s address map, the rest is actually easy.
For those of you who have already looked at config.bib in the Windows CE 6.0 MainstoneIII platform, you have probably noticed that to create the simplified config.bib I removed some things of interest for the MEMORY section. Let’s look at a few of them now that we have some basics.
Using defines to set the NK address and size:
IF IMGFLASH !
 #define NK_START      80100000
 #define NK_SIZE       03000000
ELSE ;IMGFLASH
 #define NK_START      9AA80000
 #define NK_SIZE       03F00000    ; 0x9AB0_0000 -> END (63MB FLASH)
ENDIF ;IMGFLASH
 
MEMORY
    NK               $(NK_START)    $(NK_SIZE)     RAMIMAGE
This uses the environment variable IMGFLASH to determine if the OS should run from ROM or SRAM. The #define works similar to the C/C++ preprocessor macro definitions. In this case two macros are define; NK_START and NK_SIZE. These are then used to define the RAMIMAGE using the dereference operator $().
Using FIXUPVAR to modify variable values when creating the OS:
    nk.exe:dwOEMDrWatsonSize 00000000   0x4B000               FIXUPVAR
This tells romimage to replace the initial value of dwOEMDrWatsonSize in nk.exe. The syntax is new to Windows CE 6.0. In previous versions, this would be:
    dwOEMDrWatsonSize 00000000   0x4B000               FIXUPVAR
 I haven’t tested this yet, but I think that the new syntax for Windows CE 6.0 might mean that variable in files other than nk.exe can be changed. Prior to Windows CE 6.0 only variables in the kernel (nk.exe) could be fixed up.
CONFIG Section
The CONFIG section tells romimage information about how to create the OS image. The CONFIG section includes variables assigned a value. Looking at the variables in the MainstoneIII config.bib:
·          AUTOSIZE=OFF
AUTOSIZE tells romimage to include any unused memory from RAMIMAGE in the RAM section. This can give the system more RAM. Of course the opposite is also true, if the OS image is larger than the RAMIMAGE size, romimage will use some of the RAM section for the OS. AUTOSIZE should only be set when the OS is to run from RAM.
·         KERNELFIXUPS=ON
KERNELFIXUP tells romimage that it should fixup locations that the kernel can write. (I don’t understand either) The default value is ON.
·         COMPRESSION=ON
COMPRESSION tells romimage whether it should compress files in the image. This is usually set to ON to reduce the overall OS image size.
·         PROFILE=OFF
PROFILE tells romimage whether to include profiler structures in the OS image.
·         ROMFLAGS=00
ROMFLAGS consolidates some other settings as a set of bit mapped flags. The ROMFLAGS settings are:
·         0x00000001 – disables demand paging
·         0x00000002 – disables full kernel mode. I suspect that this no longer applies to Windows CE 6.0.
·         0x00000010 – Trust mode, only trust modules in the MODULES section
·         0x00000020 – (x86 only) disable flushing on soft TLB
·         0x00000040 – if the /base linker option is used on a dll, romimage should honor that setting
 
 
There are some other CONFIG settings not used in the MAINSTONEIII when the image is in ROM. These are used to create an nk.nb0 file to be JTAG’ed to the ROM and include:
·         ROMSTART = 9AA80000               
ROMSTART sets the starting address of the ROM image            
·         ROMSIZE = 03F00000
ROMSIZE sets the size of the ROM image
·         ROMWIDTH = 32
ROMWITH can be set to 32 or 16. The setting used depends on the bus width that the ROM is on.
This should get you started working with config.bib.   There are some topics like NANDIMAGE that I did not delve into. The settings discussed here are for basic configuration of the OS Image.
You may also want to look at my Summary of BIB File Posts
Tags: 
Copyright © 2008 – Bruce Eitman
All Rights Reserved