Mapping physical to virtual address

PVOID MmMapIoSpace(
　　 IN PHYSICAL_ADDRESS PhysicalAddress,
　　 IN ULONG NumberOfBytes,
　　 IN MEMORY_CACHING_TYPE CacheType
);

//----example:
PHYSICAL_ADDRESS RegPA;
ULONG uBase;

RegPA.QuadPart = 0xA0000000;
uBase = (ULONG)MmMapIoSpace(RegPA, 4, 0);

//----

//Header: CEDDK.h
//Link Library: CEDDK.lib

出現link error的話，把ceddk.lib的path加到
Project -> Settings -> Link的object/library modules應該就可以過了

from WinCE driver and BSP Develop blog
驅動開發過程中可能遇到以下幾種與內在訪問相關的情況:

1.CPU訪問設備寄存器:
在ARM中可以直接將設備的寄存器映射到ARM的存儲空間中,我們需要使用幾個函數將硬體寄存器位址映射到系統空間:
如果已知硬體的虛擬位址,可以使用VirtualAlloc,VirtualCopy,
如果已知硬體的物理位址,需要使用MmMapIoSpace映射.

2.CPU與DMA或其他硬體交換資料。
DMA需要使用物理位址,因為DMA訪問記憶體時不會向CPU一樣先經過MMU,所以它使用物理位址。如果硬體需要與CPU交互資料，比如CPU需要將圖像畫到LCD控制器使用的記憶體中，LCD才會將其顯示出來。我們在設置硬體硬體時需要將CPU使用的虛擬位址轉換成物理位址，再告訴硬體物理位址。通常有以下幾種辦法：

1． 為該硬體保留一塊記憶體空間。一般用於記憶體使用量比較大的，且位址不再改變的設備，例如LCD控制器。
記錄下該塊記憶體的物理位址給硬體使用，計算出該塊記憶體的虛擬位址位址給CPU使用。

2． 當驅動需要訪問硬體時才將虛擬位址轉換成物理位址，一般用在記憶體空間經常變化的場合。例如塊設備的驅動，檔系統或者其他上層程式讀寫資料時並不會保證每次使用同一段位址。這種情況下，可以使用LockPages函數將虛擬位址轉換成物理位址。

3． 分配一塊物理位址，這可以用在記憶體位址不需要變化，且用量不大的情況，這時可以用AllocPhysMem分配一塊位址，同時得到物理位址與虛擬位址。

Loading Stream driver from ap

如果不想要系統啟動時由DeviceManager自動載入我們寫的driver，而是經由上層ap呼叫去load的話，則在platform.reg有一個地方要改 : 就是把[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Cin]的BuiltIn拿掉，系統就不會自動載入了，路徑可自定，不要在BuiltIn底下即可。
e.g. [HKEY_LOCAL_MACHINE\Drivers\Cin]


//cintest.cpp - demo ap to load driver
//---------------------------------------------------------------------------------
HANDLE hDevice; //handle to initialize the driver
HANDLE hSerial; //handle to open the driver, used by write, read, seek and ioctrl

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) {
DWORD cBytes_out, cBytes_in;

char cBuffer_out[] = "\f\n Hello WORLD! \n\r";
TCHAR cBuffer_in[80];

printf("\n CinTest Demo driver \n");

//使用ActivateDeviceEx時，lpszDevKey 路徑不用加上 HKEY_LOCAL_MACHINE，加的話driver叫不起來
hDevice = ActivateDeviceEx(L"Drivers\\Cin", NULL, 0, 0);
if (hDevice == INVALID_HANDLE_VALUE) { printf("file init errors \n", "%X", hDevice); return 0; }

hSerial = CreateFile(_T("CIN1:"), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

if (hSerial == INVALID_HANDLE_VALUE) { printf("file open errors \n", "%X", hSerial); Sleep(4000); return 0; }

if (!WriteFile(hSerial, cBuffer_out, strlen(cBuffer_out), &cBytes_out, NULL))
{ printf("file write errors\n"); Sleep(4000); return 0; }
cBuffer_in[0] = 0;


if (ReadFile(hSerial, cBuffer_in, 1, &cBytes_in, NULL))
{
if (!WriteFile(hSerial, cBuffer_in, cBytes_in, &cBytes_out, NULL))
{ printf("\rfile write errors\n"); Sleep(4000); return 0; }
}

CloseHandle(hSerial);
DeactivateDevice(hDevice);
return 0;
}

Result :

Using Macros and Environment Variables

The Build utility uses numerous environment variables and macros:

• Environment variables are set by the SetEnv.bat batch file when you open a Windows Driver Kit (WDK) build environment window.

• Macros are specified in the sources files. These files must exist in each source code subdirectory.
  

The distinction between environment variables and macros is weak, because some environment variables can be referenced or changed within "sources" files, and some macros can be defined as environment variables in the build environment window. However, it is recommended that you not attempt to interchange environment variables and build macros in this manner.

在Build Utility Macros 跟 Sources File 兩個分類下都有macro的list，不同的是Build Utility Macros分類下除了macro之外也可以用來做環境變數的設定

Build Utility Macros


Sources File

以下是一些巨集的介紹，完整的list要連到MSDN去參考

DEFFILE :
This macro definition specifies the name for the module-definition file (.def), known as an export file, for TARGETNAME.

DLLENTRY :
This macro definition specifies the function that is used as the entry point for a .dll file if the value of TARGETTYPE is set equal to DYNLINK. If no value is given for DLLENTRY, the default value is _DllMainCRTStartup

INCLUDES :
This macro definition specifies additional paths used to find included .h files.
Use this macro only for your private .h file directories because the standard public .h file directories are automatically included. The default value is NULL.

__PROJROOT :
This macro defines the location of a project.

RELEASETYPE :
This macro definition sets two flags: RELEASEDIR and RELEASELIBDIR, which specify which output directory to place binaries and libraries in after they are built.

SOURCELIBS :
This macro definition specifies library (.lib) files to be linked with the module specified in TARGETNAME. The default value is NULL.

SOURCES :
This macro definition contains a list of files that are processed during the build process to become the contents of a library (.lib) file or dynamic-link library (.dll) file.
The list of files consists of assembly files and source files with extensions. These include the following file types: .cxx, .cpp, .c, .asm, .s, .src, .rc, .obj, .ire, .res, .h, .odl, .tlb, .i, .cs, and .resx.
Header files cannot be included in the SOURCES macro definition.

SYNCHRONIZE_DRAIN :
This macro definition allows you to ensure that all preceding library files are built before building the current directory, which depends on the previous libraries.

TARGETLIBS :
This macro definition specifies additional library (.lib) files and object (.obj) files that should be linked into the target executable (.exe or .dll) file.

TARGETNAME :
This macro definition specifies the name of the .exe or .lib file being built, excluding the file name extension.
Build.exe creates a file named Proj2.extension, where extension can be .lib, .dll, or .exe.

TARGETPATH :
When RELEASETYPE equals CUSTOM, TARGETPATH specifies the object directory into which you are building the target device.

TARGETTYPE :
This macro definition specifies the type of file being built. (exe, lib or dll)
這裡有一篇說明提到TARGETTYPE不只這三種，有興趣可以看看 (不清楚在什麼情況下會用到) -> Utilizing a sources File template

WINCEOEM :
If a component needs to use header files and import libraries from the public projects that it depends on, set this macro definition to 1.
This setting means that the component cannot be used across releases of the system.
This macro definition should be set only by system-level components.

Stream interface drivers

The most common driver model in Windows CE is the stream interface driver. This driver model has roots in the earliest implementations of Unix. A stream driver exports functions to open, close, read, write, seek, or control the underlying hardware.

The stream interface is appropriate for any I/O device that can be thought of logically as a data source or a data sink. That is, any peripheral that produces or consumes streams of data as its primary function is a good candidate to expose the stream interface. A good example is a serial port device. An example of a device that does not produce or consume data in the traditional sense would be a display device, and indeed, the stream interface is not exposed for controlling display hardware.

A stream interface driver receives commands from the Device Manager and from applications by means of file system calls. The driver encapsulates all of the information that is necessary to translate those commands into appropriate actions on the devices that it controls.

All stream interface drivers, whether they manage built-in devices or installable devices, or whether they are loaded at boot time or loaded dynamically, have similar interactions with other system components.

The following illustrations show the interactions between system components for a generic stream interface driver that manages a built-in device, and for a stream interface driver for a PC Card Client device. Figure below, shows the architecture for stream interface drivers for built-in devices that are loaded by the Device Manager at boot time.

Writing Windows CE device drivers: Principle to Practice

Stream Interface Driver Entry Points
Here and elsewhere, XXX refers to a three character prefix you choose for your device driver. When implementing a stream interface driver replace XXX with a prefix appropriate for your specific implementation.

You can implement a driver with only Init and Deinit entry points and no device prefix. You cannot access this driver using CreateFile.

If DEVFLAGS_NAKEDENTRIES is specified in the driver's Flags registry subkey, the entry point names can be undecorated; for example, Open, Close, and so on. The sample battery driver, which is in %_WINCEROOT%\Public\Common\OAK\Drivers\Battdrvr, is an example of a driver that uses undecorated entry points. The battery driver's registry settings still must include a prefix.

Your implementations of these entry points must be declared for export from your DLL by placing __declspec(dllexport) in front of your function declaration. If you are developing in C++, your entry points must also be declared extern "C" as well.



Single Access and Multiple Access
A stream interface driver can implement either single access or multiple access by using the hOpenContext parameter passed to all file I/O functions.

To enable multiple access, each call to the XXX_Open function should return a different value for hOpenContext. The device driver must track which return values from XXX_Open are in use.

To enforce single access, only the first call to XXX_Open should return a valid hOpenContext value. As long as this value remains valid, which is until XXX_Close is called for the value, subsequent calls to XXX_Open should return NULL to the calling application to indicate failure.

MSDN

Stream Interface Driver Functions
XXX_Init
Called when an instance of the driver is loaded. This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice.

The following list shows the tasks this function can perform:

• Initialize the installed device to a default state.
  
• Allocate resources used globally by the device driver.
  
• Register a status callback function with PC Card Services.
  When the status of the device changes, the operating system calls this status callback function. For example, the status of a PC Card changes when you insert it or remove it.
  
• Map system memory and I/O space to a PC Card device memory and I/O space.
  
• Request notification on specific callback events.
  
• Register an interrupt callback function for an interrupt-driven device.
  When the device generates an interrupt, the operating system calls this interrupt callback function.

XXX_Deinit
Called when an instance of the driver is unloaded. This function is required by drivers loaded by ActivateDeviceEx, ActivateDevice, or RegisterDevice.

If you have threads blocked in your driver, resources associated with the handle or device instance might not be able to be released. To avoid this, implement the XXX_PreClose (Device Manager) and XXX_PreDeinit (Device Manager) entry points.

XXX_Open
Called when a driver is opened by an application with CreateFile.

When this function executes, your device should allocate the resources that it needs for each open context and prepare for operation. This might involve preparing the device for reading or writing and initializing data structures it uses for operation.

XXX_Close
Called when a driver is closed by the application with CloseHandle.
An application calls the CloseHandle function to stop using a stream interface driver. The hFile parameter specifies the handle associated with the device context. In response to CloseHandle, the operating system invokes XXX_Close.

The file handle specified for hOpenContext is no longer valid after this function returns; if an application tries to perform stream I/O operations on that handle after calling CloseHandle, those operations fail.

XXX_IOControl
Called when the application calls DeviceIoControl. This function might or might not be required, depending on the device capabilities that the driver exposes. This function requires an implementation of XXX_Open and XXX_Close.

XXX_Read
Called when the application calls ReadFile.

XXX_Write
Called when the application calls WriteFile.

XXX_Seek
Called when the application calls SetFilePointer.

After an application calls the SetFilePointer function to move the data pointer in the device, the operating system invokes this function. If your device is capable of opening more than once, this function modifies only the data pointer for the instance specified by hOpenContext.

XXX_PowerUp
Called just before the system resumes. Optional.

The power handler functions, XXX_PowerUp and XXX_PowerDown, execute in kernel mode, and they cannot be pre-empted

XXX_PowerDown
Called just before the system suspends. Optional. It is useful only with devices that can be shut off under software control. Such devices are typically, but not exclusively, PC Cards.

XXX_PreClose
Optional. This function marks the closing handle as invalid and wakes any sleeping threads.

XXX_PreDeinit
This function marks the device instance as invalid and wakes sleeping threads. Required if the XXX_PreClose function is implemented.

KernelIOControl function

Parameter	Bits	Win32 Type	Managed Type	Typical Value
dwIoControlCode	32	DWORD	Int32	IOCTL_HAL_GET_DEVICEID
lpInBuf	32	LPVOID	IntPtr	IntPtr.Zero (no input data required)
nInBufSize	32	DWORD	Int32	0 (no input data required)
lpOutBuf	32	DEVICE_ID*	byte[]	byte[20] (20 bytes is the size of the DEVICE_ID structure)
nOutBufSize	32	DWORD	Int32	20
lpBytesReturned	32	LPDWORD	ref Int32	0

On Windows CE, the Platform ID and Preset ID can be any length.
e.g. int = KernelIoControl(IOCTL_HAL_GET_DEVICEID, NULL,
sizeof(DWORD), (VOID*)val, sizeof(DEVICE_ID), NULL);


Get Device ID

Build process of WinCE

CESYSGEN Phase (CEBUILD.BAT, sysgen.bat)

This is the first phase of the build process. This step will process the headers and .lib files for the whole system.

BSP Phase (Build.exe)

The BSP (and later stages) are run the most when developing a new system. This phase compiles and links all of your drivers and OAL code.

BUILDREL Phase (BuildRel.BAT)

This phase is focused on collecting files from various parts of the build and copying them all to a single flat release directory (%_FLATRELEASEDIR%). The files and target folders contents from the BSP are copied in to get the modules built in the BSP Phase, along with BSP-specific configuration settings from the BSP's Files directory. When using the IDE, your Platform Builder projects are built after all the files are copied over to the _FLATRELEASEDIR.

MAKEIMG Phase (makeimg.exe)

This is the final stage in the build process. It combines everything into a binary image file(s) for placement on your target hardware. It is implemented in three primary internal stages.

The first stage merges all of the various configuration files (BIB, DAT, REG, DB—we'll detail these files in just a bit) into one master file for each type. The following table shows the files and their corresponding master-merged file.

Original files	Merged file	Description
Common.bib, Config.bib, Project.bib, Platform.bib	Ce.bib	Identifies all the Windows CE files to be combined into the operating system image.
Common.reg, Project.reg, Platform.reg	Reginit.ini	Provides a collection of registry entries for the operating system image.
Common.dat, Project.dat, Platform.dat	Initobj.dat	Provides a description of the directory and file locations for the operating system image.
Common.db, Project.db, Platform.db	Initdb.ini	Defines the creation of any databases in the Windows CE object store.

In the second stage following the merge, makeimg will process all of the EXE and DLL modules specified in LOC files to replace the resources for the current language specified for the build.

After the resources are updated, the makeimg will run ROMIMAGE as the third stage. This will link and locate all execute-in-place code files in the image, and create a ROM file system image for all the other files. This file system is merged with the RAM and other file systems within the Windows CE single-rooted file system. All files in ROM are located in the \Windows Folder.

RomImage will generate the final image as NK.BIN, and optionally as an SRE or as absolute binary image(s) suitable for burning directly into Flash.

from MSDN

where to check if driver is built in or not

check for dlls at
PBWorkspaces\xxx\RelDir\xxx000_Release
ce.bib
platform.bib

The .bib file details the memory layout that the boot loader will use.

--------------
如果要載入任何檔案 (e.g. bmp, exe, whatever) 到CE的Windows folder
在platform.bib的FILES區段 加入檔案敘述
並且把檔案存到相同目錄底下

更改winCE開機logo

用一個array存成header file
例如 320*240解析度的圖
是一個含有76800個element的array
每個element填一個color

先用bitmap tool把.bmp檔轉成header file -> logobmp_320X240.h
再把這個header file存到 platform -> snapXXX -> kernel -> OAL

不過這個header file是在哪被呼叫的呢? 還不知道~

---

每個platform的環境變數都存在 xx.bat
以螢幕大小為例:

@REM ======================================================================
@REM display resolution
@REM ======================================================================
SET BSP_DISPLAY_WIDTH=320
SET BSP_DISPLAY_HEIGHT=240

eVC++ 4.0 - problem: can't find header files

probably the provider's application is built in another version of Platform builder
path : Project -> Settings -> C/C++ -> Preprocessor -> additional include directories
check WinCE version

eVC++ 4.0 - How to build SDK

Scene: Using eVC++ to develop application which have concern with hardware configuration.

solution: build custom SDK from provider's code (using Platform Builder)
path: Platform -> SDK -> Build SDK

SDK (package of header files and libraries)

CE5.0 - Problem: 設breakpoint, device無反應

Solution:

1. Platform -> Settings -> Build Options
check Enable Kernel Debugger
Enable KITL

2. Build OS -> Make Run-Time Image

CE5.0 - How to build under command line

path = ...\platform\project_name\src\drivers

> build -c (clean before building)
> makeimg (make run-time image)

6.0 新功能

目前最新的Windows CE為Windows CE 6.0，這個版本在核心部分有很大的進步：

• 所有系統元件都由EXE改為DLL，並移到 kernel space.

• 全新設計的虛擬記憶體架構

• 全新的裝置驅動程式架構，同時支援 User Mode 與 Kernel Mode 兩種驅動程式.

• 突破只能執行 32 個工作元(process)的限制, 可以執行 32768 個工作元.

• 每一工作元的的虛擬記憶體限制由32 M 增加到全系統總虛擬記憶體.

• Platform Builder IDE 整合到 Microsoft Visual Studio 2005.

• 新的安全架構, 確保只有被信任的軟體可以在系統中執行.

• UDF 2.5 檔案系統

• 支援 802.11i (WPA2)及 802.11e (QoS) 等無線規格, 及多重 radio support.

• 支援 x86, ARM, SH4, MIPS 等各種處理器

• 提供新的 Cellcore components 使系統在行動電話網路中更容易建立資料連結及啟動通話

from wikipedia

6.0 跟 5.0架構比較

• 提供更友善且有效的開發環境　Windows CE 6.0的技術發展與突破
• CE 6.0採用高效率的新核心