如何刷墙（视频）

USB Descriptors

USB Host Class Client Driver Registry Setting

在Windows Mobile上，当HUB感受到有新设备插入时，Host Controller的Driver会试图枚举注册表。例如
[HKEY_LOCAL_MACHINE\Drivers\USB\LoadClients\4817_4099\Default\8\Mass_Storage_Class]
他们的含义如下
HKEY_LOCAL_MACHINE
Drivers
USB
LoadClients
VendorId_ProductId_ReleaseNumber
DeviceClass_DeviceSubClass_DeviceProtocol
Interface_Class_InterfaceSubClass_InterfaceProtocol
Client_Class
如上所示，如果没有特别定义，就用Default,每一个Key包含3个类别，可以制定任意几个

Linus Torvalds on git

Mobile: USB Host interface

正在写mobile上的USB Host Client Driver,今天终于知道了USBD.dll输出的函数如何使用啦！
USB毕竟只有一条通路，软件上在如何多线程，最终数据还是会以序列发送或者接收。
microsoft的函数很稳定，你可以大胆相信他们可以帮你做完你想做的事情，太多的超时处理只会是你陷入困境

OHCI规定寄存器组和共享内存

从上图可以看出，左半边是OHCI中规定的寄存器组，这些寄存器中的一些是指针，指向共享内存。符合OHCI标准的USB Host Controller就是靠这两部分来维护下游设备的状态。

这里是一组真实的OHCI标准的USB Host Controller的寄存器，他们都指向共享内存，你可以看见他们的名字和OHCI标准一致。

USB host初识

今天想了解一下USB host的驱动架构，嵌入式领域OHCI还是很常用的。
针对OHCI我今天才知道，它已经定义了内部寄存器组，包括每个bit的定义都有统一标准。
如果某个SOC说它支持OHCI，那么代码几乎不需要改，拿一个OHCI的代码就可以跑，只要提供寄存器组的首地址，那么其中每一个寄存器就确定了。另外就是中断号对应不一样。
不过虽然移植可能不难，但是搞清楚整个数据流程还是有必要的。

Linux on SAMSUNG s3c2443

我移植linux kernel 2.6.26.2到三星s3c2443处理器上，当我一直完，linux kernel已经更新到2.6.26.5了。不过其间的修改没有影响到s3c244x处理器系列。
总的来说，kernel2.6.26.2对s3c2443的支持非常的不好，它的许多代码只是移植了s3c2410的内核代码，因此在体系结构方面只是一个框架。根本不能用。
s3c2443的更好的官方支持要等2.6.28系列内核了，就目前kernel 2.6.27-rc一直在紧急的修补当中，不过我发现没有多少kernel修改者提交针对s3c2443的补丁，可能是市面上拿到s3c2443 CPU的人比较少？！
当然kernel 2.6.26.2经过修改已经可以启动，下面是我的boot log：

#Uncompressing Linux................................................................................................ done, booting the kernel.
Linux version 2.6.26.2 (cpuwolf@MyLin.localdomain) (gcc version 3.4.4) #36 Mon Sep 1 23:24:45 CST 2008
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
Machine: SMDK2443
Warning: bad configuration page, trying to continue
Ignoring unrecognised tag 0x00000000
Memory policy: ECC disabled, Data cache writeback
CPU S3C2443 (id 0x32443001)
S3C24XX Clocks, (c) 2004 Simtec Electronics
S3C2443: mpll on 800.000 MHz, cpu 400.000 MHz, mem 133.333 MHz, pclk 66.666 MHz
Warning: USB host bus not at 48MHz
S3C2443: epll on 96.000 MHz, usb-bus 96.000 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: console=ttySAC2,115200n8 console=tty0
irq: clearing pending ext status 00007200
irq: clearing subpending status 000000c0
PID hash table entries: 256 (order: 8, 1024 bytes)
timer tcon=00000009, tcnt d902, tcfg 0000020e,00000002, usec 0000170a
Console: colour dummy device 80x30
console [tty0] enabled
console [ttySAC2] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 61708KB available (2744K code, 277K data, 116K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 192 bytes
NET: Registered protocol family 16
S3C2410 Power Management, (c) 2004 Simtec Electronics
S3C2443: Initialising architecture
S3C2443: IRQ Support
S3C24XX DMA Driver, (c) 2003-2004,2006 Simtec Electronics
DMA channel 0 at c4800000, irq 88
DMA channel 1 at c4800100, irq 89
DMA channel 2 at c4800200, irq 90
DMA channel 3 at c4800300, irq 91
DMA channel 4 at c4800400, irq 92
DMA channel 5 at c4800500, irq 93
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 120
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
s3c2410-lcd s3c2410-lcd: cannot get irq 32 - err -22
s3c2410-lcd: probe of s3c2410-lcd failed with error -16
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440
brd: module loaded
loop: module loaded
dm9000 Ethernet Driver, V1.30
S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c2412-nand s3c2410-nand: Tacls=3, 22ns Twrph0=7 52ns, Twrph1=3 22ns
s3c2412-nand s3c2410-nand: System booted from NAND
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd5 (Samsung NAND 2GiB 3,3V 8-bit)
s3c2410_nand_update_chip: chip c3da52bc: 11
Scanning device for bad blocks
Bad eraseblock 0 at 0x00000000
Bad eraseblock 1 at 0x00040000
Bad eraseblock 2 at 0x00080000
Bad eraseblock 3 at 0x000c0000
Bad eraseblock 4 at 0x00100000
Bad eraseblock 5 at 0x00140000
Bad eraseblock 6 at 0x00180000
Bad eraseblock 7 at 0x001c0000
Bad eraseblock 8 at 0x00200000
Bad eraseblock 9 at 0x00240000
Bad eraseblock 10 at 0x00280000
Bad eraseblock 11 at 0x002c0000
Bad eraseblock 12 at 0x00300000
Bad eraseblock 13 at 0x00340000
Bad eraseblock 14 at 0x00380000

fedora kernel 2.6.26.3 update

My ASUS A8 notebook cannot boot up after I update kernel package of fedora linux. The system is halted as the above screen

ARM Linux kernel2.6静态memory mapping

基于ARM的SOC，很多设备寄存器的访问是需要直接静态映射的。而这部分工作一般都是在体系结构初始化时，调用iotable_init()完成。
它的其中一个参数是：
struct map_desc {
unsigned long virtual;
unsigned long pfn;
unsigned long length;
unsigned int type;
};
virtual就是想要映射的虚拟地址，pfn是物理地址，我要强调的是它不是point function，而是Page Frame Number，因此这个物理地址要切换成成页号。

unattended mode reference count

PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);
PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE);
这一对函数的作用，相当于
EnterCriticalSection()
LeaveCriticalSection()
这样类似的成对使用的函数。
实际power manager维护着一个global的reference count，当call PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE)时，reference count++。
当PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE)，reference count--。

如果万一我们call他们时没有对称，那么系统会怎样？

Power manager参考reference count，如果不等于0，那么他会调度决定进入unattended mode。但是并不是说reference count不等于零，power manager就会让系统永远处于unattended mode，而是会有等待一个超时，如果超时，那么系统还是会进入sleep。同时，这个reference count会在进入sleep后清零，也就是"以前所有的不对称都既往不咎"。

Windows Mobile 睡死之谜

Windows Mobile很容易出现"睡死过去"的现象，排除驱动程序的代码问题，那么还是可能"睡死过去"。
今天做了一个实验来模拟在suspend最后那一刻，对文件操作。结果，机器整个hang。

FILE *logFile;
FileSystemPowerFunction(FSNOTIFY_POWER_OFF);

logFile = _tfopen(TEXT("hello.txt"), TEXT("w"));

if (logFile != NULL)
{
_ftprintf(logFile, TEXT("%ld"), 12 );
fclose(logFile);
}

FileSystemPowerFunction(FSNOTIFY_POWER_OFF);是power manager在睡前最后几步必做的事情。而下面的写操作是模拟另一个线程在这个时刻后做写文件的操作。结果就是死亡。
这样的结构在实际开发中很容易形成，要特别小心。

IOCTL_POWER_SET, power manager不为你负责

IOCTL_POWER_SET是驱动程序接收power manager指令的接口。你不要以为power manager会保证每次call你的IOCTL_POWER_SET会保证race condition不发生。换句话说就是IOCTL_POWER_SET可能会被同时call到。
今天我就遇到这样的情况，一个是power manager正常的设置bkl1:到D0，结果另外一个驱动调用了
DevicePowerNotify(_T("bkl1:"), D0,POWER_NAME);
结果我偶然发现Backlight的IOCTL_POWER_SET被同时call到，导致race condition的发生。最后就用Critical Section解决了。

Linux对S3c2443的支持还不完善

我发现目前最新的Linux kernel 2.6.26.5对三星S3c2443 soc的支持是非常不完善的。我想大概是各位kernel hackers拿到s3c2443的机器太少了。大致浏览了一下代码，发现以下问题：

1. main clock的读寄存器并计算是有问题的
2. 由于第1条，导致Uart的clock无法正常设置，Uart无法正常工作
3. s3c2443已经支持4 Uart channel，kernel source code目前只支持3个
4. TFT LCD controller完全没有支持

这些问题部分我已经和Ben Dooks联系，有望在2.6.28 release时，对s3c2443 soc的基本功能进行全面的支持。

display和backlight之间不能不说的事情

我们在windows mobile5/6上写display和backlight驱动程序时候，经常可能会遇到"白屏"的现象。
Display关闭，backlight还是打开，这就是"白屏"。一般情况下，Display和backlight是两个独立的驱动程序，那么看来在关闭屏幕和背光这两个驱动程序是有一定顺序的。
我们先考虑关灯的情况，需要按如下顺序，不可颠倒，颠倒就是"白屏"：
1. backlight off 2. display off
再考虑开灯的情况，需要按如下顺序，不可颠倒，颠倒就是"白屏"：
1. display on 2. backlight on
从上面可以看出，开灯和关灯动作的顺序是相反的。如果从供电的角度来看，display和backlight有着父子关系，即display是backlight的父亲。display有电，backlight才可能有电。
可是Windows Mobile的power manager在睡觉和唤醒时，对设备驱动的操作是线性的。比如先开display,再开backlight,那么必然也是先关display，再关backlight。因此靠power manager来解决白屏问题是不可能了，需要我们自己处理。
而且实际上由于display和backlight的IClass不同，使得他们位于power manager的两个不同的设备管理列表里，导致backlight的流设备列表一定先被操作到，然后才是display。这样一来和上面提到的关灯的顺序是符合的。开灯的顺序相反！

解决方案一
把backlight放在display驱动中去做，这样简单很多，很多变量可以共享

解决方案二
Backlight和display仍然是两个驱动。那么我们的重点是反转开灯的顺序。可以选择在backlight驱动程序处理IOCTL_POWER_SET的D0时，给display驱动的电源状态设置一个floor(请参考 http://cpuwolf.blogspot.com/2008/09/window-mobile-power-managementdevice.html)，先调用SetPowerRequirement(pszDevice, D0, POWER_NAME, NULL, 0);再开启硬件背光。这个结论Microsoft的文档也有，但是她绝对不会告诉你为什么。

charge icon

用3ds max做了3张充电的图标，尺寸是128x84,如果有需要原图的，直接email我，我这里是bmp原图

揭秘window mobile power management关于device power state的管理

hi, I am cpuwolf。今天我就由深入浅的帮你揭开mobile power manager（也就是pm.dll）是如何调度设备的power state。先分析power manager的内部结构，再从API的角度帮你理解power management API的不同。他们是：
DevicePowerNotify()
SetDevicePower()
SetPowerRequirement()

ReleasePowerRequirement()
这几个函数，如果你不听我讲，光想通过看看microsoft的官方文档来理解，那是不可能的！信不信由你。

重要的数据结构

power manager为每一个被管理的设备维护着一个数据结构，它的定义简化后如下：
// this structure describes a power-manageable device
typedef struct _DeviceState_tag {
。。。
CEDEVICE_POWER_STATE curDx; // current official power state (not necessarily supported by the device)
CEDEVICE_POWER_STATE floorDx; // minimum device power state, or PwrDeviceUnspecified
CEDEVICE_POWER_STATE ceilingDx; // maximum device power state, or PwrDeviceUnspecified
CEDEVICE_POWER_STATE setDx; // power state if explicitly set, or PwrDeviceUnspecified
CEDEVICE_POWER_STATE lastReqDx; // last state requested by the device
CEDEVICE_POWER_STATE actualDx; // current actual device power state
CEDEVICE_POWER_STATE pendingDx; // Pending DX for updating
DWORD dwNumPending; // Number of Pending for updating.
。。。
} DEVICE_STATE, *PDEVICE_STATE;
居然有这么多的device power state来影响最后的一个power state的结果。也就是说power manager是个调度中心，当它最后决定某个设备最终该是什么power state（D0/D1/D2/D3/D4）的时候，要参考上面这些成员变量。所以我们第一件事是要搞清楚power manager的调度原则。

power manager的调度原则

设备的电源状态总共有D0,D1,D2,D3,D4 (D0〈D1〈D2〈D3〈D4)。ceilingDx与floorDx听名字就知道是天花板和地板的意思(ceilingDx〈floorDx)，人是生活在天花板和地板之间的空间的。在电源管理里面，意思就是天花板和地板之间的电源状态为有效状态。

例如：

ceilingDx=D1

floorDx=D3

那么D0,D4就是power manager不用考虑的状态，D1,D2,D3就是有效的电源状态。

setDx是最厉害的一个状态，它默认是PwrDeviceUnspecified，只要它不是PwrDeviceUnspecified，那么这个设备的最终状态就等于setDx。

那么setDx是谁设置的呢？

从名字我们一猜就知道，那就是SetDevicePower()。也就是说，只要这个函数一出马，那么不管系统当前是什么状态，或者这个设备是什么状态，这个对应的设备会立即切换到你指定的状态。因此，call这个函数的时候一定要三思而后行。白屏现象就很有可能是他造成的。

例如：

SetDevicePower(_T("BKL1:"),POWER_NAME,D4);

这句话就好像在说：“power manager,我命令你把BKL1:变成D4!!”

如果setDx是PwrDeviceUnspecified，那么power manager就开始考虑lastReqDx。lastReqDx的气势就要虚弱很多，也正如microsoft的文档所说，如果你想改变一个设备的系统状态，同时还想争得power manager的同意，不想太强制，那么call DevicePowerNotify()是再合适不过的了。

例如：

DevicePowerNotify(_T("BKL1:"),D4,POWER_NAME);

这句话就好像在说：“power manager,你看我现在把BKL1:变成D4如何？！”

power manager接到这样的请求，它也是需要掂量一下的，那么它的原则是什么呢？只要是有效状态就可以啦！也就是说ceilingDx〈 lastReqDx〈floorDx。

如果ceilingDx=D1，lastReqDx=D0，那么设备最终也只能是D1。

再如floorDx=D3，astReqDx=D4，那么设备最终也只能是D3。

如果 ceilingDx=D1，floorDx=D3，你请求D2,那么设备最终就是D2。

以上原则很简单吧！可是你有没有注意到我没有提到ceilingDx与floorDx是如何确定的。说到这个就不得不说说SetPowerRequirement()和

ReleasePowerRequirement()两个函数。

例如：

SetPowerRequirement(_T("BKL1:"),D1,POWER_NAME,NULL,0);

好像再说在说：“power manager,帮我把BKL1:变成D1”。你觉得呢？当然不是！

其实你的真正意思是在说：“power manager,至少帮我把BKL1:变成D1”。

然后power manager问你，“D0可以么？（背光更亮一点可以么？）”。

然后你会说，“当然也可以。”

从这个对话中，我们可以知道SetPowerRequirement()实际在设置我们的地板-floorDx。至少是floorDx，不能更低了。floorDx的默认值是D4，因此如果你不去call这个函数，那么就没什么限制。

至于ceilingDx

注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\[ on | BacklightOff | Unattended | xxx ]的下面你可以定义：

"bkl1:"=D2

这样的定义，就好像你在规定：“系统在on的时候，bkl1:最高是D2”。所以bkl1:如果是D3，那么也是可以的。这实际就是在定义设备电源状态的天花板-ceilingDx。同时，如果你没有特别为某个设备指定，那么这个设备的ceilingDx就是用注册表项default的定义值。

综上，floorDx，ceilingDx，setDx，lastReqDx这四个值是power manager调度时要参考的重要参数。

设置设备的电源状态

curDx，actualDx是一对，意思非常接近。

curDx是power manager经过调度算法，最后决定的，该设备的电源状态。可是这个状态，此设备不一定支持。设备声明自己所支持的所有状态是通过IOCTL_POWER_CAPABILITIES做到的。因此万一不支持还需要经过mapping，那么mapping的结果就是actualDx，这个结果就直接通过IOCTL_POWER_SET下达给设备驱动。mapping的过程当然就要参考IOCTL_POWER_CAPABILITIES了。

pendingDx和dwNumPending是用于处理竞争问题设计的计数器。

linux kernel 2.6.27-rc5三天前release

linux kernel stable 2.6.27-rc5三天前release。和以往一样，这次release对大多数来说并没有什么特别。但是对我来讲，这版kernel有着特殊的意义。
因为它包含了我第一次成功向Linus Torvalds提交的补丁。从上大学到现在7年了，我终于有能力参于linux内核开发了。这一天我等了很久。虽然我这次的修改非常简单，但是至少能说明我可以开始融入这个开源内核的大家庭。同时我也相信自己会在日后提交更多的修改。
这种感觉就像小学一年级第一次受老师表扬，等到老师认可的快乐！
在这个submit patch的过程中，可以感觉到这个跨世界范围的大项目的运营过程。看他们是怎么集合大家的智慧，在如此多人参与的项目中，他们是如何把控代码的质量。这些都值得我去学习。

http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.27-rc5

where to place ARM linux kernel

Uncompressed Kernel Image
在ARM体系中，下面这条是定理
ZRELADDR == virt_to_phys(PAGE_OFFSET + TEXT_OFFSET)
PAGE_OFFSET + TEXT_OFFSET定义了内核image的起始虚拟地址。ARM中定义PAGE_OFFSET为0xC000,0000，很明显这是虚地址。arch\arm下的makefile中定义
TEXT_OFFSET := $(textofs-y)
textofs-y的默认值定义如下
textofs-y := 0x00008000
ZRELADDR是对应的物理地址，它在makefile.boot中定义为
zreladdr-y := 0x10008000
这里以OMAP1为例，这个地址就是DRAM的所在的区域
由此可见，这里就是一次MMU mapping,0x10008000==>0xC0008000,那么我们的kernel就应该放在物理地址0x10008000 上，这些都是默认设置我们没必要修改。
如果只是要得到Uncompressed kernel image，就是用make Image命令build kernel,上面的常识就足够了。
Compressed Kernel Image
但是如果你使用make zImage命令build kernel，那么你一定想得到一个Compressed kernel image，这样kernel体积小，节省flash空间.
zImage有两部分组成，前段是自解压代码，后段是被压缩过的kernel image。因此自解压代码也是需要一个放置地址的。
它的起始地址是TEXT_START,TEXT_START默认为0。这段代码是地址无关的，所以可以被安排在任何地址上，解压后的地址由上面的zreladdr决定，这里就是0x10008000。
解压前后内存可能重叠
为了避免内存块重叠，linux建议我们最好这样安排：
1.解压缩后的image起始地址，在压缩image的后面
2.解压缩后的image的结束地址，在压缩image的前面
对于这两条，我觉得第一条更容易做到
解压缩后的image大小如何计算
linux kernel image是用gzip压缩的，压缩基本比例为3：1，那么在计算解压缩后的image大小时，用压缩image大小 x 4计算比较安全。
跳转到kernel
call_kernel: bl cache_clean_flush
bl cache_off
mov r0, #0 @ must be zero
mov r1, r7 @ restore architecture number
mov r2, r8 @ restore atags pointer
mov pc, r4 @ call kernel
这是跳转到解压缩的image的动作。这里可以看出ARM linux规定的向kernel的参数传递规则。
r0为0
r1为architecture的识别号
r2是指针，指向atags参数表
然后跳转到uncompressed image的起始地址上。这里r7,r8寄存器在开始就被备份过，这里做一次恢复。

Sharing Hardware Registers: When to replace multiple writers with a shared resource driver.

Sharing Hardware Registers: When to replace multiple writers with a shared resource driver.
Posted by Jeremy Cooke
翻译自
http://blogs.msdn.com/ce_base/archive/2007/03/29/sharing-hardware-registers-when-to-replace-multiple-writers-with-a-shared-resource-driver.aspx

Hi, I am cpuwolf。这篇来自微软的建议，写的是关于多个驱动共享同一个硬件的问题。这里给出了很好的建议。我尝试用尽可能贴切的专业词语翻译，有什么不对的地方，请指出。
当设计复杂的系统时，偶尔会必需协调对某些的共享资源的访问。一般这些同步问题都由操作系统所提供的例如critical section或mutex等来解决 。这些技术在它是一个简单的共享资源，并且较少的对它的访问时，是无可挑剔的。但对于复杂的资源访问多个threads ，进程，驱动程序，或多个应用程序，新的规范可能更为合适。一个很好的共享资源的驱动程序的例子，就是GPIO驱动程序。每个驱动可能共用一个GPIO模块的寄存器，或者共同读-修改-写，每个驱动如果不同步，那么就会产生问题，
比起直接访问共享资源，把这些访问操作抽象到一个独立的驱动程序去做，可能会更好。所有会访问共享资源的家伙，可以采用尽量少的open这个驱动或者较少使用它的接口。同时，这个驱动程序在内部去处理将同步问题和处理任何可能出现的错误。调用者可以不用再担心同步问题，因为所有这些麻烦都已经交给了别的驱动。
通过使用这一技术，程序员，往往能够避免使用critical section，否则这样的结构会充斥整个原本的代码。现在每一次对共享资源的访问，现在只需通过一个用户设计的API，这些API抽象了访问动作，并且增加程序的可读性。
共享资源的驱动程序也应该预处理和检查错误的输入，以及很好的处理共享资源的错误。由于错误码现在是集中处理的，所有程序员大可认为共享资源已经被很好的保护。这是team开发时的很重要的一点。
例子学习
这个嵌入式系统具有多通道ADC转换器，并且每个通道都有相应的设备使用。多个不相干的驱动程序都试图访问各自的通道。软件可以将hardware所有通道的转换结果放在一块内存中。如果多个线程请求ADC转换，同时没有适当的同步 那么这里就潜藏着一个污染到另一个的情况。
在这特别的系统里有和ADC转换相关的battery驱动程序， USB驱动程序，以及系统的背光驱动程序。battery驱动程序是要关心当前的电压、电池的温度、以及充电电压和充电电流。 USB驱动程序需要监控USB vbus的电压，而背光驱动器需监测环境光线与光电二极管。由于这些功能是在自己的驱动中处理，所有共享资源的访问，都必须以一个更先进的方式控制。以下图1描绘了每个驱动程序都要存取硬件的ADC 。
模拟向数字转换器，将被抽象，并使用一个专门的驱动程序。驱动程序允许多个writer使用所有通道的转换功能，同时返回结果放在一个用户指定的内存中（见图2下文） 。
这个驱动暴露出一个函数，其中包括A / D转换功能并返回结果。如下：
enum ADChannels
{
AD_CHANNEL_BAT_VOLTAGE = 0,
AD_CHANNEL_BAT_CHG_VOLTAGE,
AD_CHANNEL_BAT_CHG_CURRENT,
AD_CHANNEL_BAT_TEMP,
AD_CHANNEL_USB_VBUS,
AD_CHANNEL_PHOTODIODE,
TOTAL_AD_CHANNELS
};

BOOL PerformADConversion(USHORT *pOutBuffer, DWORD OutSize);
在这里pOutBuffer 指向用户的buffer，在函数返回的大小必须等于TOTAL_AD_CHANNELS。必须注意，当向用户数据区拷贝数据时，建议使用类似CeSafeCopyMemory 的函数来处理，它可以处理非法内存的问题。
该PerformADConversion 函数可以实例化一个critical section同步使用，可以看出在图3 ：

在这个设计中，所有硬件访问都被保护在一个集中的代码区，只使用仅仅一个critical section。系统性能得以提升，因为使用了轻量级的critical section，而是一个缓慢的同步对象（如mutex） 。程序员现在可以进一步优化系统性能，每个驱动程序可以同时进行。
虽然使用一个专门的驱动程序来完成这些事情有很多的好处，但是，事实上，这种做法可能会稍微有点慢。因为通过标准的Windows CE的函数访问驱动程序是有一些开销。因此，最好的方法是建立一种结构是驱动的访问开销最小。但是无论怎样，使用这种方法的收益是远远大于这里的开销的。

挖掘WinCE 5系统调用过程

int shellcode[] =
{
0xE59F0014, // ldr r0, [pc, #20]
0xE59F4014, // ldr r4, [pc, #20]
0xE3A01000, // mov r1, #0
0xE3A02000, // mov r2, #0
0xE3A03000, // mov r3, #0
0xE1A0E00F, // mov lr, pc
0xE1A0F004, // mov pc, r4
0x0101003C, // IOCTL_HAL_REBOOT
0xF000FE74, // trap address of KernelIoControl
};
这是黑客常用的缓冲攻击代码形式，这里的32为常数，都是ARM机器指令。
我就要想你展示的不是如何攻击WinCE内核，而是看看WinCE的系统调用是如何实现的。WinCE一个常用的API，KernelIoControl，它的实现体实在内核NK.exe，而function caller只是一个trusted的user级别的application。
你可以想象，这样的API的实现，必然要经历CPU从user processer mode切换到supervisor processer mode。
BOOL KernelIoControl(
DWORD dwIoControlCode,
LPVOID lpInBuf,
DWORD nInBufSize,
LPVOID lpOutBuf,
DWORD nOutBufSize,
LPDWORD lpBytesReturned
);
KernelIoControl超过了4个参数，那么在参数传递时，超过的部分使用堆栈完成的。IOCTL_HAL_REBOOT的参数都没什么用，所以这个我们忽略，传0就可以了，因此r1,r2,r3赋值0.
IOCTL_HAL_REBOOT的数值必须放在寄存器r0。
上面的代码中r4的内容会变为0xF000FE74，代码最后就是跳转到0xF000FE74，你可以看到这个地址很大，在整个内存空间的高地址。同时这个地址是经过编码得到，公式是：
0xf0010000-(256*apiset+apinr)*4
对于KernelIoControl，apiset是0，apinr是99。0xF000FE74是这样得到的。
当代码跳转的这样一个高地址时，会引发prefetch abort，这样exception会被内核 ，也就是NK.exe抓到。然后再对这个出错地址进行解析，就可以知道应用程序想访问那个system cal。
综上，WinCE并不是靠SWI这样的软中断实现system call，而是prefetch abort。

WinCE5 kernel高地址都放了什么东西

typedef struct ARM_HIGH {
ulong firstPT[4096]; // 0xFFFD0000: 1st level page table
char reserved2[0x20000-0x4000];

char exVectors[0x400]; // 0xFFFF0000: exception vectors
char reserved3[0x2400-0x400];

char intrStack[0x400]; // 0xFFFF2400: interrupt stack
char reserved4[0x4900-0x2800];

char abortStack[0x700]; // 0xFFFF4900: abort stack
char reserved5[0x6800-0x5000];

char fiqStack[0x100]; // 0xFFFF6800: FIQ stack
char reserved6[0xC000-0x6900];

char kStack[0x800]; // 0xFFFFC000: kernel stack
struct KDataStruct kdata; // 0xFFFFC800: kernel data page
} ARM_HIGH;

Post-Processing flash.dio

windows mobile最终生成image通常叫做flash.bin。请记住其实是flash.dio，这个文件是一个真正的数据镜像，flash.bin是flash.dio在后期处理，也就是post-processing阶段生产的。
Flash.bin中会包含NAND flash每个sector info的附加信息，并且以block的大小分段。其实也就是把flash.dio中的原始数据加以分段，打包。

值得注意的是微软上面提到：
In addition, NandPostProc.exe also truncates TFAT by 4 blocks, and then adds two compaction blocks into IMGFS and into TFAT. These compaction blocks provide wear–leveling, and help lengthen the life of the flash hardware.

Flash.bin中imgfs分区和tfat分区会被加上gap，反正我是没理解微软的用意。他这样一改，会导致开头的MBR中的分区表信息和这里对不上，因为两个分区后移了。除非这4块区域被标记为未使用，那么查找分区时会自然向后查找，否则就会出错。下面是我用KITL抓到的错误：
Loaded 'cecompr.dll', no matching symbolic information found.
2928 PID:a7a9f512 TID:e7a7a85e ERROR: IMGFS!CVolume::LoadCompressionEngine: unable to load decompressor type "yyyyyyyyyyyyyyyy" from dll "CECOMPR.DLL"... expect failures!!!
Unloaded symbols for 'cecompr.dll'

这样的错误，我花了1个多月，才发现就是上面4 blocks导致。最后我临时换了方案，改烧flash.dio就OK。
所以如果你在porting platform时，遇到这样的问题，先参考一下我的经历。