Actual memory (bib) Configuration

Document directory

• Actual memory (bib) Configuration

Actual memory (bib) Configuration

Bib, memory, practice

Memory configuration of WinCE
The memory (including SDRAM and flash) configuration of Wince includes two aspects: definition in source code (including C and assembly) and definition in system configuration file config. bib. In the source code, you need to define the physical and virtual addresses and sizes of the memory, and initialize a structure array named oemaddresstable to inform the System of the relationship between the physical addresses and virtual addresses, the system generates the MMU page table based on its settings. In config. bib, the memory is generally defined as different segments, and each segment is used for different purposes.
Config. bib File
The config. bib file is divided into two parts, which are called segments, memory segments, and config segments. The memory segment defines the memory sharding method, and the config segment defines some other attributes of the system. The following is a config. Bib file memory segment example:
Memory
Name start address size attribute
Reserved 80000000 00008000 Reserved
Drv_glb 80008000 00001000 Reserved
CS8900 80010000 00030000 Reserved
Edbg 80040000 00080000 Reserved
NK 800c00000 00740000 ramimage
Ram 81000000 00800000 Ram
In principle, the name can take any string, and romimage determines its purpose through the attribute of a memory chip. The reserve attribute indicates that the memory of the film is used by BSP, and the system does not need to care about its purpose. ramimage indicates that it is a piece of memory for storing OS images, while Ram indicates that some pieces of memory are Ram, the system can allocate space and run programs.
However, do not change the name of the memory that stores the Rom, that is, NK. This name is used when the bib file defines the Rom to which a file is attached (wince supports storing the ROM image in several discontinuous memory films, the following section defines touch in the bib file. DLL is placed in the Rom named NK,
Touch. dll $ (_ flatreleasedir) \ touch. dll NK sh
Therefore, if NK is changed to another name, the NK string in all bib files in the system needs to be changed.
Note: ensure that the memory of each device is not overlapped, and leave no holes in the middle to save memory. If the two devices cannot be loaded at the same time, they should be kept with only one piece to save memory. For example, in this example, cs8950 is retained for the NIC Driver and edbg is retained for the NIC for debugging (kitl, the system is designed that these two programs will not be loaded at the same time (cs8950 determines that edbg will automatically exit if it is running at startup ), it is a waste and unnecessary to keep one piece of memory for the two drivers.
A Ram slice must be physically consecutive. If the system's physical memory is divided into several slice, only one slice can be declared on the ram slice, the other inactive phase is reported to the system by oemgetextensiondram. If there is more than one memory chip, oemenumextensiondram should be used for reporting. There is no limit on NK chips. When NK spans more than two physical memory slices, the OS package will be displayed when the system starts to span multiple physical memory slices. This is considered an error, however, this does not affect system execution and stability, because MMU is opened when the system is started, and the virtual address is used to view the continuous memory space. Of course, if the kernel itself is put on two memory chips, the system will not be able to start. Other reserved memory disks are generally used for the driver DMA and should ensure their physical continuity, because the DMA uses the physical address directly.
Note the following in the config section:
Romstart, which defines the starting position of the RoM. It should be the same as the starting position of the NK disk.
Romsize, which defines the ROM size. It should be the same as the NK disk size.
If you do not need NK. Binfile, you can not set these two values.
Romwidth, which only defines how the file is organized when romimag generates the ROM package, rather than its literal meaning: the width of the RoM, so generally it should be 32
Compression, generally defined as on, to enable the compression function to reduce the size of the binfile.
Autosize, usually set to on, so that the system uses the memory defined for Rom but not used as Ram, and increases the RAM usage. Note: If the Rom is flash, it cannot be set to on, because Flash cannot be used as Ram.
Romoffset, which defines the difference between the physical address and virtual address of the OS starting position (that is, romstart). This definition is not used in some BSP.
Oemaddresstable and others
Oemaddresstable is used to initialize the ing between virtual addresses and physical addresses of various devices in the system. In my BSP, it is defined and initialized as follows: copy the content to the clipboard code:
Typedef struct
{
Ulong ulvirtualaddress;
Ulong ulphysicaladdress;
Ulong ulsizeinmegs;
} Addresstablestruct;
# Define Meg (A) (A-1)> 20) + 1)
Const addresstablestruct oemaddresstable [] =
{
{Sdram_virtual_memory,/virtual address
Physical_addr_sdram_main,/physical address
Meg (sdram_main_block_size)/size of the space in MB
},
...........................
{
0,
0,
0
}
}; As shown in the example, oemaddresstable is a structure array. The first member of each item is the virtual address, the second member is the corresponding physical address, and the last member is the size of the space in the segment. The last entry of this array must all be 0 to show the end of the entire array. When the kernel starts, it will read the content of this array to initialize the MMU page table, enable MMU, and enable the program to access the device with a virtual address. Of course, each physical address and virtual address used in oemaddresstable must be defined in the header file. The files defining these values in each BSP are different. Therefore, the specific file cannot be specified here, readers can refer to the specific BSP documentation and code.
Processing of discontinuous memory
If the physical connection is continuous, the oemaddresstable can map the memory address only by one entry. However, if the BSP runs on a physically discontinuous system of the sdram, more items are required in the oemaddresstable to map the SDRAM to a continuous virtual address, of course, they can also be mapped to discontinuous virtual addresses, but it seems that there is no reason to do so. In addition, the system needs to do more work when the physical address is not continuous. For example, I have such a system: 32 M SDRAM, 16 M Flash, and SDRAM are physically discontinuous. They are divided into 4 8 M memory blocks, as shown in the usage of my SDRAM:
The memory section of the config. bib file is as follows: copy the content to the clipboard code:
Memory
Reserved 80000000 00008000 Reserved
Drv_glb 80008000 00001000 Reserved
CS8900 80010000 00030000 Reserved
Edbg 80040000 00080000 Reserved
NK 800c00000 00940000 ramimage
Ram 81800000 00800000 RAM in this 32 m space, BSP retains the first 0x80000 bytes, followed by NK, which occupies 0x940000 bytes and spans two memory slices, these are not much different from other BSP settings. Next, let's take a look at the RAM chip, which only occupies the last 8 m space. As mentioned above, in this physical memory discontinuous system, A Ram slice cannot span two physical memory blocks. Therefore, it is designed to only occupy the last physical memory slice in the system, while the other two are reported to the system by oemenumextensiondram at runtime, the content of this function is as follows: copy the content to the clipboard code:
Pmemsections [0]. dwflags = 0;
Pmemsections [0]. dwstart = (sdram_virtual_memory + 0x1000000 );
Pmemsections [0]. dwlen = 0x800000;
Pmemsections [1]. dwflags = 0;
Pmemsections [1]. dwstart = (sdram_virtual_memory + 0x0a00000 );
Pmemsections [1]. dwlen = 0x600000;
Return 2; in this way, all the memory of the system is activated, and the available memory of the system becomes 8 + 8 + 6 = 24 m. You can define RAM as any of the three parts, the other two pieces are reported in oemenumextensiondram. However, putting RAM on the last physical memory has a major advantage: If NK becomes larger, for example, when compiling a debug system, you only need to comment out the content in oemenumextensiondram, config. the bib file can be run without any changes, but the makeimg will warn that the system package is too large to run, but it does not affect the system execution and stability, because the memory after NK is not used, it is occupied by the system with a high increase, which is extremely convenient for debugging.
If the physical memory of the system is continuous, it will become much simpler. For example, if the 32 m sdram is physically continuous, the memory usage can be expressed as follows:
The available memory of the owner system can be defined in Ram.
If you do not know much about hardware, please note: whether the SDRAM is physically continuous or not has nothing to do with a few pieces of SDRAM on our board. You should ask the hardware engineer about the address distribution of the sdram.