OEMAddressTable (Compact 2013)
10/16/2014
This array of structures defines physical-to-virtual address mappings that the boot loader and kernel require for system startup in an x86 or ARM platform.
Syntax
typedef struct {
UINT32 CA;
UINT32 PA;
UINT32 size;
} OAL_ADDRESS_TABLE, *POAL_ADDRESS_TABLE;
Members
Member |
Description |
|---|---|
CA |
Cached virtual address that begins the memory range. |
PA |
Physical address that begins the memory range. |
size |
Size of the memory range, in MB for ARM platforms and in bytes for x86 platforms. Must be a multiple of 4 MB for x86-based platforms and a multiple of 1 MB for ARM. |
Remarks
You can use any name for the table; two names that developers commonly use are OEMAddressTable and g_oalAddressTable. The table must be in the esi register when the x86 StartUp function jumps to KernelStart, or the r0 register when the ARM StartUp function jumps to KernelStart.
In Windows Embedded CE 6.0, OEMAddressTable defined all static mappings for a platform, cached and uncached. In Windows Embedded Compact 2013, this table only defines the address mapping required for system startup, and the memory defined in it will only be mapped as cached. The data must be declared in a READONLY section, and there must be at least one nonzero entry for the structure to be valid. OEMAddressTable typically contains one or two entries: one for RAM and one for ROM (if the ROM is execute-in-place (XIP) flash memory).
Device mappings must be declared in OEMDeviceTable. If you have an OEMDeviceTable, the first entry of the OEMAddressTable must point to your OEMDeviceTable using the following syntax.
CE_NEW_MAPPING_TABLE, <OEMDeviceTable>, 0
Important
<OEMDeviceTable> must be replaced with a pointer to your OEMDeviceTable.
If you are not using a OEMDeviceTable, the first entry of OEMAddressTable must identify RAM, and it must start at 0x80000000. For ARM-based hardware, 0x80000000 can map to anything.
The last entry of the table must be set to 0 (zero). You can leave gaps between ranges, but you cannot have overlapping ranges.
The only valid virtual memory mapping range is from 0x80000000 to 0x9FFFFFFF.
For every entry created in the table, the kernel creates a cached mapping in the 0x8000000-0x9FFFFFFF space.
Note
If you modify the RAM entry in OEMAddressTable, you must update Config.bib to use the new memory mapping.
Any memory that is not mapped at system startup cannot be directly accessed by an interrupt service routine (ISR) without first calling CreateStaticMapping to map the address.
Note
On CPUs with ARMv7 architecture, conflicting cache attributes are not supported. On devices that support CPUs with ARMv7 architecture you must use OEMAddressTable to map cached addresses and use OEMDeviceTable to map uncached addresses. For more information, see "Freeing Virtual Address Space in the Kernel" in this document.
Code Example
The following code example shows an implementation of OEMAddressTable for x86-based hardware platforms, which have the restriction of VA 0x80000000 = PA 0x00000000. ARM-based hardware platforms do not have this restriction.
Important For readability, the following code example does not contain security checking or error handling. Do not use the following code in a production environment.
public _OEMAddressTable
_OEMAddressTable:
;
; OEMAddressTable defines the mapping between Physical and Virtual Address
; o MUST be in a READONLY Section
; o First Entry MUST be RAM, mapping from 0x80000000 -> 0x00000000
; o each entry is of the format ( VA, PA, cbSize )
; o cbSize must be multiple of 4M
; o last entry must be (0, 0, 0)
; o must have at least one nonzero entry
; RAM 0x80000000 -> 0x00000000, size 64M
dd 80000000h, 0, 04000000h
; FLASH and other memory, if any
; dd FlashVA, FlashPA, FlashSize
; Last entry, all zeros
dd 0 0 0
Freeing Virtual Address Space in the Kernel
You can free additional virtual address space in the kernel by defining an OEMDeviceTable structure. For more information, see OEMDeviceTable.