Android service

Android service 的启动可以用
setprop ctl.start xxx
的命令来完成.他的具体实现请参考Android/system/core/init/init.c的
service_start()函数

如何刷墙（视频）

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寄存器在开始就被备份过，这里做一次恢复。