| Understanding Windows CE's VirtualSetAttributes function |
by Kurt Kennett (Mar. 22, 2007)
Foreword: In this brief technical note, Windows CE developer Kurt Kennett looks at how virtual memory is used to map peripheral registers into a Windows CE process. He points out that peripheral registers often have "attributes" that exhibit behavior different from ordinary memory. The VirtualSetAttributes function takes care of this.
Understanding VirtualSetAttributes
by Kurt Kennett
Virtual Memory is fantastic. It allows you to create this personalized "view" of the memory space of a computer, and rearrange where things are physically to suit your desires. This is especially good for the organization of registers of memory-mapped peripherals. By allocating a range of virtual memory, and mapping that memory onto a physical register bank, you get a pointer to a C-like structure containing fields that correspond to each register.
This procedure is fairly straightforward, and allows easy access to the hardware registers of many types of CPUs and peripherals in a Windows CE system. Usually this is accomplished via one of two mechanisms: - VirtualAlloc() + VirtualCopy() / VirtualFree()
- A range of virtual address space is allocated that can map the physical space needed
- The virtual to physical mapping is set up for those pages
- When necessary, the range of virtual pages is released and the mapping destroyed
- MmMapIoSpace() / MmUnmapIoSpace()
- This effectively does the first two steps above in one function call, with fixups on the address if it is not page-aligned.
The functions in (1) are exported to all drivers and applications. The functions in (2) are implemented as part of the CEDDK (CE Driver Development Kit), and are customizable for any particular platform.
With some new processor systems, it becomes optional and sometimes necessary to set "attributes" on virtual memory pages that map specific portions of physical memory. This is done to set qualities on the physical resources that are mapped. For example, TLB (Translation Lookaside Buffer) entries for a set of virtually mapped pages may need to be configured with specific attributes in order to allow a particular bus on the system to access the memory. If an operating system has segmented data and code areas, it can set the "no execute" bit to make sure the CPU doesn't fetch instructions from data regions. Another example is ARM's TrustZone technology, which uses a "secure" bit to establish privilege on certain memory regions. One of the most common examples is a display buffer, where you do not want to cache writes to a frame buffer, but want to use a hardware write buffer instead.
To allow this type of customization, the VirtualSetAttributes() function is provided. This allows us to manually call the function after the sequence in (1) above, or automatically in the function provided by an OEM in (2). Using the mechanism in (2) is more desirable, as it leads to more portable code (less specificity with regard to setting attributes for an end system in driver code). However, using (2) does not easily allow for multiple register banks to be allocated in one virtual page (leading to waste of virtual address space). Depending on your needs, you can use whichever method you desire.
By default the memory system is generic and does not know which buses are used to access a particular piece of physical memory. Because of this, if the default flags are used, a peripheral bus might not be accessed properly. You can set the attributes properly for your particular system by using the VirtualSetAttributes(). For example:
/* allocate dwBytes of virtual address space */
void *pVirtMem = VirtualAlloc(NULL,
dwBytes,
MEM_RESERVE,
0);
/* map the memory to physical address 0x10000000 (arbitrary) */
VirtualCopy(pVirtMem,
(void *)(0x10000000>>8),
dwBytes,
PAGE_PHYSICAL | PAGE_READWRITE | PAGE_NOCACHE);
/* set the attributes on the pages */
VirtualSetAttributes(pVirtMem,
dwBytes,
0x13,
0x13,
NULL); |
The attributes on the set of pages mapping the physical address would now have the bits 0x13 set, to allow for possible use of a specific bus that holds the physical peripheral. The use of 0x13 is arbitrary here, because these flags are CPU-architecture specific. Consult the appropriate documentation for your CPU architecture to learn what each bit does in your page table entry. You might accidentally change the physical page number, which could cause some unexpected behavior! Caveats, and more information on the arguments to the virtual memory functions discussed here, can be found on MSDN help.
Copyright (c) 2007 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows CE Base Team Blog, here.
 About the author: Kurt Kennett is a development lead on the Windows CE base team responsible for drivers and forward-looking technology, including both OAL and bootloader design and implementation. His previous industry experience included stints at Electronic Arts, General Electric, Nortel Networks, and Intrinsyc Software. When not playing with computers, Kennett does science fiction/fantasy writing as well as some romance writing. Some of his work has over 25,000 readers on the Internet.
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Windows is a trademark or registered trademark of Microsoft Corporation in the United States and/or other countries and is used by WindowsForDevices under license from owner. All other marks are the property of their respective owners. WindowsForDevices is an independent publication not affiliated with Microsoft Corporation.
news feed