Multiple XIP Regions (Windows Embedded CE 6.0)
1/6/2010
Execute-in-place (XIP) regions are areas where an application can run code directly from ROM, rather than having to load it from RAM.
You can construct multiple XIP regions in a single system. In this way, you can use XIP capabilities while using more than one memory area. For example, you could install the core OS features into ROM, and install the other OS features into flash memory. XIP applications could run in both places. You can still upgrade the flash region as needed. However, the XIP region of memory must be read-only.
You can chain together as many ROM regions as you want. Each time you add a ROM region, the kernel may replace another ROM region. The kernel does not physically replace the module, but replaces its functionality with a new module in a separate ROM region. The order you define for your ROM regions determines the order in which the OS overwrites modules. The ROM region that contains Nk.exe is at the bottom of the list, and the kernel adds new regions to the top of the list. This enables you to replace all modules in the original image, except Nk.exe, by linking to another ROM region.
To add a ROM region to an existing run-time image, create a new .bib file that lists the modules that you want to add to or replace in an existing OS design. To add a new .exe file or replace an existing one, add the .exe file to the .bib file.
You must make an additional entry in the .bib file when you add or modify a DLL. In Windows Embedded CE, all DLLs load from the top down in the virtual memory process space. Because Windows Embedded CE loads all DLLs for a specified .exe file in the same address location, the MODULES section of the .bin file reserves the same amount of virtual memory space for all DLLs. For any specified process, the system either loads the same DLLs to the process address space or reserves space to load later. When you use Makeimg.exe to build a ROM image, it generates the starting and ending addresses of all DLLs in the image. The following code example shows a sample DLL address generated by Makeimg.exe:
First DLL Address: 01f90000h
Last DLL Address: 02000000h
You must include an entry in the CONFIG section of the new .bib file, under the DLLHIGHADDR declaration, that specifies the start address for all DLLs in the associated ROM image. This start address is the lowest address allocated for DLL virtual memory space in the original .bin file. In the new .bin file, Makeimg.exe lists the starting address at which the system can begin reserving and loading virtual memory. The system reserves memory from the starting address down. The following code example shows a sample DLL start address generated by the new .bin file:
DLLHIGHADDR=0x01f90000
Be sure that your XIP regions do not overlap. If they do, the system does not run correctly. You can leave gaps between DLL regions without causing system problems, but this decreases the amount of virtual memory available to a process. Because the kernel reserves the same amount of virtual memory space for all ROMs and loaded DLLs, the kernel never uses memory in a gap between the DLLs. You can also use the gap to expand a ROM image's DLLs without having to rearrange any ROM images that follow. For example, if your main ROM's DLLs end at 0x01f00000, you could start your next ROM's DLLs at 0x01f00000. If your second ROM's DLLs end at 0x01e00000, you might begin your third ROM's DLLs at 0x01d00000, which would allow the second ROM to grow without affecting the third ROM.
This variable contains a chain of ROM pTOC pointers, which point to a table of contents. The kernel is stored in the ROM located at offset ROM_SIGNATURE_OFFSET + 4 with a DWORD signature ROM_SIGNATURE stored at ROM_SIGNATURE_OFFSET.
The kernel can leave a DLL out of an image altogether, even if the DLL is implicitly linked to another module. Romimage.exe prints a warning about the missing DLL, but still builds the image. This enables you to load the missing DLL from the RAM file system or the Target Control shell.