How to access physical memory in Windows CE -- reprinted

How to access physical memory in Windows CE

Reprinted from http://www.cppblog.com/milkyway/articles/18269.html

A significant difference between an embedded device and a desktop PC is that its applications usually need to directly access a certain segment of physical memory, which is particularly important for the driver to access the physical memory, especially in the ARM architecture, I/O ports are mapped to a physical memory address. Therefore, compared with windows, Windows CE provides a relatively simple physical memory access method. Both drivers and applications can access a certain piece of physical memory through APIS.
Some functions of Windows CE need to use the physical memory structure physical_address. Windows CE defines physical_address in ceddk. H. It is actually of the large_integer type and its definition is as follows:
// In ceddk. h
Typedef large_integer physical_address, * pphysical_address;
// In winnt. h
Typedef union _ large_integer {
Struct {
DWORD lowpart;
Long highpart;
};
Longlong quadpart;
} Large_integer;
It can be seen that 64 bits are used in Windows CE to represent the physical address. For most 32-bit CPUs, you only need to set its highpart to 0.
If you want to directly access the physical memory of an address, Windows CE provides the virtualalloc () and virtualcopy () functions. virtualalloc is responsible for retaining a segment of virtual memory in the virtual memory space, virtualcopy is responsible for binding a piece of physical memory to the virtual memory. In this way, the access to the physical memory is still performed through the Virtual Address. Their declaration is as follows:
// Apply for Virtual Memory
Lpvoid virtualalloc (
Lpvoid lpaddress, // The starting address of the expected virtual memory
DWORD dwsize, // size in bytes
DWORD flallocationtype, // application type, which can be reserve or commit
DWORD flprotect // access permission
);
// Bind the physical memory to the virtual address space
Bool virtualcopy (
Lpvoid lpvdest, // target address of the virtual memory
Lpvoid lpvsrc, // physical memory address
DWORD cbsize, // the size to bind
DWORD fdwprotect // access permission
);
Virtualalloc can apply for Virtual Memory in two steps: retain mem_reserve and submit mem_commit. Mem_reserve only retains a segment of the virtual address space of the process and does not allocate the actual physical memory. Therefore, the reserved virtual memory cannot be directly used by applications. In the mem_commit stage, physical memory is allocated to the virtual memory.
The following code shows how to use virtualalloc and virtualcopy to access the physical memory. Because virtualcopy is responsible for binding a piece of physical memory to the virtual memory, virtualalloc only needs to retain the memory and there is no need to submit it.
Fpdriverglobals =
(Pdriver_globals) virtualalloc (
0,
Driver_globals_physical_memory_size,
Mem_reserve,
Page_noaccess );
If (fpdriverglobals = NULL ){
Errormsg (driver_error_msg, (text ("virtualalloc failed! /R/N ")));
Return;
}
Else {
If (! Virtualcopy (
(Pvoid) fpdriverglobals,
(Pvoid) (driver_globals_physical_memory_start ),
Driver_globals_physical_memory_size,
(Page_readwrite | page_nocache ))){
Errormsg (driver_error_msg, (text ("virtualcopy failed! /R/N ")));
Return;
}
}
Ceddk also provides the mmmapiospace function to map a piece of physical memory directly to the virtual memory. The memory applied for with mmmapiospace must be released with mmunmapiospace. The original form of this function is as follows:
Pvoid mmmapiospace (
Physical_address physicaladdress, // The starting physical address.
Ulong numberofbytes, // number of bytes to be mapped
Boolean cacheenable // whether to cache
);

Void mmunmapiospace (
Pvoid baseaddress, // starting virtual address returned by mmmapiospace
Ulong numberofbytes //
);
In fact, the mmmapiospace function also calls the virtualalloc and virtualcopy functions to map physical addresses to virtual addresses. The original code of the mmmapiospace function is public, which can be obtained from % _ winceroot %/public/common/oak/Drivers/ceddk/ddk_map/ddk_map.c. We can also see the usage of virtualalloc and virtualcopy from the implementation of mmmapiospace:
Pvoid mmmapiospace (
In physical_address physicaladdress,
In ulong numberofbytes,
In Boolean cacheenable
)
{
Pvoid pvirtualaddress; ulonglong sourcephys;
Ulong sourcesize; bool bsuccess;

Sourcephys = physicaladdress. quadpart &~ (Page_size-1 );
Sourcesize = numberofbytes + (physicaladdress. lowpart & (page_size-1 ));

Pvirtualaddress = virtualalloc (0, sourcesize, mem_reserve, page_noaccess );
If (pvirtualaddress! = NULL)
{
Bsuccess = virtualcopy (
Pvirtualaddress, (pvoid) (sourcephys> 8), sourcesize,
Page_physical | page_readwrite | (cacheenable? 0: page_nocache ));

If (bsuccess ){
(Ulong) pvirtualaddress + = physicaladdress. lowpart & (page_size-1 );
}
Else {
Virtualfree (pvirtualaddress, 0, mem_release );
Pvirtualaddress = NULL;
}
}
Return pvirtualaddress;
}
In addition, Windows CE also provides the allocphysmem function and freephysmem function to apply for and release a continuous physical memory. The function can ensure that the applied physical memory is continuous. If the function succeeds, the virtual memory handle and the starting address of the physical memory are returned. This is especially useful for DMA devices. I will not go into details here. Readers can refer to the Windows CE online documentation.