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. The config. bib file config. bib 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. Example of bib file memory segment: memory; name start address size attribute reserved 80000000 00008000 reserved drv_glb 80008000 00001000 reserved CS8900 80010000 00030000 reserved edbg 80040000 00080000 reserved NK 800c0000 00740000 ramimage Ram 81000000 00800000 Ram name can be any string in principle, romimage determines the purpose of a memory slice based on its attributes. 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 you change NK to another name, you need to change this NK string in all the bib files in the system. 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. In the config section, pay special attention to the following: 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 other oemaddresstable are 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: typedef struct {ulong ulvirtualaddress; ulong ulphysicaladdress; ulong ulsizeinmegs;} addresstablestruct; # define Meg () (A-1)> 20) + 1) const addresstablestruct oemaddresstable [] ={{ sdram_virtual_memory, // virtual address limit, // physical address Meg (sdram_main_block_size) // The 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 a virtual address, and the second member is the corresponding physical address, the last member is the size of 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. If the processing of discontinuous memory exists physically consecutive, The oemaddresstable can map the memory address only one by one. 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: config. The memory section of the bib file is as follows: Memory reserved 80000000 00008000 reserved drv_glb 80008000 00001000 reserved CS8900 80010000 00030000 reserved edbg 80040000 00080000 reserved NK 800c0000 00940000 ramimage Ram 81800000 00800000 RAM in this 32 m space, BSP retains the first 0 x 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 slice, which only occupies the last 8 MB of space. As mentioned above, in such a physical memory discontinuous system, the RAM slice cannot span two physical memory blocks, therefore, it is designed to only occupy the last physical memory in the system, while the other two are occupied by oemenumexten Siondram is reported to the system at runtime. The function content is as follows: 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 system memory is activated, and the available system memory becomes 8 + 8 + 6 = 24 m, you can define RAM as any of the three parts, and report the other two parts 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, memory usage indicates that 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.