现像：
1.当编译完eboot后进行链接时，会用到几个库文件,在eboot目录的sources文件中描述:
TARGETLIBS=/
$(_COMMONOAKROOT)/lib/$(_CPUINDPATH)/fulllibc.lib /
$(_COMMONOAKROOT)/lib/$(_CPUDEPPATH)/blcommon.lib /
$(_COMMONOAKROOT)/lib/$(_CPUDEPPATH)/bootpart.lib /
$(_COMMONOAKROOT)/lib/$(_CPUINDPATH)/csp_arm.lib /
$(_COMMONOAKROOT)/lib/$(_CPUDEPPATH)/eboot.lib /
$(_COMMONOAKROOT)/lib/$(_CPUINDPATH)/cs8900dbg.lib /
..
当在更改了上述库文件的源码并编译后，在PB中单独编译eboot时,更改后的目标库文件没有被链接进eboot的最终镜像文件。
解决方法：
找了一些资料，并经过多次试验后，在pb4.2的帮助文档中找到下面的说明:
Microsoft Windows CE .NET 4.2
_CPUDEPPATHIf RELEASETYPE is DDK, OAK, SDK, or PLATFORM, and WINCECPU is set to 1, which means that the source code is microprocessor-dependent, _CPUDEPPATH specifies a qualifier that defines the CPU-dependent directories. This macro definition includes the microprocessor as specified by _TGTCPU, the OS as specified by _TGTOS, and the debug state as specified by WINCEDEBUG. Build.exe uses _CPUDEPPATH when it sets TARGETLIBS.
_CPUDEPPATH is set by Makefile.def, and is not visible in the command prompt build window. Do not set this variable.
注意上面的加粗部份,意思是_CPUDEPPATH环境变量在命令提示符下不可见，可以理解为不能用。所以解决方法是,先将对应的驱动进行手动编译后:
1.将上面的sources文件的库文件引用的改成绝地地址,如：
TARGETLIBS=/
c:/wince420/public/common/oak/lib/armv4/retail/cs8900dbg.lib/
...
2.或者使用PB的IDE环境进行重新编译(rebuild)
注意的几个问题:
1. cs8900dbg有两个目录，对应是:BSP/Driver/cs8900dbg这个是BSP带的.还有一个位于wince420/public/common/oak/drivers/ethdbg/cs8900这个是pb4.2带的。这两个有区别:
1> BSP带的cs8900dbg.c文件中的一个函数Probe()，里面有个功能:
if (IOREAD(IO_PACKET_PAGE_POINTER) != CS8900_SIGNATURE)
{
DBGMSG("Signature Error/n");
break;
}
这个函数在CS8900初上电时能检测到正常值，但是在工作后重新检查，将会检测不到正确值，所以需要将此功能代码注释掉.可以只检查CS8900的EISA Number.
2> BSP带的cs8900dbg.c文件只能用于eboot,不能用在hal中。它比PB自带的cs8900dbg.c少了几个功能函数，而这些函数将会被链接进hal,供kernel使用。
所以，最好还是使用PB自带的cs8900dbg.注意,它默认使用CS8900的Mem模式，而非IO模式。可以将cs8900dbg.c文件开头处的#define CS8900_MEM_MODE宏注释掉即可使用IO模式.
2. 我在另一块板子上试eboot时,发现在cs8900在nboot启动时可以正常使用,而进入eboot进行下载文件时发现初始化cs8900时失败,经排查,nboot使用时正确初使化了cs8900的总线控制器，而在eboot时没有正常初始化，由此可见,eboot启动时也是有自已的启动代码，而不是nboot直接跳转到eboot的c代码处。Eboot的启动代码与hal共用,位于bsp/kernel/arm/fw.s文件中.我的另一块板子的对应fw.s文件中，它把对内存初使化的代码注释掉了,所以导致出错!fw.s文件中对内存初始化的代码引用了相同目录下的reg2410.a,它定义了一些内存总线初始化的参数，一般只需要修改这里即可。值得注意的是,相同目录下的memcfg.inc也定义了与reg2410.a相同的参数，但是我却始终没有找到(用superfinder)哪些文件引用了memcfg.inc文件.
3. 几个常用的功能:
1> 单独编译:
事实上也要打开pb的IDE,只是通过命令行手动对目标进行编译,打开ide与目标工程后，在build目录下选择"open build release directory",打命令提示符中切换到目标文件夹下，输入build -c即可。-c是删除已经存在的obj文件，重新编译。注意，此时一般在目标文件夹下有个makefile与sources文件，或者是dir文件,是编译选项命令.编译完成后，如果是pb自带的驱动程序，大多会生成lib文件(主要还是看sources文件里的配置),这个生成的lib文件会自动拷贝至$WINCEROOT/public/common/oak/lib/$(cpu平台,如armv4)/$(编译类型，如retail)/下面，具体位置也要看目标工程的设置，如cpu类型,编译类型(debug/release/)等等。
编译eboot时,也是在上面的命令提示符中，切换到eboot目录，先编译，后输入:romimage boot.bib.生成的镜像文件位于bsp/target/(cpu类型)/(编译类型)/
编译目标dll文件(如cs8900.dll)可以参考以前写的笔记.
2> 在用pb对目标工程多次编译(rebuild)后，往往莫明其妙会出错，可以在编译前先执行build菜单下的clean命令，再进行编译。