wince6.0下怎么实现系统运行起来后升级更新NK.BIN

wince6.0下怎么实现系统运行起来后升级更新NK.BIN,第1张

1、注册表1.配置project.bib或者添加UserFeature,以将含入NK.bin请参考《让程序在WindowsCE系统启动时自动运行-快捷方式》2.配置platform.reg或者common.reg,在[HKEY_LOCAL_MACHINEinit]段添加如下类似内容:"LaunchXX"="""DependXX"=hex:YY,ZZ,其中XX是十进制的数字,表示的启动顺序标识;YY,ZZ是LeastSignificant的十六进制数字,表示所依赖(先于运行)的程序的启动顺序标识。例如:"Launch80"="MyApp.exe""Depend80"=hex:1E,00语意为程序MyApp.exe的启动顺序标识是80,它依赖标识为30(即001E)的程序。如果不依赖其他程序,那么不需要添加"DependXX"=hex:YY,zz,指示;如果依赖多个程序,那么在"DependXX"指示中指明;eg."Launch80"="MyApp.exe""Depend80"=hex:0A,00,1E,00语意为MyApp.exe程序的启动依赖标识为10和30的程序。3.PlatformBuilderIDE->Build->MakeImage,生成新的NK.bin说明:1.如果是别的程序所依赖的程序,那么在的代码中需要添加如下代码SignalStarted(XX)以通告 *** 作系统已经运行,否则依赖的程序将不会运行。一般SignalStarted加在InitInstance成员函数的最后(MFCCE)或者while(GetMessage())之前(CSDK)2.不要重复使用启动顺序标识,依赖方程序的启动顺序标识应大于被依赖方程序。3.如果不想让包含在NK.bin中,同时又想让它自动启动,那么请明确指出的路径,同时确保文件系统驱动程序先运行。eg."Launch80"="HardDiskMyAppMyApp.exe""Depend80"=hex:4.启动失败不会影响系统5.参考《让程序在WindowsCE系统启动时自动运行-快捷方式》6.相关PB4.2帮助主题AddingaFiletoanOperatingSystemHowtoConfiguretheRegistrytoRunanApplicationatStartup一、快捷方式假定WindowsCE.NET目标工程为CEPC类型,目录为E:ProjectMyWinCE,并且工程已经Build(或者Rebuild)成功;假定WindowsCE.NET的应用为MyApp.exe1.将MyApp.exe复制到E:PROJECTSMyWinCERelDirCEPC_X86Release目录下;2.修改MyWinCE工程的project.bib文件,在FILESSection添加MyApp.exe$(_FLATRELEASEDIR)MyApp.exeNKH3.创建快捷方式文件MyApp.lnk(文本文件),文件内容如下:10#WindowsMyApp.exeMyApp.lnk文件也放入E:PROJECTSMyWinCERelDirCEPC_X86Release目录下4.修改MyWinCE工程的project.bib文件,在FILESSection添加MyApp.lnk$(_FLATRELEASEDIR)MyApp.lnkNKH5.修改MyWinCE工程的project.dat文件,添加如下内容:Directory("WindowsStartup"):-File("MyApp.lnk","WindowsMyApp.lnk")6.PlatformBuilderIDE->菜单Build->MakeImage(记得千万不要Build或者Rebuild,否则你就要重新来一遍)到此得到的NK.bin就包含了应用程序MyApp.exe和MyApp.lnk,并且MyApp程序会在系统启动时自动运行。说明:I.将自定义的文件打包进NK.bin中的方法有两种,一种是编辑project.bib文件。在FILESSection描述文件的名称,源文件的路径,文件在目标系统中的属性。在上面,MyApp.exe$(_FLATRELEASEDIR)MyApp.exeNKH表示将E:ProjectMyWinCERelDirCEPC_X86Release目录下的文件MyApp.exe文件打包进NK.bin,并且此文件将处在Kernel内存区,文件属性类型为隐藏。第二种方法是添加UserFeature。PlatformBuilderIDE->FeatureView->在"MyWinCEFeatures"上RightClick鼠标->InsertUserFeature->指向想打包的文件。无论采用哪种打包方法,在启动的WindowsCE系统中,文件都在Windows目录下。下一步就是根据需要重新组织文件系统的目录结构。II.组织文件系统的目录结构的途径在于修改project.dat文件,添加文件目录结构的描述。描述的语法如下:root:-Directory("")表示在root目录()下创建目录Directory(""):-Directory("")表示在指定目录下创建子目录Directory("(""):-File(".","Windows.")表示在指定目录下创建Windows目录下文件的拷贝,显示名称是.。(记得上面提到打包的文件在Windows目录下吗?呵呵,我想你明白了)III.应用程序并不一定需要打包进NK.bin假定程序在硬盘的某个位置,如硬盘MyAppMyApp.exe,那么只需创建快捷方式文件,链接指向硬盘MyAppMyApp.exe就是了IV.相关PB42帮助主题AddingaFiletoanOperatingSystemCreatingaShortcutFileandAddingIttotheOSOrganizingFilesWithinanOS整个过程简单来说就是,想清楚应用程序将会出现在哪个目录下,创建正确的快捷方式文件,修改目标系统目录组织配置,最后将应用程序和相应的快捷方式文件打包进NK.bin。WinCE自启动应用程序的方法【假定】:PC机的IP地址为:192.168.0.32subnetmask:255.255.255.0设备机的IP地址为:192.168.0.200subnetmask:255.255.255.0【确定】:PC机与设备机通信正常;PC机装有PlatformBuilder(4.2)软件;PC机装有WinCE.net配套的SDK;设备机装有Wince.net(4.2) *** 作系统;【方法一】:步骤一:建立连接。运行PC机上的PlatformBuilder软件,打开Tools->RemoteRegistryEditor,d出WindowsCERemoteRegistryEditor对话框,同时d出SelectawindowsCEDevice。如果PC机上装有SDK,在SelectawindowsCEDevice对话框中就会出现SDK所对应的设备,如TDMVBNETDevice。选中“TDMVBNETDevice”,点击“OK”按钮,出现以下两个对话框:打开设备机的“开始”->“运行”,在对话框内输入:cmd,进入命令画面,在符号>后输入:CEMGRC.EXE/S/T:TCPIPC.DLL/Q/D:192.168.0.32:1865,回车即可。点击PC主机上的对话框“ManualServer-Action”上的“OK”按钮,在WindowsCERemoteRegistryEditor对话框里添加了TDMVBNETDevice设备,表示PC机和设备机连接正常。步骤二:修改注册表。打开TDMVBNETDevice,在[HKEY_LOCAL_MACHINEinit]段添加如下内容:“Launch70”=”HardDiskkingviewouchvew.exe”“Depend70”=hex:1400“Launch80”=”HardDiskkingviewKV_FTP_Server.exe”“Depend80”=hex:14003C00步骤三:保存注册表信息。打开设备机的“开始”->“挂起”,数秒钟后重启设备机。【方法二】:步骤一:建立连接。同方法一。步骤二:修改注册表。打开TDMVBNETDevice,在[HKEY_LOCAL_MACHINEExplorerShellFolders]段修改:将“StartUp”=”Windows”修改为:“StartUp”=”HardDiskStartUp”。步骤三:保存注册表信息。打开设备机的“开始”->“挂起”,数秒钟后重启设备机。步骤四:添加应用程序。在可移动设备(CF卡)里添加目录StartUp,将应用程序如KV_FTP_Server.exe,Tochvew.exe的快捷方式拷到StartUp目录下,重启设备机。

Exfat格式的优点:

1、增强台式电脑与移动设备的相互 *** 作能力。

2、单文件大小最大可达16EB (1EB=1024PB ,1PB=1024TB ,1TB=1024MB,16EB=16777216TB=17,179,869,184MB)。

3、簇大小可高达32MB。

4、同一目录下最大文件数可达65536个。

5、支持访问控制。

6、支持TFAT(WINCE早期文件系统)。

Exfat格式的缺点:

1、exfat兼容性较差,在xp系统中经常无法识别。

2、某些设备(如PDA、DC)将无法使用exFAT格式的闪存卡。

3、使用exFAT的设备将不能够使用 Windows Vista的ReadyBoost功能。

4、授权方式不明确。微软曾经为FAT文件系统的一部分申请过专利,用户可以在Windows XP上添加支援exFAT的修补程序。

扩展资料:

FAT32与exFAT可用4GB文件的区别:

大多数优盘在格式化时默认FAT32,最大优点就是在一个不超过8GB的分区中,FAT32的每个簇容量都固定为4KB,与前代相比可以大大地减少磁盘的浪费,提高磁盘利用率。

虽然对于最大分区容量的支持上面,FAT32的2TB最大分区容量至今仍不过时,但FAT32无法传输并存放超过4GB容量的光盘ISO镜像、高清视频、各种图形作品文件等等,这是最致命的弊端。而exFAT格式在苹果本或者是Windows电脑上都可以格式化,并且在两个系统之间可以互相无障碍使用。相比之下,exFAT格式就没有4GB文件传输限制了。

其实FAT32与exFAT存在着一个升级关系,这两种文件系统都支持OS X系统与Windows系统,如果你将U盘格式化成这两种文件系统,在不同 *** 作系统电脑上可以畅通无阻地使用。

参考资料来源:百度百科-exFAT

Windows CE6.0启动过程分析

在Windows CE 6.0中,内核(Kenerl)和OEM代码被分成oal.exe、kernel.dll和kitl.dll三个部分,其中启动代码(startup)和 OAL层的实现部分不再与内核链接生成NK.exe,取而代之的是启动代码(startup)和硬件相关且独立于内核的OAL层的实现部分编译成 oal.exe,而与内核相关且独立于硬件的OAL层代码包含在kernel.dll中;内核无关传输层(KITL)的支持代码从OAL层分离出来编译成 kitl.dll。

从表面上看,好像只是代码重新组合了一下,从帮助 文档中BSP的移植过程看好像也是这么一回事,实际上,整个Windows CE 6.0内核布局发生了很大的改变。Windows CE 6.0的启动过程也是如此,如果你想按照Windows CE 5.0的启动顺序去分析Windows CE 6.0的启动顺序,可能会走到一个死胡同。主要是因为Windows CE 6.0在启动过程中调用了kernel.dll和kitl.dll两个动态链接库的原因,而且Windows CE6.0不再编译生成KernKitlProf.exe内核文件。

从Windows CE 6.0的帮助文档可以看出,WinCE6.0的启动只与oal.exe和kernel.dll有关,至于kitl.dll,只有将 *** 作系统编译成具有 KITL功能时才用到。分析Windows CE 6.0的启动过程实际上找到编译oal.exe和kernel.dll的源码位置。

首先看一下将WinCE6.0编译成诸如 WinCE5.0所说的基本内核情况,即kern.exe。对于oal.exe源码位置比较容易找到,因为oal.exe是启动代码与硬件相关的OAL层 实现文件编译而成,所以只需在BSP的OAL目录中便能找到。而对于kernel.dll,在BSP目录结构中,基本上无法找到kernel.dll的编 译文件,所以必须从其他方面着手。

下面为WinCE 6.0的编译日志输出文件:makeimg.out在文件复制过程的一部分:

Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\nk.exe for debugger Copying E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll to E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kernel.dll for debugger

从日志输出文件可以看出,在文件复制过程 中,WinCE6.0编译器将oal.exe更名为nk.exe,而将kern.dll文件更名为kernel.dll,也就是说,kern.dll文件 的实现部分就是kernel.dll的实现体。根据前面的分析,oal.exe是与硬件相关独立于内核的OAL层的实现部分,而kernel.dll为内 核相关独立于硬件的OAL层的实现部分。同样可以从最后整合后的二进制配置文件ce.bib文件中看出端倪。

@CESYSGEN IF CE_MODULES_NK

nk.exe E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\oal.exe NK SHZ

kitl.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kitl.dll NK SHZ

kernel.dll E:\WINCE600\OSDesigns\xsbase270\xsbase270\RelDir\XSBase270_ARMV4I_Release\kern.dll NK SHZ

@CESYSGEN ENDIF

而kern.dll动态库在整个Windows CE6.0中没有显式编译过程,即没有一个sources文件有kern.dll的编译过程,所以只能从 *** 作系统的编译文件Makefile中寻找其编译 过程。下面看一下$(_PUBLICROOT)\common\CESYSGEN\makefile中的部分内容:

nk::$(NK_COMPONENTS) $(NK_REPLACE_COMPONENTS)

@copy $(SG_INPUT_LIB)\oemstub.pdb $(SG_OUTPUT_OAKLIB)

@copy $(SG_INPUT_LIB)\oemstub.lib $(SG_OUTPUT_OAKLIB)

set TARGETTYPE=DYNLINK

set TARGETNAME=kern

set RELEASETYPE=OAK

set DLLENTRY=NKStartup

set DEFFILE=NO_DEF_FILE

set TARGETLIBS=

set SOURCELIBS=%%NKLIBS%% $(SG_INPUT_LIB)\nkmain.lib $(SG_INPUT_LIB)\fulllibc.lib

$(MAKECMD) /NOLOGO NOLIBC=1 kern.dll

从上述代码中可以发现,原来kern.dll动态库是从oemstub.lib编译而来,而且与nkmain.lib有关。

在理顺了上述文件的相互之间的关系之后,再来分析Windows CE 6.0的启动过程可能就比较容易啦。

在理清了上述文件的关系之后,便可以分析任意一款基于ARM微处理器的Windows CE 6.0的启动过程,现在以深圳亿道电子技术有限公司开发的基于PXA270 ARM开发平台为例,分析Windows CE 6.0 *** 作系统启动过程。

1、Startup函数:

从Windows CE 6.0的帮助文档可以看出,WinCE6.0的启动只与oal.exe和kernel.dll有关,至于kitl.dll,只有将 *** 作系统编译成具有 KITL功能时才用到。分析Windows CE 6.0的启动过程实际上找到编译oal.exe和kernel.dll的源码位置。

oal.exe的通过Startup函数完成硬件 的初始化。Startup.s代码与该硬件平台的Bootloader启动代码共用,其中PreInit函数主要完成将ARM处理器工作模式切换到管理员 模式、同时关闭MMU,并检测系统启动原因,如果是热启动、即在该函数调用之前已经启动了Bootloader程序,相当基本硬件初始化已经完成,则直接 跳转到OALStartUp函数中;否则需要进行硬件中断屏蔽、内存、系统时钟频率、电源管理等硬件的基本初始化过程。(具体过程见代码的分析)

$(_PLATFORMROOT)\xsbase270\src\common\Startup\Startup.s

LEAF_ENTRY StartUp

bl PreInit

tst r10, #RCSR_HARD_RESET

beq OALStartUp

tst r10, #RCSR_GPIO_RESET

bne Continue_StartUp

bl xlli_mem_init 初始化内存控制器

ldr r0, =xlli_PMRCREGS_PHYSICAL_BASE

ldr r0, [r0, #xlli_PSPR_offset]

mov r1, r10

bl XllpPmValidateResumeFromSleep

cmp r0, #0

bne Failed_Sleep_Resume

Sleep_Reset

ldr r0, =xlli_PMRCREGS_PHYSICAL_BASE

ldr r0, [r0, #xlli_PSPR_offset]

mov r1, r10

b XllpPmGoToContextRestoration

Failed_Sleep_Resume

ldr r1, =xlli_RCSR_SMR

bic r10, r10, r1

Continue_StartUp

bl xlli_intr_init初始化中断控制器

bl EnableClks使能内核时钟(内存/OS定时器/FFART时钟之需)

bl OALXScaleSetFrequencies 设置系统频率

bl xlli_mem_Topt

bl xlli_mem_restart 复位内存,使其处于工作模式

bl xlli_ost_init 初始化 *** 作系统定时器

bl xlli_pwrmgr_init 初始化电源管理

bl xlli_IMpwr_init 初始化内部存储器

b

ENTRY_END

2、OALStartUp函数:

在系统硬件初始化完毕之后,Startup调用 OALStartUp函数,OALStartUp函数主要完成将OEMAddressTable表传递给内核;然后调用KernelStart函数跳转到 内核OEMAddressTable表的主要作用表的每一个入口都定义了一个内存中的物理位置、内存的大小以及映射这物理地址的静态虚拟地址;

◆静态虚拟内存地址被定义在缓冲存储器的范围之内;

◆内核可以创建非缓冲的内存地址指向到相同的物理地址;

◆对于同一物理地址,既有一个缓冲的虚拟内存地址,也有一个非缓冲的虚拟内存地址;

◆OEMAddressTable最后必须以0结尾;

◆对于MIPS和SHx类型的CPU,物理地址与虚拟地址的映射由CPU完成,无需创建OEMAddressTable

$(_PLATFORMROOT)\xsbase270\src\Inc\ Oemaddrtab_cfg.inc):

$(_PLATFORMROOT)\xsbase270\src\oal\OalLib\Startup.s

3、KernelStart函数主要作用:

◆完成OEMAddressTable表中的物理地址到虚拟地址和虚拟地址到物理地址之间的映射;

◆对存储器页表和内核参数区存储空间(RAM或DRAM)进行清零处理。

◆读出CPU的ID号,内核需要根据该ID决定ARM的MMU处理,因为ARMV6和ARMV6之前的ARM处理器的MMU处理过程有所区别;

◆设置并开启MMU和Cache,因为在Startup函数关闭MMU和Cache;

◆设置ARM处理器工作模式的SP指针,ARM处理器共用7种不同的工作模式 (USER、FIQ、IRQ、Supervisor、Abort、Undefined、System),除用户模式(USER)和系统模式 (System)之外,其他5种工作模式都有具有特定的SP指针寄存器(ARM处理器称其为影子寄存器);

◆读取内核启动所需要的KDataStruct结构体;

◆调用ARMInit函数重新定位Windows CE内核参数pTOC和初始化OEMInitGlobals全局变量;

◆利用mov pc, r12指令跳转到kernel.dll的入口位置,即NKStartup函数中。

$(_PRIVATEROOT)WINCEOS\COREOS\NK\LDR\ARM\armstart.s

4、ARMInit函数:

在ARMInit之前,系统仍无法使用全局变量, 因为系统的全局还在ROM区域,对于 *** 作系统而言,出于安全考虑,只有XIP程序才有读取ROM区域数据的权利,对于大部分Windows CE *** 作系统,只有将数据拷贝到RAM区域后才能进行读写,ARMInit函数中通过调用KernelRelocate函数对pTOC全局变量重新定位,定位 之后,对内核启动所需要的KDataStruct结构体进行初始化,其中OEMInitGlobals便是交换oal.exe和kernel.dll之间 的全局指针,ARMInit函数返回kernel.dll的入口位置。并在KernelStart函数最后利用mov pc, r12指令跳转到kernel.dll的入口位置,即NKStartup函数中。

$(_PRIVATEROOT)WINCEOS\COREOS\NK\LDR\ARM\arminit.c

5、NKStartup函数:

硬件平台初始化完成后,oal.exe的启动任务基本完成,余下的启动工作由内核相关且独立于内核的OAL层实现体kernel.dll接管。kernel.dll主要作用:

◆从结构体参数KDataStruct * pKData提取内核启动时所必须的全局变量,同时初始化内核全局变量;

◆定位对Windows CE 6.0特有的OEMGLOBAL结构体的初始化函数OEMInitGlobals地址,该结构体构建了内核和OAL层之间进行通信的桥梁。在 OEMGLOBAL结构体定义了OAL层所必须的函数,该结构体在oemglobal.c文件中被初始化,并被编译在OEMMain.lib和 OEMMain_StaticKITL.lib两个库中,如果OAL链接这两个库,则必须要有该结构体中函数实现体;

◆通过调用ARMSetup设置物理地址和非缓冲的虚拟内存地址的映射、ARM中断向量以及内核模式所需要的堆栈。

◆调用OEMInitDebugSerial函数初始化调试串口;

◆调用OEMInit进行平台初始化;

需要注意的时,NKStartup函数调用OEMInitDebugSerial和 OEMInit函数的过程与Windows CE 6.0之前的版本完全不同,这是因为在Windows CE 6.0以前的版本中,由于内核(kernel)、OAL和KITL编译在一个可执行的文件中,它们之间的共享变量只需简单利用extern关键字申明便可 相互之间进行访问,而在Windows CE 6.0中,由于内核(kernel)、OAL和KITL被编译成不同的可执行文件,变量之间的相互访问无法使用extern关键字实现共享,即内核无法使 用extern DWORD varX方法访问OAL层的变量varX,当然OAL层的实现体同样无法通过同样的方式访问内核变量。为实现内核和OAL访问共享信息,Windows CE 6.0定义了OEMGLOBAL和GLOBAL两个结构体。

在 Windows CE 6.0的内核启动时,OS找到OAL的入口位置,然后调用入口函数与全局块进行指针交换,这样内核才能使用OAL层中的信息,同样OAL层才能访问内核(kernel)导出的函数。

所以上述两个函数的调用实际上通过OEMGLOBAL结构体实现的。实际调用位置为$(_PRIVATEROOT)\winceos\coreos \nk\oemstub\oemstub.c中的OEMInitDebugSerial和OEMInit,这两个函数中通过OEMGLOBAL结构体指针 访问OAL层中的OEMInitDebugSerial和OEMInit。

首先看一下将WinCE6.0编译成诸如WinCE5.0所说的基本内核情况,即kern.exe。对于oal.exe源码位置比较容易找到,因为 oal.exe是启动代码与硬件相关的OAL层实现文件编译而成,所以只需在BSP的OAL目录中便能找到。而对于kernel.dll,在BSP目录结 构中,基本上无法找到kernel.dll的编译文件,所以必须从其他方面着手。

调用KernelFindMemory()函数分割RAM区域,在Windows CE *** 作系统中,RAM空间主要分为存储内存和程序内存,存储内存主要为文件的存储空间,包括内核文件和复制到系统中所有目标文件,程序内存为运行程序时所需要的存储空间。

◆KernelStart ()启动内核。

$(_PRIVATEROOT)\WINCEOS\COREOS\NK\KERNEL\ARM\mdarm.c

void NKStartup (struct KDataStruct * pKData)

{

。。。。

}

6、KernelSstart函数:

这里的KernelStart函数与前面的KernelStart函数的属于两个完全不 同的函数,NKStartup函数中调用的KernelStart函数为$(_PRIVATEROOT)\WINCEOS\COREOS\NK \KERNEL\ARM\armtrap.s文件中的KernelStart函数,主要完成调用内核初始化函数KernelInit,并跳转到 *** 作系统的 第一个启动的任务。

LEAF_ENTRY KernelStart

ldr r4, =KData (r4) = ptr to KDataStruct

ldr r0, =APIRet

str r0, [r4, #pAPIReturn] set API return address

mov r1, #SVC_MODE

msr cpsr_c, r1 switch to Supervisor Mode w/IRQs enabled

CALL KernelInit initialize scheduler, etc.

mov r0, #0 no current thread

mov r1, #ID_RESCHEDULE

b FirstSchedule

ENTRY_END

7、KernelInit函数:

Windows CE 6.0的内核初始化函数同其他版本的内核初始化函数基本相近,主要完成在启动第一个线程前对内核进行初始化,主要包括API函数集初始化、堆的初始化、初始化内存池、进程初始化、线程初始化和文件映射初始化等 *** 作。

void KernelInit (void)

。。。{

}

8、FirstSchedule:

FirstSchedule函数为Windows CE *** 作系统启动过程中最后无条件跳转的一个函数,windows CE进行第一个调度,实际为一个空闲线程,因为windows CE系统还没有完成启动,只有当windows CE完全启动并进入稳定状态,然后启动文件系统filesys.dll,设备管理device.dll,窗体图像子系统gews.dll和shell程序 explore.exe。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/tougao/11731787.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-18
下一篇 2023-05-18

发表评论

登录后才能评论

评论列表(0条)

保存