1.9w+
社区成员
- 全部
- 问答
WINCE电源管理及几个小问题
各位英雄：
小弟在学习WINCE5.0下的电源管理时，遇到了几个问题，敬请各位指教！
1、WINCE500\PLATFORM\COMMON目录下的文件，和实际的BSP（比如SMDK2410）以及WINCE500\PUBLIC\COMMON\OAK（包括CSP、DRIVERS）是什么关系？PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON的几个文件为什么在WINCE500\PLATFORM\COMMON\SRC\COMMON\BOOT\BLCOMMON目录下也有？还有startup.s文件，我的BSP目录下就有3个，分别如下：
BSP270\Src\Bootloader\Eboot
BSP270\Src\Common\Startup
BSP270\Src\Kernel\Oal
而且WINCE500\PLATFORM\COMMON\SRC\ARM\INTEL\PXA27X\STARTUP下也有startup.s文件，请问这些文件到底什么关系？
2、sources文件中的_TARGETPLATROOT、_CPUINDPATH究竟在哪里定义？我查阅了BSP目录下的sources.cmn文件，有些宏就没有定义，比如_CPUINDPATH。
3、我的BSP目录下的EBOOT目录下的sources文件，有语句：TARGETLIBS= \
$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\oal_startup_pxa27x.lib \
$(_PLATCOMMONLIB)\$(_CPUINDPATH)\oal_blcommon.lib
为什么它链接的是oal_blcommon.lib），不是PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON下的blcommon.lib？
4、我的BSP目录下没有off.c文件，也即是没有实现OEMPowerOff的代码，也没有实现OEMIdle的代码，请问该在BSP下的哪一部分实现电源管理相关的这几个函数？我的BSP目录结构如下：
BSP270－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
|－－Cesysgen
|－－Files
|－－Lib
|－－Src
－－Bootloader
－－Common
－－Drivers
－－Inc
－－Kernel
－－Xllp
|－－target
5、电源管理pm.dll分成MDD和PDD两部分，请问如果要实现电源管理（休眠和唤醒），PDD层需要做什么工作呢？也即是需要根据WINCE5.0自带的platform.cpp移植什么呢？
小弟在学习WINCE5.0下的电源管理时，遇到了几个问题，敬请各位指教！
1、WINCE500\PLATFORM\COMMON目录下的文件，和实际的BSP（比如SMDK2410）以及WINCE500\PUBLIC\COMMON\OAK（包括CSP、DRIVERS）是什么关系？PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON的几个文件为什么在WINCE500\PLATFORM\COMMON\SRC\COMMON\BOOT\BLCOMMON目录下也有？还有startup.s文件，我的BSP目录下就有3个，分别如下：
BSP270\Src\Bootloader\Eboot
BSP270\Src\Common\Startup
BSP270\Src\Kernel\Oal
而且WINCE500\PLATFORM\COMMON\SRC\ARM\INTEL\PXA27X\STARTUP下也有startup.s文件，请问这些文件到底什么关系？
2、sources文件中的_TARGETPLATROOT、_CPUINDPATH究竟在哪里定义？我查阅了BSP目录下的sources.cmn文件，有些宏就没有定义，比如_CPUINDPATH。
3、我的BSP目录下的EBOOT目录下的sources文件，有语句：TARGETLIBS= \
$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\oal_startup_pxa27x.lib \
$(_PLATCOMMONLIB)\$(_CPUINDPATH)\oal_blcommon.lib
为什么它链接的是oal_blcommon.lib），不是PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON下的blcommon.lib？
4、我的BSP目录下没有off.c文件，也即是没有实现OEMPowerOff的代码，也没有实现OEMIdle的代码，请问该在BSP下的哪一部分实现电源管理相关的这几个函数？我的BSP目录结构如下：
BSP270－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
|－－Cesysgen
|－－Files
|－－Lib
|－－Src
－－Bootloader
－－Common
－－Drivers
－－Inc
－－Kernel
－－Xllp
|－－target
5、电源管理pm.dll分成MDD和PDD两部分，请问如果要实现电源管理（休眠和唤醒），PDD层需要做什么工作呢？也即是需要根据WINCE5.0自带的platform.cpp移植什么呢？
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
lllchr88 2010-03-22
mark
hzdysymbol 2009-05-22
2、控制面板中的display里面应该有定时器的吧，定时到后是发送什么指令给背光驱动呢？背光驱动中也是在IOCTL中截获该指令？
本身没有定时器，需要自己去处理
3、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
不一定要转到on，无论想转到什么状态都可以，查看ＰＭ的Ｐublic下面的代码
4、系统电源状态切换时，电源管理器应该会主动去通过IOCTL_POWER_SET调用各驱动（比如背光驱动）的IOCTL流接口函数吧？为什么我的背光驱动中还需要一个线程去监视系统电源状态的切换？就是调用RequestPowerNotifications，然后WaitForMultipleObjects的那个线程！
背光驱动中的线程监测和电源管理没有关系，如果用ＰＭ来管理背光驱动的话完全可以把这个线程拿掉
本身没有定时器，需要自己去处理
3、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
不一定要转到on，无论想转到什么状态都可以，查看ＰＭ的Ｐublic下面的代码
4、系统电源状态切换时，电源管理器应该会主动去通过IOCTL_POWER_SET调用各驱动（比如背光驱动）的IOCTL流接口函数吧？为什么我的背光驱动中还需要一个线程去监视系统电源状态的切换？就是调用RequestPowerNotifications，然后WaitForMultipleObjects的那个线程！
背光驱动中的线程监测和电源管理没有关系，如果用ＰＭ来管理背光驱动的话完全可以把这个线程拿掉
daigua04 2009-05-22
英雄们走过路过，帮忙看下我的上一楼的问题啊，如果分不够，可以再加了！
daigua04 2009-05-20
再次总结下我的问题：
1、电源管理组件是不是就是添加power management（FULL）？
2、控制面板中的display里面应该有定时器的吧，定时到后是发送什么指令给背光驱动呢？背光驱动中也是在IOCTL中截获该指令？
3、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
4、系统电源状态切换时，电源管理器应该会主动去通过IOCTL_POWER_SET调用各驱动（比如背光驱动）的IOCTL流接口函数吧？为什么我的背光驱动中还需要一个线程去监视系统电源状态的切换？就是调用RequestPowerNotifications，然后WaitForMultipleObjects的那个线程！
问题是多，亟需要各位英雄的搭救...
1、电源管理组件是不是就是添加power management（FULL）？
2、控制面板中的display里面应该有定时器的吧，定时到后是发送什么指令给背光驱动呢？背光驱动中也是在IOCTL中截获该指令？
3、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
4、系统电源状态切换时，电源管理器应该会主动去通过IOCTL_POWER_SET调用各驱动（比如背光驱动）的IOCTL流接口函数吧？为什么我的背光驱动中还需要一个线程去监视系统电源状态的切换？就是调用RequestPowerNotifications，然后WaitForMultipleObjects的那个线程！
问题是多，亟需要各位英雄的搭救...
guopeixin 2009-05-19
[Quote=引用 2 楼 paul_chao 的回复:]
lz 的問題有點多了
首先來考古一下好了, 話說 wince 3.0 時代, 是沒有 platform\common, 也沒有 public\commom\oak\csp 的, 所有與 bsp 相關的程式碼, 全部要在 platform\%_TGTPLAT% 下完成, 更有甚者, MS 的 reference board ODO, 它是用一塊底板, 上面再換 x86/ARM/SHx/MIPS/PowerPC 等不同的 cpu 板, 所以在 platform\%_TGTPLAT%\kernel\hal 下, 還有一個 ARM 的目錄.
但是, 照 MS 的理想, platform 其實還可以再細分為 B…
[/Quote]
套用网上的话，你就是骨灰级的玩家
lz 的問題有點多了
首先來考古一下好了, 話說 wince 3.0 時代, 是沒有 platform\common, 也沒有 public\commom\oak\csp 的, 所有與 bsp 相關的程式碼, 全部要在 platform\%_TGTPLAT% 下完成, 更有甚者, MS 的 reference board ODO, 它是用一塊底板, 上面再換 x86/ARM/SHx/MIPS/PowerPC 等不同的 cpu 板, 所以在 platform\%_TGTPLAT%\kernel\hal 下, 還有一個 ARM 的目錄.
但是, 照 MS 的理想, platform 其實還可以再細分為 B…
[/Quote]
套用网上的话，你就是骨灰级的玩家
AlexChan1981 2009-05-19
问题多多
forpeople 2009-05-19
qiang
弓虽 啊
谢谢分享
弓虽 啊
谢谢分享
daigua04 2009-05-18
有关windows ce 5.0电源管理的问题，想请教您，恳请指点一二...
1、为什么我的控制面板里没有电源这一项？
2、控制面板中，display可以设置自动关闭背光时间，如果我设置为1min，请问1min后，系统是如何一步步去关闭背光的？需要底层的背光驱动配合吗？
3、系统电源状态可以自行定义，如果增加除了on、useridle、systemidle、suspend之外的其它一个状态，请问增加后的状态在哪里可以体现出来呢？控制面板中会有吗？
4、控制面板中，power state可以分别设置useridle、systemidle、suspend的TIME-OUT时间，请问这几个状态之间的切换，需要在pm.dll的PDD层做什么工作，比如设置定时器？
5、如果我想在systemidle时关闭背光，需要怎么做？系统到达system idle时，又是如何去关闭背光的？
6、进入system idle后，如果点击触摸屏，就进入On模式，并打开背光。是不是先在触摸屏驱动中向系统发送OpenEvent(EVENT_ALL_ACCESS, FALSE, _T（"PowerManager/ActivityTimer/UserActivity")); 事件，然后系统自动切换到On模式？那么请问又该怎么打开背光呢？
7、电源管理模块的重点之一是制订系统电源管理策略，这包括定义系统电源状态，决定状态间转换的条件。请问我在wince的那一层定制管理策略呢？比如用户在使用时候，系统处于On状态；用户停止输入，系统自动转入UserIdle状态；持续没有输入事件后，进入SystemIdle状态；持续一段时间后，系统将自动进入Suspend状态。
1、为什么我的控制面板里没有电源这一项？
2、控制面板中，display可以设置自动关闭背光时间，如果我设置为1min，请问1min后，系统是如何一步步去关闭背光的？需要底层的背光驱动配合吗？
3、系统电源状态可以自行定义，如果增加除了on、useridle、systemidle、suspend之外的其它一个状态，请问增加后的状态在哪里可以体现出来呢？控制面板中会有吗？
4、控制面板中，power state可以分别设置useridle、systemidle、suspend的TIME-OUT时间，请问这几个状态之间的切换，需要在pm.dll的PDD层做什么工作，比如设置定时器？
5、如果我想在systemidle时关闭背光，需要怎么做？系统到达system idle时，又是如何去关闭背光的？
6、进入system idle后，如果点击触摸屏，就进入On模式，并打开背光。是不是先在触摸屏驱动中向系统发送OpenEvent(EVENT_ALL_ACCESS, FALSE, _T（"PowerManager/ActivityTimer/UserActivity")); 事件，然后系统自动切换到On模式？那么请问又该怎么打开背光呢？
7、电源管理模块的重点之一是制订系统电源管理策略，这包括定义系统电源状态，决定状态间转换的条件。请问我在wince的那一层定制管理策略呢？比如用户在使用时候，系统处于On状态；用户停止输入，系统自动转入UserIdle状态；持续没有输入事件后，进入SystemIdle状态；持续一段时间后，系统将自动进入Suspend状态。
daigua04 2009-05-18
非常感谢您的回答，感激不尽！
1、电源管理组件是不是就是添加power management（FULL）？
2、display里面应该有定时器的吧，定时到后是发送什么驱动指令呢？背光驱动中也是在IOCTL中截获该指令？
6、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
7、我看common.reg中有设置了，是不是要把它移植到platform.reg中并修改时间值？
1、电源管理组件是不是就是添加power management（FULL）？
2、display里面应该有定时器的吧，定时到后是发送什么驱动指令呢？背光驱动中也是在IOCTL中截获该指令？
6、点击触摸屏或者键盘，系统是如何出发useractivity事件呢？且该事件触发后，一定要转到on吗？能不能跳到其它状态？
7、我看common.reg中有设置了，是不是要把它移植到platform.reg中并修改时间值？
Ricky_hu 2009-05-18
[Quote=引用 9 楼 daigua04 的回复:]
有关windows ce 5.0电源管理的问题，想请教您，恳请指点一二...
1、为什么我的控制面板里没有电源这一项？
2、控制面板中，display可以设置自动关闭背光时间，如果我设置为1min，请问1min后，系统是如何一步步去关闭背光的？需要底层的背光驱动配合吗？
3、系统电源状态可以自行定义，如果增加除了on、useridle、systemidle、suspend之外的其它一个状态，请问增加后的状态在哪里可以体现出来呢？控制面板中会有吗？
4、控…
[/Quote]
1、因为你没有添加电源管理的组件。
2、这个关背光的动作是display驱动里面做的，肯定跟需要背光驱动来配合啊，实际上是display驱动发指令，背光驱动来关闭背光而已。
3、系统电源状态可以自定义么？没有自己定义过，也没有必要吧！要增加的话肯定需要修改public下面的代码，你修改之后控制面板中应该会有（如果支持自定义的话）。
4、这就是PM的主要工作，不需要你再特别的做其它事情，你添加PM组件就行了。
5、进入systemidle的时候，PM会让系统设备进入注册表中systemidle下设定的设备电源状态，比如D3，具体是通过IOCTL来完成的。
6、这个事件UserActivity本身存在于系统中，不需要在触摸屏驱动中添加你说的代码，这些都是PM来完成的。UserActivity被触发后，PM会把系统的电源状态设定到ON，然后把设备的电源状态也设定到D0，也是通过IOCTl来完成的。在背光等驱动中会有接IOCTL的代码。
7、这就是PM的功能。MS已经为你做好了，不需要你来实现这些功能。你只要添加PM组件就OK了。系统进入ueseridle和systemidle以及suspend的时间你可以在平台的reg文件中自定义。
有关windows ce 5.0电源管理的问题，想请教您，恳请指点一二...
1、为什么我的控制面板里没有电源这一项？
2、控制面板中，display可以设置自动关闭背光时间，如果我设置为1min，请问1min后，系统是如何一步步去关闭背光的？需要底层的背光驱动配合吗？
3、系统电源状态可以自行定义，如果增加除了on、useridle、systemidle、suspend之外的其它一个状态，请问增加后的状态在哪里可以体现出来呢？控制面板中会有吗？
4、控…
[/Quote]
1、因为你没有添加电源管理的组件。
2、这个关背光的动作是display驱动里面做的，肯定跟需要背光驱动来配合啊，实际上是display驱动发指令，背光驱动来关闭背光而已。
3、系统电源状态可以自定义么？没有自己定义过，也没有必要吧！要增加的话肯定需要修改public下面的代码，你修改之后控制面板中应该会有（如果支持自定义的话）。
4、这就是PM的主要工作，不需要你再特别的做其它事情，你添加PM组件就行了。
5、进入systemidle的时候，PM会让系统设备进入注册表中systemidle下设定的设备电源状态，比如D3，具体是通过IOCTL来完成的。
6、这个事件UserActivity本身存在于系统中，不需要在触摸屏驱动中添加你说的代码，这些都是PM来完成的。UserActivity被触发后，PM会把系统的电源状态设定到ON，然后把设备的电源状态也设定到D0，也是通过IOCTl来完成的。在背光等驱动中会有接IOCTL的代码。
7、这就是PM的功能。MS已经为你做好了，不需要你来实现这些功能。你只要添加PM组件就OK了。系统进入ueseridle和systemidle以及suspend的时间你可以在平台的reg文件中自定义。
daigua04 2009-05-17
各位英雄，还有几个问题：
1、电源管理策略，也即包括超时等管理机制，是在OAL层定制的吗？主要要做什么工作呢？
2、电源管理PM.DLL的定制，是否必须要移植PDD层？移植或不移植的差别主要是什么呢？
3、OAL层的几个重要函数，如OEMIdle、OEMPowerOff等，这和PM.DLL是什么关系？
4、空闲休眠时，最后分别都会调用OEMIdle和OEMPowerOff；如果是关闭背光（BacklightOff）状态，它的底层实现代码应该在何处实现？在LCD驱动里吗？实现后又该如何和内核层保持接口一致呢（也即使得上层可以顺利自动调用它关闭背光）？
谢谢了！
1、电源管理策略，也即包括超时等管理机制，是在OAL层定制的吗？主要要做什么工作呢？
2、电源管理PM.DLL的定制，是否必须要移植PDD层？移植或不移植的差别主要是什么呢？
3、OAL层的几个重要函数，如OEMIdle、OEMPowerOff等，这和PM.DLL是什么关系？
4、空闲休眠时，最后分别都会调用OEMIdle和OEMPowerOff；如果是关闭背光（BacklightOff）状态，它的底层实现代码应该在何处实现？在LCD驱动里吗？实现后又该如何和内核层保持接口一致呢（也即使得上层可以顺利自动调用它关闭背光）？
谢谢了！
daigua04 2009-05-17
英雄，赐教啊...
lyx_wq 2009-04-21
up
shuiyan 2009-04-16
1、用了这么久，觉得这些目录间的异同、来历可以不去深究，只要理解一点：Platform下面的都是提供给你可以自己修改的；public下的绝对不要改动。
如果涉及到一些需要修改public下代码的，宁可先移到platform下来进行修改。依赖编译时复制到release目录下的先后顺序，来确保最终有效的是Platform中被改动的部分。
startup.s文件至少可以找到3种，互不相同，有个调用顺序，public下的是启动必须，oal是必须的，eboot的是可跳过的，因为可以没有eboot。
2、
3、public下的只包含所有平台最通用的部分，而具体平台各自私有的一些配置需要由各自bsp的OAL来实现。
4、
5、非特殊驱动控制的，需要实现电源管理的，可以在pm的pdd层实现，比如设置所有未使用的io口状态，所有未用的控制器状态，无专用驱动的一些信息保存、状态指示等。
有专用驱动的，必须完善自己的PowerOn/PowerOff函数，以供PM调用。
如果涉及到一些需要修改public下代码的，宁可先移到platform下来进行修改。依赖编译时复制到release目录下的先后顺序，来确保最终有效的是Platform中被改动的部分。
startup.s文件至少可以找到3种，互不相同，有个调用顺序，public下的是启动必须，oal是必须的，eboot的是可跳过的，因为可以没有eboot。
2、
3、public下的只包含所有平台最通用的部分，而具体平台各自私有的一些配置需要由各自bsp的OAL来实现。
4、
5、非特殊驱动控制的，需要实现电源管理的，可以在pm的pdd层实现，比如设置所有未使用的io口状态，所有未用的控制器状态，无专用驱动的一些信息保存、状态指示等。
有专用驱动的，必须完善自己的PowerOn/PowerOff函数，以供PM调用。
jerry79 2009-04-15
楼上的兄弟经验真是丰富啊！
老猿IVD 2009-04-15
Paul, Chao
牛人啊！
牛人啊！
paul_chao 2009-04-14
lz 的問題有點多了
首先來考古一下好了, 話說 wince 3.0 時代, 是沒有 platform\common, 也沒有 public\commom\oak\csp 的, 所有與 bsp 相關的程式碼, 全部要在 platform\%_TGTPLAT% 下完成, 更有甚者, MS 的 reference board ODO, 它是用一塊底板, 上面再換 x86/ARM/SHx/MIPS/PowerPC 等不同的 cpu 板, 所以在 platform\%_TGTPLAT%\kernel\hal 下, 還有一個 ARM 的目錄.
但是, 照 MS 的理想, platform 其實還可以再細分為 Board, Chip level, 有很多部份是共用的, 故 MS 在不同的版本做了不同的演進
4.x 時代, MS 將 SOC CPU 內部的 device driver 從 bsp 中抽離, 放至 public\common\oak\csp
5.0 時代, MS 再更進一步, 將 kernel 的共用部份也移出, 放至 platform\common, 但 device driver 的部份, 則還是放在 public\common\oak\csp.
6.0 時代, MS 覺得與 SOC 的東西放的散諸各地不利 maintain, 故又將與 SOC 有關的 kernel/driver 全部放在 platform\common\src\soc, 而與 cpu 無關的 kernel code, 則放在 platform\common\src\common 下, 與 ARM architecture (like as 920T/926), 則放在 platform\common\src\arm 下
到 7.0 時代會不會再改呢?? 不知, 不過各位不用擔心, 從歷史上來看, MS 不會讓工程師閒閒沒事做的.
回歸主題
1. blcommon 是在 4.x 時代 MS 提出的 bootloader 架構, 其時放在 public\common\oak\drivers\ethdbg, 至 5.0 時代移至 platform\common\src\common\boot\blcommon, 但為了降低 bsp 從 4.2 移植至 5.0 的困難性, 故還留著.
startup.s 通常是 arm 下放 wince 的程式進入點 StartUp, 按照 MS 的理想, 與 Board 無關而與 SOC 內部有關的, 放在 platform\common 中, 但與 Board 有關的設定, 則放在 platform\%_TGTPLAT%\kernel\oal 中.
(1) platform\%_TGTPLAT%\bootloader\eboot 是 eboot 的, 給在 platform\%_TGTPLAT%\common\startup 執行完後叫用, 與 kernel\oal 下的 startup 都是做 board level 的設定, 惟 eboot 還需做 mmu 的設定.
(2) platform\%_TGTPLAT%\common\startup 應是從 platform\common\src\arm\intel\pxa27x\startup 移植過來, 做 cpu 的設定, 理論上只要是用 pxa27x 這顆 cpu, 那麼就直接可使用 platform\common\src\arm\intel\pxa27x 下的程式碼, 無須修改, 但實務上, MS 的理想太崇高而不易實現, 故常會移植一份來修改符合 board
(3) platform\%_TGTPLAT%\kernel\oal 給 nk.bin 用的
2. 這些東西, MS 從來沒有一份文件有交待清楚的, 猜猜吧, 八九不離十的.
3. 如前所述, 4.x 的就是用 PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON下的blcommon.lib
4. MainStoneII 的在 platform\platform\common\src\arm\intel\pxa27x\power\off.c, 但其實裡面全是空的, 你可參考 MainStoneIII 的 BSP, 上網找一下就有.
5. PM 的主要架構只是在 power state 改變時做 notify, 主要的電源管理還是在每一支各別的 driver.
果然還是老賊會考古.
Paul, Chao @ Techware
首先來考古一下好了, 話說 wince 3.0 時代, 是沒有 platform\common, 也沒有 public\commom\oak\csp 的, 所有與 bsp 相關的程式碼, 全部要在 platform\%_TGTPLAT% 下完成, 更有甚者, MS 的 reference board ODO, 它是用一塊底板, 上面再換 x86/ARM/SHx/MIPS/PowerPC 等不同的 cpu 板, 所以在 platform\%_TGTPLAT%\kernel\hal 下, 還有一個 ARM 的目錄.
但是, 照 MS 的理想, platform 其實還可以再細分為 Board, Chip level, 有很多部份是共用的, 故 MS 在不同的版本做了不同的演進
4.x 時代, MS 將 SOC CPU 內部的 device driver 從 bsp 中抽離, 放至 public\common\oak\csp
5.0 時代, MS 再更進一步, 將 kernel 的共用部份也移出, 放至 platform\common, 但 device driver 的部份, 則還是放在 public\common\oak\csp.
6.0 時代, MS 覺得與 SOC 的東西放的散諸各地不利 maintain, 故又將與 SOC 有關的 kernel/driver 全部放在 platform\common\src\soc, 而與 cpu 無關的 kernel code, 則放在 platform\common\src\common 下, 與 ARM architecture (like as 920T/926), 則放在 platform\common\src\arm 下
到 7.0 時代會不會再改呢?? 不知, 不過各位不用擔心, 從歷史上來看, MS 不會讓工程師閒閒沒事做的.
回歸主題
1. blcommon 是在 4.x 時代 MS 提出的 bootloader 架構, 其時放在 public\common\oak\drivers\ethdbg, 至 5.0 時代移至 platform\common\src\common\boot\blcommon, 但為了降低 bsp 從 4.2 移植至 5.0 的困難性, 故還留著.
startup.s 通常是 arm 下放 wince 的程式進入點 StartUp, 按照 MS 的理想, 與 Board 無關而與 SOC 內部有關的, 放在 platform\common 中, 但與 Board 有關的設定, 則放在 platform\%_TGTPLAT%\kernel\oal 中.
(1) platform\%_TGTPLAT%\bootloader\eboot 是 eboot 的, 給在 platform\%_TGTPLAT%\common\startup 執行完後叫用, 與 kernel\oal 下的 startup 都是做 board level 的設定, 惟 eboot 還需做 mmu 的設定.
(2) platform\%_TGTPLAT%\common\startup 應是從 platform\common\src\arm\intel\pxa27x\startup 移植過來, 做 cpu 的設定, 理論上只要是用 pxa27x 這顆 cpu, 那麼就直接可使用 platform\common\src\arm\intel\pxa27x 下的程式碼, 無須修改, 但實務上, MS 的理想太崇高而不易實現, 故常會移植一份來修改符合 board
(3) platform\%_TGTPLAT%\kernel\oal 給 nk.bin 用的
2. 這些東西, MS 從來沒有一份文件有交待清楚的, 猜猜吧, 八九不離十的.
3. 如前所述, 4.x 的就是用 PUBLIC\COMMON\OAK\DRIVERS\ETHDBG\BLCOMMON下的blcommon.lib
4. MainStoneII 的在 platform\platform\common\src\arm\intel\pxa27x\power\off.c, 但其實裡面全是空的, 你可參考 MainStoneIII 的 BSP, 上網找一下就有.
5. PM 的主要架構只是在 power state 改變時做 notify, 主要的電源管理還是在每一支各別的 driver.
果然還是老賊會考古.
Paul, Chao @ Techware
daigua04 2009-04-14
怎么没有英雄路过啊？自己支持一下！
